On Wed, Oct 29, 2008 at 04:30:32PM -0400, Chuck Lever wrote: > I assume sync() is required because this logic performs a rename as well > as a simple write? I think an fsync() on the containing directory (together with an fsync() of the file itself) would do the job if you wanted to avoid the globaly sync(). I don't think ext3 is capable of doing anything finer-grained than a whole-filesystem sync, though, so this doesn't help many people in practice right now. In any case, the rename adds an extra level of safety by ensuring the nsm state is updated atomically, so we shouldn't get rid of it. >> Anyway, I think the nsm state updating shouldn't matter if you don't >> even have any peers to notify. > > It probably does matter. > > When a system is initially installed, it likely does not have a state > file in /var/lib/nfs. This may be harmless if it's not present; > rpc.statd probably does the right thing in this case. The "right thing" in that case would be, I guess, to create a state file with "0" in it. It doesn't do that. So this patch *does* break stuff. Oops! So should we revert it and do something else, or patch statd to create a new state file if necessary? > However, the rest of the logic in nsm_get_state() is needed to bump the > system's state value properly after every reboot. It may be > inconsequential if there were no mounts or no NFS clients during the > last reboot, but this is subtle. I wouldn't bet on it. If the state is only every communicated to hosts by notifications, then if we're not notifying, the update of the state can't matter. (So is that premise correct?) --b. -- 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
