Newsgroups: comp.protocols.nfs
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!Firewall!uunet!convex!thurlow
From: thurlow@convex.com (Robert Thurlow)
Subject: Re: NFS performance
Message-ID: <thurlow.676918668@convex.convex.com>
Sender: usenet@convex.com (news access account)
Nntp-Posting-Host: dhostwo.convex.com
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
References: <1991Jun13.164017.29944@Firewall.Nielsen.Com> <625@appserv.Eng.Sun.COM> <1991Jun13.234448.16172@Firewall.Nielsen.Com>
Date: Fri, 14 Jun 1991 16:57:48 GMT
Lines: 49

In <1991Jun13.234448.16172@Firewall.Nielsen.Com> kdenning@genesis.Naitc.Com (Karl Denninger) writes:

>I can't see how this is any different than ACKing packets from NFS clients
>when you haven't actually written them any further than the buffer cache
>(exactly the same as the standard Unix semantics).  You have the same risks
>if the server (the machine with the disk on it :-) crashes as you would with
>a local workstation or server drive.  In both cases data can be lost.

No you _don't_ have the same risks; you have a lot more points of
failure, like someone turning off your server and physically removing
it from your network, for example.  With NFS, you've taken a pretty
reliable disk I/O subsystem and put the disk maybe very far away, with
lots of failure points you didn't have before, and with other processes
able to alter the data outside of either your control or awareness.  To
some degree, though, you're still expecting it to obey perfect Unix
filesystem semantics.  It just ain't gonna work that way (though if Sun
fixed some of the protocol bugs in NFS, it'd be better).  An
implementor needs to think harder to get NFS to do The Right Thing.

Take this for an example: you're doing a 1K write to a filesystem with
an 8K blocksize, so you need to do a read/edit/write of a whole block.
What happens when the initial read tells you that the file has changed,
and that you should flush everything you know about the file out of
your buffer cache?  How do you hang onto the data you were trying to
write?  That isn't a problem over UFS.

>>MIPS systems have an unsafe export option that allows you to turn off
>>this constraint - big performance win, big safety lose.

>There is no export option in the manual pages for RiscOS 4.51 which 
>addresses what you're talking about.  I just checked again; it's not there.

Yup, we do this too, but we make a discouraging noise about it, and
it isn't the default like it is on Silicon Graphics machines.  It's
worth the kick for some things, though; my Sun (running 4.1.1) often
doesn't survive a server crash, so an 'unsafe' swap might be okay.

>I would think that one of the easiest ways to address this would be to allow
>an option to have "safe" or "unsafe" writes on a per-mount basis.  This
>allows the user to choose his level of performance and risk, and make
>his/her own choice.  I'd be for that.

It would make a good mount option, I agree.  Having a global decision
about such things made for you sucks.

Rob T
--
Rob Thurlow, thurlow@convex.com
An employee and not a spokesman for Convex Computer Corp., Dallas, TX
