Re: [PATCH] PUFFS backend allocation (round 3)

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

On 28 Oct 2014, at 15:43, Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:

> On Tue, Oct 28, 2014 at 02:52:36PM +0100, J. Hannken-Illjes wrote:
>> NFS allows them and therefore VOP_CLOSE is the last chance to report
>> write errors back to the application.
> 
> The situation is a bit different: write and fsync call VOP_PUTPAGE
> which calls VOP_STRATEGY and forgets about the write error.

Confused.  If write and/or fsync are synchronous (VOP_PUTPAGES with
flag PGO_SYNCIO) no write error will be forgotten.  If one of these
VOP_PUTPAGES is async the write error will be delayed and if the
next (and last) operation is VOP_CLOSE this is the last chance to
report the error back.  If any intermediate operation returns a delayed
error to the application it is cleared and close will no longer see it.

> The 
> write error should be recovered by write and fsync and then cleared:
> I do not want to get in in the next write operation: immagine I write
> at the end of a file, get EDQUOT, then within an allocated area in the
> file, I should not get EDQUOT again.

I don't understand this section.

> But what about close? If I am to be reported a write error when calling
> close, it should _not_ be cleared as I should get it again if I call
> caose again, until the time the write succeeds.

There is no close after close.  Once a file is closed it may return
a delayed error but has to close anyway.  This is how NFS works and
what applications expect.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)