Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!bellcore!iscp.Bellcore.COM!jona From: jona@iscp.Bellcore.COM (Jon Alperin) Newsgroups: comp.unix.aix Subject: Re: Control NFS exported filesystems Message-ID: <1991Jun20.141138.7555@bellcore.bellcore.com> Date: 20 Jun 91 14:11:38 GMT References: <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU> <8567@awdprime.UUCP> <1991Jun19.154830.17276@uai.com> <1991Jun19.162331.25505@bellcore.bellcore.com> <1991Jun20.090136.14351@ioe.lon.ac.uk> Sender: usenet@bellcore.bellcore.com (Poster of News) Reply-To: jona@iscp.Bellcore.COM (Jon Alperin) Organization: Bell Communications Research (Bellcore) Lines: 31 In article <1991Jun20.090136.14351@ioe.lon.ac.uk>, teexand@ioe.lon.ac.uk (Andrew Dawson) writes: |> In <1991Jun19.162331.25505@bellcore.bellcore.com> jona@iscp.Bellcore.COM (Jon Alperin) writes: |> |> > Hey...maybe this explains the reason that when I save a file |> >under VI which is kept on another NFS partition, VI tells me that it |> >was able to save the file, but because the real physical disk was full I |> >end up with a 0 length file (and lose all my work)..... |> |> This sounds like something we have been discussing with IBM recently. I think |> essentially the client is cacheing requests, so although write() returns |> sucessfully, the data hasn't been written to disk. Your application may pick up |> an error if fsync is called, and the close should also fail (not that many |> applications check this). However, I'm not sure even this much worked until |> we'd applied an APAR fix. SO....whats the APAR #? |> JANET: andrew@uk.ac.ucl.sm.uxm UUCP/EARN/BITNET: andrew@uxm.sm.ucl.ac.uk |> INTERNET: andrew%uxm.sm.ucl.ac.uk@nsfnet-relay.ac.uk |> "Leapers do it with assistance from neurological holograms" -- Jon Alperin Bell Communications Research ---> Internet: jona@iscp.bellcore.com ---> Voicenet: (908) 699-8674 ---> UUNET: uunet!bcr!jona * All opinions and stupid questions are my own *