| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
readdir picks up these two entries as "normal" dentries, but rmdir'ing
them won't work (and we wouldn't want to remove them anyway).
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Since we want to move to using the usermodehelper upcall
unconditionally, just remove nfsdcld. The kernel code to handle
this will be formally deprecated in 3.10 as well.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tracking db
Usermode helper upcalls are all the rage these days for infrequent
upcalls, since they make it rather idiot-proof. No running daemon is
required, so there's really no setup beyond ensuring that the callout
exists and is runnable.
This program adds a callout program to nfs-utils for that purpose. The
storage engine on the backend is identical to the one used by nfsdcld.
This just adds a new frontend for it.
For now, building with --enable-nfsdcltrack gives you both nfsdcld and
nfsdcltrack programs. A later patch will remove nfsdcld altogether.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we add a new usermodehelper upcall program to do the database
access, the existing "init" function will be overkill every time
we start up the program.
Break out the database handle establishment routine into a separate
function that we can call from each upcall command in the one-shot
program.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
This is holdover from an earlier version of the code and doesn't really
provide any benefit. Also, mark the topdir and dirname arguments const
since they should never be changed.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
We'll soon be adding a new nfsdcltrack program, at which point it won't
make much sense to call this directory and the config option "nfsdcld".
Rename it to be a bit more generic.
While we're at it, change the default for --enable-cltrack to "yes".
When we introduce the one-shot program, we're going to want to build
it by default anyway.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|