Re: Make sm-notify faster if there are no servers to notify

[Neil Brown <neilb@suse.de>]

On Thursday December 4, bfields@fieldses.org wrote:
> 
> Any progress on this?  I don't think we can release in the current
> state, since as far as I can tell that means on a new system, unless the
> install scripts create /var/lib/nfs/state, neither sm-notify nor statd
> ever writes to /proc/sys/fs/nfs/nsm_local_state, and (without testing)
> it looks to me like that means lockd defaults to a state of 0, which is
> nonsense?

Why is '0' nonsense?
The only real requirement on 'state' is that it changes when the host
reboots while some peer is monitoring it.  Even if it got reset to
zero every time the sm and sm.bak became empty it would still work
just fine.  If we reboot and find that both sm and sm.bak are empty
there is really no point in changing 'state'.


I think it would still be valuable to replace the 'sync' with two
'fsync's, one of the file, one on the directory.
This may not be a win on ext3 today (I'm not 100% certain about that)
but there are other filesystems and more seem to be coming.

NeilBrown