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: 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