Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!decwrl!sgi!llustig!objy!prefect!peter From: peter@prefect.Berkeley.EDU (Peter Moore) Newsgroups: comp.protocols.nfs Subject: Re: NFS writes and fsync(). Message-ID: <1990Oct15.025613.12574@objy.com> Date: 15 Oct 90 02:56:13 GMT References: <1990Oct9.152612@objy.objy.com> <1990Oct14.082712.10811@objy.com> Sender: news@objy.com Reply-To: peter@objy.com Organization: Objectivity Inc. Lines: 29 Oops. Further thought brings out some problems. Given the scenario: 1) Process P on machine L writes to file F on machine R 2) R crashes before syncing the changes to disk and either: a) recovers before P does any more writes to F, or b) crashes after P has finished with F. 3) P continues on blithely unaware that the writes to F failed and produces some data. In my last note I said that a process that did the careful fsyncs that even local writes require wouldn't be bothered by the above scenario. But calling fsync during stage 3 would only commit changes since R reconnected. P would falsely think that all changes have been committed. This is not good. Two changes could fix this. First, invalidate all NFS handles on reboot. This would cause fsyncs on existing file descriptors to fail. Second, (sadly) do an implicit fsync on every close. This would protect processes that do: write, close, reopen, and then fsync. So we still need implicit fsyncs, but not on every write. But now a server crash will take down all processes with open file descriptors on that server, whether or not the process actually lost any data. So there are more tradeoffs to be made. But it still seems like a worthwhile option. Peter