From owner-freebsd-stable@FreeBSD.ORG Tue Apr 26 19:36:03 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 523C416A4CE; Tue, 26 Apr 2005 19:36:03 +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 j3QJa2FF019574; Tue, 26 Apr 2005 15:36:02 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3QJa2pg019573; Tue, 26 Apr 2005 15:36:02 -0400 (EDT) (envelope-from green) Date: Tue, 26 Apr 2005 15:36:02 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050426193602.GE5789@green.homeunix.org> References: <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <16998.36437.809896.936800@khavrinen.csail.mit.edu> <20050420173859.GA99695@stack.nl> <20050426140701.GB5789@green.homeunix.org> <20050426151751.GB68038@stack.nl> <20050426155043.GC5789@green.homeunix.org> <20050426160609.GA68511@stack.nl> <20050426162549.GD5789@green.homeunix.org> <20050426164346.GA68763@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050426164346.GA68763@stack.nl> User-Agent: Mutt/1.5.6i cc: freebsd-stable@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 19:36:03 -0000 On Tue, Apr 26, 2005 at 06:43:46PM +0200, Marc Olzheim wrote: > [changed cc: from standards@ back to stable@ again.] > > On Tue, Apr 26, 2005 at 12:25:49PM -0400, Brian Fundakowski Feldman wrote: > > You can assure that this happens in only two ways: > > > > 1. Make a complete copy of the data. This is what currently occurs: > > it gets stuffed into the buffer cache as the write happens. > > 2. Keep the data around synchronously -- by virtue of the write system > > call being used synchronously, the thread's VM context is around, > > and duplication need not occur. > > It seems as though FreeBSD 4.x either used 2) or does something wrong > indeed. Why would 2) be a problem on FreeBSD 5.x ? Can't the pages > written from be locked during the write, instead of copied internally ? I'm still guessing that for whatever reason your writes on the FreeBSD 4.x NFS client are not using NFSv3/transactions. The second method I just now implemented; it works fine except for being slower since all data is acknowledged synchronously. Are you using one writev() instead of many writes so you can atomically write a large sparse data structure? If so, you will probably just have to cope with the lower performance than for reasonably-sized writes. If not: why are you trying to write it atomically? Just use multiple normal-sized write() calls. > Btw. running the writev program with 20 * 100 MB on UFS on a 512MB > FreeBSD 6-CURRENT system practicly locks the filesystem down _and_ > causes all processes to be swapped out in favor of the buffer cache. > 'top' however, doesnt' show a rise in BUF usage. > > On FreeBSD 4.x, the system performance as usual during the writev to > UFS. That's certainly not very optimal. I don't know anything about it, sorry. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\