Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Nov 2001 13:23:52 -0500
From:      Bill Moran <wmoran@potentialtech.com>
To:        Daniel Lang <dl@leo.org>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: dirpref benefit on virtual disks
Message-ID:  <3BF013B8.8070009@potentialtech.com>
References:  <20011112152726.A10505@atrbg11.informatik.tu-muenchen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
[since I've yet to see any other replies]

Daniel Lang wrote:
> Hi,
> 
> as I understood, the new dirpref algorithm can improve
> performance a lot, but only applies to new created directories.
> To be able to use it, old existing directories would have to
> be created new.

That's consistent with my understanding of it.


> Now I have some huge filesystems on RAID partitions. To recreate
> all their directories involves some hassle, but I would think
> about doing it. But since these are no real but virtual disks,
> spread over a set of disks in a hardware raidbox, I'm not sure, 
> if I would even benefit from the better algorithm. It sounded
> a bit like designed for filesystems on a (single?) disk?

My thought would be that, yes, it will improve performance.  If
you've got a typical 3 disk, RAID-5, a read of the directory still
causes a seek on all three disks, and if there's continual seeking
across the three disks, you'll see performance degredation.  If
dirpref can layout the directory info so that it's close together,
seek time is reduces, whether on 3 disks or one.
That being said, I don't _know_.  It would be interesting to test
it.  Since you're already considering recreating directories, why
not do a test to see if it's worth it?  Just take a directory tree
that's pretty complicated and that was created before you updated
the dirpref code.  Run a find operation of some sort that traverses
the tree and time it.  Then, back that tree up and recreate it,
re-run the find and time it again and let everyone know if it's
worth it.  You only need do this with one section of a tree on the
drive to determine how much difference it's going to make.

> Also I would like to know, if there is a certain limit of free
> space, on the disk, so that the algorithm can actually use
> the better layout? The disks have some space left, in an
> absolute way, but not that much from a relative point of view
> (like 12GB left which is just 6% minfree not taken into account).

Have a read of the original paper on FFS (which is in /usr/share/doc
if you installed docs with FreeBSD) there is an explanation of why
8% is reserved on the drive - man tunefs comments about this as well.
I would assume that the new dirpref code needs plenty of free space
to use the optimal layout policy, but I don't know if the minimal
free space is still 8% or not, and I don't know if anyone has even
tested the new dirpref code to see if that number has changed.

-- 
Bill Moran
Potential Technology
http://www.potentialtech.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BF013B8.8070009>