| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Allow the fetching of NFSDCLTRACK_GRACE_START out of environment
variables. If it's present in the "create" or "init" upcalls, then we
can use that to query the database to see whether there are any clients
that have not issued a RECLAIM_COMPLETE since that time.
If there aren't any, then we know that all reclaim activity is now done
and we can then cue the kernel to lift the grace period.
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
...and set the has_session field in the DB based on whether it's
true or not. Since we no longer set the timestamp for v4.1+ clients on
a check operation, we must be careful to set the timestamp to zero
for v4.1+ clients found via the legacy tracker.
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have some possibility for races with nfsdcltrack when the DB schema
is upgraded.
Suppose we update the nfs-utils package on a machine after the DB has
been initialized. With the current scheme of initializing the DB only
during the "init" phase, we could end up with a new program that expects
a new schema with an old database.
We could try to do a one-time update when the package is installed, but
that could be racy. We could get an upcall between when the program is
installed and when we run the update. Also, relying on packaging to get
that right is tricky at best. To fix this, change how the database
initialization and checking of the schema revision works.
On every upcall, attempt to open the db as we normally would. If that
fails, then try to create the directory if it doesn't exist and then
retry the open. If it fails again, then give up.
If we get a successful open, then query the DB for the schema version.
If it matches what we expect, then declare success and move on. If the
query fails then assume that the DB isn't set up yet. Start an exclusive
transaction, check the schema version again and then set up the DB if no
one raced in to create it in the meantime.
This should only add a tiny bit of overhead on most upcalls (just an
extra select of the parameters table), and should improve the
performance of the "init" upcall. It'll also make it possible to handle
DB schema changes sanely.
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
