4.8 ffs_dirpref problem

[Julian Elischer]

> From mckusick at beastie.mckusick.com  Wed Oct 22 22:30:03 2003
> X-Original-To: julian at vicor-nb.com
> Delivered-To: julian at vicor-nb.com
> To: Ken Marx <kmarx at vicor.com>
> Subject: Re: 4.8 ffs_dirpref problem 
> Cc: freebsd-fs at freebsd.org, cburrell at vicor.com, davep at vicor.com,
> 	jpl at vicor.com, jrh at vicor.com, julian at vicor-nb.com, VicPE at aol.com,
> 	julian at vicor.com, Grigoriy Orlov <gluk at ptci.ru>
> In-Reply-To: Your message of "Wed, 22 Oct 2003 12:57:53 PDT."
>              <20031022195753.27C707A49F at mail.vicor-nb.com> 
> Date: Wed, 22 Oct 2003 16:37:54 -0700
> From: Kirk McKusick <mckusick at beastie.mckusick.com>

> 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/<disk for my broken filesystem>

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 <gluk at ptci.ru> if he has
> any ideas on how to proceed.

> 	Kirk McKusick

> =-=-=-=-=-=-=