Date: Wed, 20 Apr 2005 13:29:10 -0400 From: Garrett Wollman <wollman@csail.mit.edu> To: Brian Fundakowski Feldman <green@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock Message-ID: <16998.37222.529748.205885@khavrinen.csail.mit.edu> In-Reply-To: <20050420155233.GJ1157@green.homeunix.org> References: <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 20 Apr 2005 11:52:33 -0400, Brian Fundakowski Feldman <green@FreeBSD.ORG> said: > I think the first is more useful behavior than the last. Supporting it > should be exactly the same as supporting what happens if the actual > filesystem fills up. In this case, the filesystem is being requested to > write more "than there is room for." Returning a short write for operations on regular files would definitely be considered astonishing. The changes that you have made should be considered flow control, not admission control, and should appear to the user no differently than if we were waiting for a slow disk to write something; i.e., the user thread should be blocked until either the entire write completes, or the process is interrupted by a signal. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16998.37222.529748.205885>