Re: Question about nfsdcltrack --storagedir

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 3968 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]