Essentially, the UFS file system (and its close relatives) is
intentionally fragmented in a controlled way as the files are written,


exactly that was invented over 20 years ago and still it works perfect.

at sort-of-random locations all over the disk, rather than starting at

it's definitely NOT "sort of random".

it divides disk onto "cylinder groups". it puts new files to the same cylinder group as other files in the same directory, BUT when files grow large (like over 1MB) it FORCES the fragmentation by switching to other cylinder group.

the reason is simple - having file fragmented every few megs doesn't make a speed difference, while it keeps every cylinder group from filling out.

for small files there will be almost always space available in the same cyl group. seek time within cylinder group is in order of 2-3ms at most.

UFS from the beginning optimized for rotational delay too, by dividing tracks into multiple "angle zones", so if it has to fragment within cylinder group, it choose the space in the zone that after head movement it will be shortest rotational delay possible.
same for seeking between inode and file data.

unfortunately - modern drives hide real geometry, so such optimization doesn't work any more. this is quite a large loss, for 7200rpm drive one rotation is 9 ms, average rotational delay 4.5ms, could be half that or less with such optimization possible.

UFS does not just prevent fragmentation, it tries to manage it (as unavoidable thing) to make it's effect as little as possible.


all of this worked fine and efficient on about 1 MIPS computer like VAX, after that UFS was changed a lot, but this basic mechanism is still the same.

except extreme cases there is never need for defragmenting UFS filesystem!!!



the remaining space as efficiently as possible, at the cost of speed.

while it still can keep fragmentation quite low with much less space available (unless it's really close to 0%), this "low speed" means mostly higher CPU load when selecting blocks to allocate. on modern machines like
1Ghz or more it's difficult to see any difference.

large files, you can adjust some of the parameters (e.g. using
tunefs(8)) so the filesystem will handle large files more efficiently,
at the expense of wasting space on small files.

rather by newfs, by making huge blocks like -b 65536 -f 8192, and make MUCH less inodes (like -i 1048576)

still - it will lose about as much space then as FAT32 with 8kB clusters, which is AFAIK default for FAT32 on large drives.

with huge files, such settings may not only speed things a bit, but actually save space by not reserving that much for inodes and bitmaps.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to