Disk fragmentation

Paul De Bra debra at alice.UUCP
Mon Sep 12 06:29:27 AEST 1988


In article <116 at telmail.UUCP> Richard writes:
>>Can fragmentation cause severe performance degradation on SCO XENIX?
I did some testing: create a small c-program which opens 2 files and
writes blocks (1k or so) to each of them, alternating between the 2 files.
Create a few megabytes of data this way, then delete the files. On some
particular system I measured about 10 seconds per megabyte with a new file
system.
Repeat this process for a few hours (just a few hours!!!!), the time quickly
exceeded half a minute per megabyte. So YES performance degrades.
Solutions?
1) Use separate file systems for heavily used directory subtrees like /tmp
   and /usr/spool.
2) If you know how to do it and have lots of memory, use a ramdisk for /tmp,
   but do not use SCO's ramdisk. A quick hack is all it takes to write your
   own ramdisk driver which is 3 times faster. A plain vanilla 286 AT needs
   only 3 to 4 seconds per megabyte on a (Xenix) ramdisk.
3) Run fsck -S frequently on heavily used file systems, to rearrange the free
   list. (don't do this while a file system is mounted!)
4) If you really want your baby to fly: have /etc/rc copy your most popular
   programs (C-compiler and its passes for instance, and vi or emacs...)
   to a ramdisk. You'd be amazed about the performance gain. (don't forget
   to include the directory you mount the ramdisk on in your PATH, before
   /bin and /usr/bin).

This degradation is not typical a Xenix problem: all V7 file systems suffer
from this problem. Getting faster disks and using large buffer pools doesn't
help a bit. The overall performance gets better, but the difference between
a new and an old file system remains.

I don't know about the degradation in uport Unix. I did run my test once
on a 286 machine, and on a new file system the test took already longer than
on an old Xenix file system...

Paul.



More information about the Comp.unix.xenix mailing list