From owner-freebsd-fs@FreeBSD.ORG Thu Oct 23 12:46:28 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 6C86A16A4B3 for ; Thu, 23 Oct 2003 12:46:28 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CDDF43FBD for ; Thu, 23 Oct 2003 12:46:27 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h9NJkQeN007683; Thu, 23 Oct 2003 12:46:26 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200310231946.h9NJkQeN007683@beastie.mckusick.com> To: Ken Marx In-Reply-To: Your message of "Thu, 23 Oct 2003 11:08:02 PDT." <3F981902.90607@vicor.com> Date: Thu, 23 Oct 2003 12:46:26 -0700 From: Kirk McKusick 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: Julian Elischer 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 19:46:28 -0000 Date: Thu, 23 Oct 2003 11:08:02 -0700 From: Ken Marx To: Julian Elischer CC: mckusick@mckusick.com, cburrell@vicor.com, davep@vicor.com, freebsd-fs@freebsd.org, gluk@ptci.ru, jpl@vicor.com, jrh@vicor.com, julian@vicor-nb.com, VicPE@aol.com Subject: Re: 4.8 ffs_dirpref problem X-ASK-Info: Confirmed by User 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 Unfortunately, I do believe that you will need to start over from scratch with a newfs. The problem is that by the time you are at 85% full with the old parameters, the directory structure is already too "dense" forcing you to search far and wide for more inodes. If you start from the beginning with a large filesperdir then your directory structure will expand across more of the disk which should approximate the old algorithm. Kirk McKusick