Date: Sun, 20 Aug 95 23:29 CDT From: steve@simon.chi.il.us (Steven E. Piette) To: nate@rocky.sri.MT.net Cc: terry@cs.weber.edu, freebsd-hackers@freebsd.org Subject: Re: Making a FreeBSD NFS server Message-ID: <m0skOUl-0006IIC@simon.chi.il.us>
next in thread | raw e-mail | index | archive | help
> From rocky.sri.MT.net!nate Sun Aug 20 14:58:22 1995 > Date: Sun, 20 Aug 1995 12:02:14 -0600 > From: Nate Williams <nate@rocky.sri.MT.net> > To: steve@simon.chi.il.us (Steven E. Piette) > Cc: terry@cs.weber.edu, freebsd-hackers@freebsd.org > Subject: Re: Making a FreeBSD NFS server > Content-Length: 2228 > > Steven E. Piette writes: > [ Speeding up NFS writes ] > Terry > You can turn on async writes in the BSD NFS server. > > Terry> Be warned that, though Sun and SVR4 do this too, this is a cache > Terry> coherency violation and can result in Bad Things Happening in case > Terry> of a server power failure or other failure that results in the > Terry> server going down, then coming back up while the app on a client > Terry> is still running. This is because the client will think the data > Terry> was written and may depend on being able to retrieve it later > Terry> (ie: a database index). > > > Steve> Terry, Do you bother checking your references before you make blanket > Steve> statements or do you like to just wing it? Do you bother checking them > Steve> after someone points out your errors? > > Huh? What Terry said above is correct. With async writes, the server > effectively tells the client is that the data has been written (when in > fact it really hasn't been). In the case of a power failure that occurs > after the server has informed the client, but *before* the data has > actually been written you have big problems. > > > Nate > Thanks Nate, First, my message slipped out be accident. I was sending a bunch of messages and I sent it instead of deleting my initial thoughts about his mail. My apologies to Terry, for letting my initial reactions become public. I usually start a reply and continue reading mail for additional responses before sending it out. In this case I sent out something I was going to let slide. I know all about Async writes, prestoserve, and UPS's. I have to explain them to customers on almost regular basis. My issue was with Terry's assertion that Async writes was part of the SVID and that Sun's and SVR4 machines do this this by default. Or at least that's what I thought he was saying, because he's said that before, and it's plainly wrong. In all fairness to Terry, what he said was: TL > The SGI, being SVR4 based, is doing async writes on the server by TL > default. The BSD box is waiting for the write to be comitted to TL > the server disk before continuing. TL > TL > You can turn on async writes in the BSD NFS server. TL > TL > Be warned that, though Sun and SVR4 do this too, this is a cache TL > coherency violation and can result in Bad Things Happening in case TL > of a server power failure or other failure that results in the TL > server going down, then coming back up while the app on a client TL > is still running. This is because the client will think the data TL > was written and may depend on being able to retrieve it later TL > (ie: a database index). He's correct about the behaviour and the problems it creates. I might have misinterpreting his comment to "Be warned that, though Sun and SVR4 do this too" as meaning that they also use Async by default as opposed to meaning that You can turn on async writes in the BSD NFS server and Sun's and SVR4 machines as well. The former is incorrect, the latter is accurate. Since I'm not sure what he was tring to say, I again apologise for biting Terry's head off.... Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0skOUl-0006IIC>