On Fri, Dec 05, 2008 at 02:34:54PM +1100, Neil Brown wrote: > On Thursday December 4, bfields@xxxxxxxxxxxx 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? Even numbers are supposed to mean that a host is down, odd that it's up. In practice noone ever uses that fact--they only ever advertise odd numbers. So we might get away with using an even number. But then again a peer would be in its rights to check the parity and complain, and some may well do that. > 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. Hm, I don't know; it might be that an inconveniently timed network partition combined with nsm states that repeat themselves could prevent a client from knowing about some reboot that it should have known about. It's safer to keep a counter and ensure that the state never repeats (well, anyway, not until it overflows after a few billion reboots). > If we reboot and find that both sm and sm.bak are empty > there is really no point in changing 'state'. I think I've convinced myself of that, yes. For the purposes of locking, a reboot which didn't require notifying any client may as well have not been a reboot, since no state was lost. But we should at least make sure that the state is properly initialized and nondecreasing. > I think it would still be valuable to replace the 'sync' with two > 'fsync's, one of the file, one on the directory. Sure, may as well.--b. > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
