hedrick@athos.rutgers.edu (Charles Hedrick) (04/13/88)
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.