From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 18:01:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 99BA516A4CE; Wed, 20 Apr 2005 18:01:39 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3KHxkSc073470; Wed, 20 Apr 2005 13:59:46 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3KHxkf5073469; Wed, 20 Apr 2005 13:59:46 -0400 (EDT) (envelope-from green) Date: Wed, 20 Apr 2005 13:59:46 -0400 From: Brian Fundakowski Feldman To: Garrett Wollman Message-ID: <20050420175946.GL1157@green.homeunix.org> References: <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> <16998.37222.529748.205885@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16998.37222.529748.205885@khavrinen.csail.mit.edu> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 18:01:40 -0000 On Wed, Apr 20, 2005 at 01:29:10PM -0400, Garrett Wollman wrote: > < 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. So what _would_ be consistent for nfs_bio.c::nfs_write()? IO_UNIT is set for all write calls which means "atomic", and nfs_rslock() and O_APPEND appear to at least attempt this. Please take a detailed look at the current system and the changes... it's far less clear-cut than POLA dictates. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\