On Mon, 28 Oct 2002 23:02:32 -0600 (CST), Richard Rauch <rauch@rice.edu>
wrote:
> When I asked about FFS fragmentation in the past, I was assured that FFS
> doesn't substantially suffer from fragmentation-related performance
> problems.  (Due, apparently, to the scattering of files on the disk.)
> Unless your disk is skirting the limits of its capacity, I was told, the
> disk layout strategies generally don't suffer from this.  (I'd think
> that too much scattering would result in excessive seeks, even if it
> helped enable blocks to be written in long, contiguous runs.)

I'm absolutely sure I've seen fragmentation statistics from NetBSD, but I
can't seem to remember where.  "man -k frag" is no help, neither does
"fragment" appear on the man pages of fsck, df, du, mount.  It's not dmesg
output.  But I know I've seen it.  There's also a way to find the number
of segments of a given file.  

The number I see is always low, meaning nearly no fragmentation.  I'm not
surprised, knowing a little about filesystem strategies from DEC, Novell
and Microsoft, and having read some of the FFS (and LFS) papers.  After
all, when FFS was taking shape, seek times were an order of magnitude
higher than today's.  

On Mon, 28 Oct 2002 20:23:46 -0500 (EST), mcmahill@mtl.mit.edu wrote:
> 
> I'm asking because the time to extract a file on a 40 Gb drive with
> about 800Mb free that I have is horribly slow and I'm trying to figure
> out why.

So, you're looking at 2% free space?  What exactly is there to "figure
out"?  :)

Any file system reacts badly as you decrease its latitude to make optimal
choices.  Unless your 39.2 GB is static data and you really just want an
800 MB section to work with (in which case you would disklabel things
accordingly), defragging isn't your answer.  rm(1) and/or newfs(8) are.  

HTH.  

--jkl