From owner-freebsd-fs@FreeBSD.ORG Wed Oct 22 15:52:35 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 945FF16A4B3 for ; Wed, 22 Oct 2003 15:52:35 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9DBD43F3F for ; Wed, 22 Oct 2003 15:52:32 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 9BB6172DA8; Wed, 22 Oct 2003 15:52:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 99A6C72DA3; Wed, 22 Oct 2003 15:52:32 -0700 (PDT) Date: Wed, 22 Oct 2003 15:52:32 -0700 (PDT) From: Doug White To: Ken Marx In-Reply-To: <3F95D3F3.2050203@vicor.com> Message-ID: <20031022154631.H71676@carver.gumbysoft.com> References: <3F95D3F3.2050203@vicor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-fs@freebsd.org Subject: Re: 4.8 ffs_dirpref problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 22:52:35 -0000 Purge extensive cc:. On Tue, 21 Oct 2003, Ken Marx wrote: > We have 560GB raids that were sometimes bogging down heavily > in our production systems. Under 4.8-RELEASE (recently upgrated from 4.4) > we find that when: > > o the raid file system grows to over 85% capacity (with only > 30% inode usage) > o we create ~1500 or so 2-6kb files in a given dir > o (note: soft updates NOT enabled) Interesting problems and analysis. If I'm reading the diffs and source right, the old allocation algorithm exists at the end of the dirpref function, below the comment about the backstop. It would be interesting to wrap the rest of the function in a tunable so you could easily short-circuit to the backstop. I don't know if it could be done on a per-filesystem basis. You might just have to eat the old layout semantics for the entire system if we want to keep the cost of the tunable low. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org