From owner-freebsd-fs@FreeBSD.ORG Thu Oct 23 11:12:57 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 BDABB16A4C0 for ; Thu, 23 Oct 2003 11:12:57 -0700 (PDT) Received: from sploot.vicor-nb.com (sploot.vicor-nb.com [208.206.78.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3EE443FB1 for ; Thu, 23 Oct 2003 11:12:56 -0700 (PDT) (envelope-from kmarx@vicor.com) Received: from vicor.com (localhost [127.0.0.1]) by sploot.vicor-nb.com (8.12.8/8.12.8) with ESMTP id h9NI82T1050765; Thu, 23 Oct 2003 11:08:02 -0700 (PDT) (envelope-from kmarx@vicor.com) Message-ID: <3F981902.90607@vicor.com> Date: Thu, 23 Oct 2003 11:08:02 -0700 From: Ken Marx User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20031023171932.9F36C7A425@mail.vicor-nb.com> In-Reply-To: <20031023171932.9F36C7A425@mail.vicor-nb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 25 Oct 2003 07:10:35 -0700 cc: freebsd-fs@freebsd.org cc: cburrell@vicor.com cc: julian@vicor-nb.com cc: davep@vicor.com cc: VicPE@aol.com cc: jpl@vicor.com cc: gluk@ptci.ru cc: jrh@vicor.com cc: mckusick@beastie.mckusick.com 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: Thu, 23 Oct 2003 18:12:58 -0000 Thanks for the reply, We actually *did* try -s 4096 yesterday (not quite what you suggested) with spotty results: Sometimes it seemed to go more quickly, but often not. Let me clarify our test: We have a 1.5gb tar file from our production raid that fairly represents the distribution of data. We hit the performance problem when we get to dirs with lots of small-ish files. But, as Julian mentioned, we typically have many flavors of file sizes and populations. Admittedly, our untar'ing test isn't necessarily representitive of what happens in production - we were just trying to fill the disk and recreate the problem here. We *did* at least hit a noticeable problem, and we believe it's the same behavior that's hitting production. I just tried your exact suggested settings on an fs that was already 96% full, and still experienced the very sluggish behavior on exactly the same type of files/dirs. Our untar typically takes around 60-100 sec of system time when things are going ok; 300-1000+ sec when the sluggishness occurs. This time tends to increase as we get closer to 99%. Sometimes as high as 4000+ secs. I wasn't clear from your mail if I should newfs the entire fs and start over, or if I could have expected the settings to make a difference for any NEW data. I can do this latter if you think it's required. The test will then take several hours to run since we need at least 85% disk usage to start seeing the problem. Thanks! k Julian Elischer wrote: >>From mckusick@beastie.mckusick.com Wed Oct 22 22:30:03 2003 >>X-Original-To: julian@vicor-nb.com >>Delivered-To: julian@vicor-nb.com >>To: Ken Marx >>Subject: Re: 4.8 ffs_dirpref problem >>Cc: freebsd-fs@freebsd.org, cburrell@vicor.com, davep@vicor.com, >> jpl@vicor.com, jrh@vicor.com, julian@vicor-nb.com, VicPE@aol.com, >> julian@vicor.com, Grigoriy Orlov >>In-Reply-To: Your message of "Wed, 22 Oct 2003 12:57:53 PDT." >> <20031022195753.27C707A49F@mail.vicor-nb.com> >>Date: Wed, 22 Oct 2003 16:37:54 -0700 >>From: Kirk McKusick > > >>I believe that you can dsolve your problem by tuning the existing >>algorithm using tunefs. There are two parameters to control dirpref, >>avgfilesize (which defaults to 16384) and filesperdir (which defaults >>to 50). I suggest that you try using an avgfilesize of 4096 and >>filesperdir of 1500. This is done by running tunefs on the unmounted >>(or at least mounted read-only) filesystem as: > > >> tunefs -f 4096 -s 1500 /dev/ > > > On the same filesystem are directories that contain 1GB files > and others that contain maybe 100 100K files (images) > > > >>Note that this affects future layout, so needs to be done before you >>put any data into the filesystem. If you are building the filesystem >>from scratch, you can use: > > > would this have an effect on an existing filesystem with respect to new data > being added to it? > > > > > >> newfs -g 4096 -h 1500 ... >> >>to set these fields. Please let me know if this solves your problem. >>If it does not, I will ask Grigoriy Orlov if he has >>any ideas on how to proceed. > > >> Kirk McKusick > > >>=-=-=-=-=-=-= > > > -- Ken Marx, kmarx@vicor-nb.com It's too costly to get lean and mean and analyze progress on the diminishing expectations. - http://www.bigshed.com/cgi-bin/speak.cgi