diff options
author | Jeff Layton <jlayton@redhat.com> | 2012-11-08 15:02:20 -0500 |
---|---|---|
committer | Steve Dickson <steved@redhat.com> | 2012-11-11 18:01:23 -0500 |
commit | 79ff473c2a07078bde8900e66a6db1a17039a956 (patch) | |
tree | 9e6e23d368adc85561395525b11b266627070635 /utils/nfsdcltrack/nfsdcld.man | |
parent | 09cc3c831c8b1f27439fe09c951139bb6ec8e6c6 (diff) | |
download | nfs-utils-79ff473c2a07078bde8900e66a6db1a17039a956.tar.gz nfs-utils-79ff473c2a07078bde8900e66a6db1a17039a956.tar.xz nfs-utils-79ff473c2a07078bde8900e66a6db1a17039a956.zip |
nfsdcltrack: add a legacy transition mechanism
If the kernel passes the legacy recdir path in the environment, then we
can use that to transition from the old legacy tracker to the new one.
On a "check" operation, if there is no record of the client in the
database, check to see if there is a matching recoverydir. If there
isn't then just refuse the reclaim. If there is, then insert a new
record for this client into the db, and remove the legacy recoverydir.
If either of those operations fail, then refuse the reclaim.
On a "gracedone" operation, clean out the entire legacy recoverydir
after purging any unreclaimed records from the db. There's not much
we can do if this fails, so just log a warning if it does.
Note that this is a one-way conversion. If the user later boots back
into an older kernel, it will have no knowledge of the new database.
In principle, we could create a tool that would walk the clients
table, md5 hash the clientids and create directories in the
v4recovery dir. Doing that automatically would be pretty difficult
however.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
Diffstat (limited to 'utils/nfsdcltrack/nfsdcld.man')
0 files changed, 0 insertions, 0 deletions