Date: Tue, 18 Apr 2006 10:35:05 -0700 (PDT) From: Mohan Srinivasan <mohan_srinivasan@yahoo.com> To: Alfred Perlstein <alfred@freebsd.org>, Xin LI <delphij@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, ps@freebsd.org, cvs-all@FreeBSD.org, mohans@freebsd.orgc Subject: Re: cvs commit: src/sys/nfsclient nfs_bio.c nfs_vnops.c Message-ID: <20060418173505.83522.qmail@web30803.mail.mud.yahoo.com> In-Reply-To: <20060418133832.GF35896@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> wrote: > * Xin LI <delphij@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060418173505.83522.qmail>