Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!eastapps!hinode!geoff From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) Newsgroups: comp.protocols.nfs Subject: Re: NFS performance Message-ID: <6743@eastapps.East.Sun.COM> Date: 14 Jun 91 15:00:45 GMT References: <1991Jun13.164017.29944@Firewall.Nielsen.Com> <625@appserv.Eng.Sun.COM> <1991Jun13.234448.16172@Firewall.Nielsen.Com> Sender: news@East.Sun.COM Reply-To: geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) Organization: Sun Microsystems PC-NFS Engineering Lines: 43 Quoth droms@bucknell.edu (in ): #In article <1991Jun13.234448.16172@Firewall.Nielsen.Com> kdenning@genesis.Naitc.Com (Karl Denninger) writes: # # > # >If the server ACKs the data before writing it to disk, there is a window # >during which the server can crash. The data is then lost. # # How does this differ from the standard "Unix" way of doing file I/O, which # returns a successful reply from a write call before the data is safely on # disk? If you write data, get back a "ACK" (or good return value) the data # isn't necessarially on disk -- it could be in the buffer cache. If the # machine crashes before the data is flushed you lose. # #I think the difference lies in the feedback to the user. If the local #UNIX box crashes, the user is aware "something is wrong" immediately. #If the server crashes and reboots, the data can be lost silently... It's more than simply a vague "feedback to the user": it's a question of what assertions can be made about the correctness of file system operations. Even though normal buffer cache operations can reorder some kinds of operation, I can code something like write(file1, data1) fsync(file1) write(file2, "file1 was written successfully") (with appropriate error checking) and be confident that file2 will be written if and only if file1 was written. Karl's "standard Unix way" doesn't apply here: if the machine crashes, the process will crash with it. If an NFS server could ack the first write (but not commit it to stable storage), then crash and reboot, the failure of the write would be undetectable. The decision as to whether data should be written "safely" or not should logically rest with the client, not the server. This is why the hack of an async server side configuration option is so dangerous. The correct approach, of course, is the (unimplemented) RFS_WRITECACHE NFS function.... >sigh< But for now, Prestoserve is the best solution. --Geoff Arnold, PC-NFS architect(geoff@East.Sun.COM or geoff.arnold@Sun.COM)-- ------------------------------------------------------------------------------ -- Sun Technology Enterprises : PC Networking group -- -- (officially from July 1, but effectively in place right now) --