Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!olivea!tardis!tymix!uunet!mcsun!ukc!educ-isis!teexand From: teexand@ioe.lon.ac.uk (Andrew Dawson) Newsgroups: comp.unix.aix Subject: Re: Control NFS exported filesystems Message-ID: <1991Jun20.090136.14351@ioe.lon.ac.uk> Date: 20 Jun 91 09:01:36 GMT Article-I.D.: ioe.1991Jun20.090136.14351 References: <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU> <8567@awdprime.UUCP> <1991Jun19.154830.17276@uai.com> <1991Jun19.162331.25505@bellcore.bellcore.com> Reply-To: andrew@uxm.sm.ucl.ac.uk Organization: Bloomsbury Computing Consortium Lines: 18 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. -- #include /* My brain was swiss-cheesed when I wrote this */ 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"