On Fri, Nov 11 2016, J. Bruce Fields wrote: > On Thu, Nov 10, 2016 at 10:54:41AM +1100, NeilBrown wrote: >> On Wed, Nov 09 2016, Jeff Layton wrote: >> >> > On Wed, 2016-11-09 at 14:46 +1100, NeilBrown wrote: >> >> Hi, >> >> I notice that nfsdcltrack has a "--storagedir" option. >> >> I wonder how this can be used, given the nfsdcltrack is only(?) called >> >> from the kernel and there is no(?) mechanism to pass extra options. >> >> >> >> In a clustered-server context it would make sense(?) to share the >> >> database between cluster nodes and it is easiest to do this if the >> >> file in a separate filesystem (mounted as part of fail-over) rather >> >> than in /var. >> >> This can(?) be achieved using a symlink, but rpm likes to remove >> >> symlinks to non-existent locations. >> >> >> >> With NFSv3 the equivalent is the state files maintained by statd, and >> >> these can be relocated by passing the -P option to rpc.statd. >> >> How does one do a similar thing for NFSv4??? >> >> >> >> >> > >> > Ahh, I added that option mostly for when I was testing it. I did a lot >> > of the earlier testing running it by hand, and --storagedir let me use a >> > different directory for the db. I did have a vague idea that we might >> > use it in the situation you describe, but I never wired that up as I >> > didn't have a real need for it. >> > >> > We could add a new module parm that would set that option when the >> > kernel does its callout, or allow passing the storagedir by environment >> > variable. >> > >> > What would make the most sense from a usability standpoint? >> >> Maybe a config file in /etc/ which nfsdcltrack reads on start-up? >> Though in some ways I'd rather that instead of running a program, the >> kernel sent a message to user-space. Possibly a u-event? >> Then existing configuration mechanisms could be used to choose a program >> and a context for it to run in. >> I wonder if u-events handle namespaces at all. >> >> This came up because a customer was symlinking all of /var/lib/nfs to >> shared storage (and lost their symlink thanks to rpm). That isn't a >> solution that I really like, and it led me to reflect on other things in >> /var/lib/nfs. >> >> etab - holds a normalized copy of /etc/exports, plus ad hoc changes. >> It would like in /run/nfs if we built this today >> export-lock - lockfile to protect changes to above. Would also be >> in /run if we built it today. (I wonder why that doesn't >> use .etab.lock, which is already used for locking) >> state, sm, sm.bak - statd state files. These belong in /var/lib/nfs >> but are easily relocated with args to rpc.statd and sm-notify. >> v4recovery - the NFSv4 version of above >> xtab - this hasn't been needed since we gained /proc/fs/nfs/exports >> It is just a record of what should be in the kernel >> We should remove this. I'll make a patch. >> rmtab - this hasn't been needed since the "new cache" and the >> up-call mechanism were created. It might be still used >> to respond to "showmount" commands, but that was never reliable. >> If we keep it, it should probably move to /run. >> But what do people think if finally discarding the old >> (non-new_cache) code and using that as an excuse to increment >> the major version number of nfs-utils? > > Looking at the history.... Looks like that went into 2.5.42 in late > 2002. In distro terms, first distros to support the new interface > include RHEL4, Debian 3.1/Sarge, Suse 9. > > No comment on the other stuff, just wanted to check that as I'm inclined > to extreme conservatism on backwards compatibility. But, yeah, I guess > that'd be OK. Thanks. On the flip side, kernels since 3.1 (4.5 years ago) cannot make use of the code I'm suggesting be removed. So it does feel like it might be time. NeilBrown
Attachment:
signature.asc
Description: PGP signature
