Fast reboot & Disk fragmentation

John R. MacMillan john at chance.UUCP
Fri Apr 26 14:35:39 AEST 1991


|First, I seem to remember that someone made a simple modification
|(somewhere) so that when shutting the system down normally, a key word
|is written to a key file, so that, upon subsequent rebooting, fsck need
|not be run (greatly speeding up the reboot process).

There are a couple of approaches you can take.  Be warned that any of
them have a very small window where the system could crash, and an
fsck would not be done, even though it probably should.

I took a fairly simple approach.  I modified /etc/shutdown so that if
given the -f (fastboot) option, after it thinks the system is
basically down, it touches /etc/fastboot.  On reboot, if this file is
present, it is removed and the fsck is skipped.

Some time ago, Lenny and Gil posted a more thorough set of stuff that
takes a slightly different approach, and is much more useful if you
have multiple partitions.

|Second, my disk is getting to the 60-70% full range, and things are
|starting to slow down.  Are there any suggestions for defragmentation?

The simplest thing to do is fsck -s the disk every now and again.
This will rebuild the freelist, so new things will not be as
fragmented, but will not help with existing fragmentation.

There is a program available, the name of which escapes me, that
claims to defragment a filesystem in place.  I have never tried it so
I can't comment on whether it works.  It's the kind of thing, though,
that I wouldn't want to do without making a backup, which means you
may not save much effort.

What I do involves a program called fsanalyze which reports (among
other things) the top 10 fragmented files.  I have it on a customized
floppy file system.  I boot from floppy, fsck -s, run fsanalyze.  Then
I copy the fragmented executables (all of them), move them all back,
and fsck -s again.  A couple iterations of this does not take long and
will take care of the most fragmented executables.

I tend to do this when I put in big things that I suspect will be
fragmented and are important to me.  For example, gcc is big, and I'm
low enough on disk space that by the time I get it fix-pointed, it's
probably pretty fragmented, and I want it to load as quickly as
possible.




More information about the Comp.sys.3b1 mailing list