disk fragmentation

[Charles Hedrick]

Today I called the Microport support people to see if they could do
something to help the slow startup I'm seeing for long programs,
particularly Emacs (actually Jove).  I suspected that the file system
was badly fragmented, and thus that the file was inefficiently ordered
on the disk.  They gave me some advice that I thought is worth passing
on.  Apparently System V doesn't bother to keep the free list in
order.  So after time, it begins to get randomized.  The result is
that reading a long file requires the disk drive to skip all around
the disk.  The only way to completely solve this problem is to
reorganize the disk: either do a backup, recreate the file system
(i.e. do the mkfs again) and reload from the backup, or use dcopy to
copy it to a fresh file system.  However fsck's -s option provides a
fairly good way of defragmenting a live file system.  Note that this
doesn't reorder files that are already randomized.  What it does do is
sort the free list.  So any new files you create after doing this are
reasonably organized.  What I tried was doing fsck -s, the copying a
few programs that seemed to be loading slowly, and finally renaming
the copy to the original name.  (Warning: copy all the files first,
before you get rid of any of the originals.  As soon as you remove any
of the originals, you'll be putting those random blocks right back
onto the free list.)  The result is that reading through emacs went
from 18 seconds to 4 seconds.  I used getblks (a program from the bbs
that shows the block numbers of all the blocks in a file) on both
copies of the file, and the difference is drastic.  I wouldn't quite
use the block numbers of the original as a random number generator,
but they do skip around alarmingly.  The copy has only a few jumps.
Presumably if I did a backup and restore things would be slightly
better yet, as those remaining jumps would be gone.  But it's much
easier to run fsck regularly than to dump the file system and restore
it regularly.

For those who find my wording ambiguous, he is roughly what I did to
defragment files /usr/local/bin/emacs and /usr/local/bin/kermit.  (I
didn't write the steps down as I did them, so something could be
missing, but this is fairly close.)

1) reboot from the standalone boot floppy
2) fsck /dev/rdsk/0s2.  Do this until it runs without errors
3) fsck -s /dev/rdsk/0s2.  This sorts the free list.
4) /etc/mount /dev/dsk/0s2 /mnt    (this is /usr)
5) cd /mnt/local/bin
6) cp emacs emacs.new
   cp kermit kermit.new
  ... etc. for the group I files I wanted to fix
   mv emacs.new emacs
   mv kermit.new kermit
  ... note that it is critical to do all the cp's before any of
  the mv's.
7) cd /
8) /etc/umount /dev/dsk/0s2
9) fsck -s /dev/rdsk/0s2.  (This is because the process above
   freed a bunch of files with random junk in them.  I wanted
   to start off with my free list in good shape.  This isn't
   strictly necessary.
10) sync
11) reboot from hard disk normally

This worked because there were just a few big files that needed to be
defragmented.  If I had a huge number of files that all were causing
performance problems, it would be easier to dump the disk and recreate
it.  Of course if I did the fsck -s regularly enough, I might be
able to prevent the problem in the first place.