cvs commit: src/sys/nfsclient nfs_bio.c nfs_vnops.c

[Mohan Srinivasan]

Alfred,

FYI - I am working on changes that would retain and re-dirty the
buffers on other NFS errors as well. For example, on an ESTALE, 
there's little point in retaining the buffers. But on reception 
of an ENOSPC, it might be worth retaining and re-dirtying the 
buffers, as space could free up on the server volume and a
subsequent retry of the write (say on the close()) could succeed.

The problem I ran into here is that various parts of the vfs don't
check for the return value of bwrite(). In particular, if getblk()
is called with a size that is different from the b_count (of the cached
buffer), getblk sets B_NOCACHE on the cached buffer and calls bwrite()
on it (so that the existing buffer is written out and discarded and a 
new buffer of the required size can be allocated). If bwrite() fails 
(and if NFS decides to retain and re-dirty the buffer), getblk() needs 
to check for the return value from bwrite() and return failure to its 
caller, and callers of getblk() need to handle the errors from getblk(). 
For now, I am experimenting with an alternate version of getblk() that 
only NFS uses.

mohan

--- Alfred Perlstein <alfred at freebsd.org> wrote:

> * Xin LI <delphij at FreeBSD.org> [060417 23:39] wrote:
> > delphij     2006-04-18 05:28:41 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:        (Branch: RELENG_6)
> >     sys/nfsclient        nfs_bio.c nfs_vnops.c 
> >   Log:
> >   MFC src/sys/nfsclient/nfs_bio.c,v 1.154
> >   and src/sys/nfsclient/nfs_vnops.c,v 1.262 (by ps@):
> >   
> ...
> >    - Treat ETIMEDOUT as a "recoverable" error, causing the buffer
> >      to be re-dirtied. ETIMEDOUT can occur on soft mounts, when
> >      the number of retries are exceeded, and we don't want data loss
> >      in that case.
> 
> Actually that's the documented behavior, if the mount times out,
> one will lose data.
> 
> What does this do?  Leave the buffer dirty/held until forcefully
> unmounted?  I guess that sort of makes sense, can someone explain
> a bit better?
> 
> -- 
> - Alfred Perlstein
>