On Wed, Oct 29, 2008 at 05:11:45PM -0400, bfields wrote: > 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? It looks like this still needs to be fixed? I think it would be good enough just to teach rpc.nfsd to create the file if it doesn't exist. --b. > > > 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
