File system performance

[David S. Herron]

In article <1990Nov5.222733.11408 at unixland.uucp> bill at unixland.uucp (Bill Heiser) writes:
>In article <1990Nov3.222929.2164 at servalan.uucp> rmtodd at servalan.uucp (Richard Todd) writes:
>>  Well, that's how FFS works on other machines (I've hit it on Apple Unix
>>2.0, which includes Berkeley FFS).  Hitting the no-free-blocks limit when
>>you've got 5M free in fragments is a little unusual; I was hitting the

That 10% limit is a heuristic invented when Berkeley invented FFS
designed to help keep fragmentation down.

>Is there something that can be done "on-line" to de-fragment Unix partitions?

Theoretically, yes.  It would work best if the disk were `unmounted'
first which is easiest to do if the system were brought to single user.
It would also require writing software which would first sort the
free list, then reorder all the data blocks into as contiguous an
order as possible.  The method is left as an excercise to the reader.

If Unix were multitasking internally (as Mach is) then I can imagine
an addition to either the disk driver or file system driver which
would run as a seperate `thread', at very low priority, and do file
system optimization in the background.  Since it would run at low
priority it would only snarf up idle time ...

>Or is the best bet to just backup and restore the partition using something
>other than 'dump'?  

This will work -- assuming you're using `tar' or `cpio'.

>  (I haven't done anything with the Esix
>"2K file system utility" yet -- I'm not sure what is on that disk-- been too
>busy to experiment...)

All the 2K file system is is the same old V7 file system with some
constants changed to confuse the innocent.  It's no great stride
forward in understanding the Universe .. it has most of the same
performance features & limitations (eg, it fragments quickly and doesn't
work well with largeish partitions since the inodes are all stuck
at one end of the partition) as the .5K and 1K file systems.

The difference is that the basic unit of allocation is a 2Kbyte block.

Therefore each each data block in an inode refers to twice as much
data as a 1K file system.

Therefore you can have more data in a file before you get to indirect
or doubly indirect blocks.

Therefore a read returns more data (inside the kernel) so you tend to
get a little more read ahead effect.

Therefore it's suitable for file systems where you intend to store
lots of largeish files.

Perhaps (guess) it would also be good for file systems where you
intend to store lots of 1K<"file_size"<2K files since then all the
data in the file would be stored in one data block.  This might
have a positive effect on fragmentation ..

-- 
<- David Herron, an MMDF & WIN/MHS guy, <david at twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david at ms.uky.edu>
<-
<- Use the force Wes!