On Sun, Jul 07, 2013 at 10:51:30PM -0400, Thor Lancelot Simon wrote: > On Sun, Jul 07, 2013 at 07:55:12PM +0200, Manuel Bouyer wrote: > > On Sun, Jul 07, 2013 at 10:18:29AM -0700, Erik Fair wrote: > > > The problem of close(2) returning an "unexpected" error showed up in the > > > original Andrew Filesystem (AFS) papers from CMU, too - AFS syncs on > > > close, which can fail, but they found most applications not checking the > > > return code from close(2). > > > > Yes, it's the same issue as NFS: write(2) can't return the error, unless > > it really does the write (in this case the writes are synchrounous). > > I don't think that's quite true. It could do the quota accounting for the > write, but not actually do the write. If all the quota datastructures > are in-core, that might be fast enough.
How could it do that, when all informations is on the remote server ? When writing a block, the NFS client doesn't know if it's already allocated (which which case it's a NOP for quotas) or if it's a new block. Not to mention that writes can come from different clients ... -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --