Re^2: Earthmen are sooo clever

[Bob McGowen Wyse Technology Training]

In article <1788 at ncsp24Aug198920:30:10GMT jay at ncspm.ncsu.edu (Jay C. Smith) writes:
>From article <5176 at ucdavis.ucdavis.edu>, by cck at deneb.ucdavis.edu (Earl H. Kinmonth):
>> On some systems, such as SCO Xenix, an approach such as the following
>> has the effect of defragmenting file systems.
>> (a)	backup up the file system you want to defragment (or at least
>> major directory trees in that system);
>> (b) verify the backup;
>> (c) remove the backed up files;
>> (d) fsck -s
>> (e) restore from the back up.
>
>A faster alternative to steps c and d is mkfs.  This will have the effect
>of removing all files and rebuilding the free list and it runs a lot
>faster than "rm -fr *" fo

A point to remember is that the -s and -S options to fsck only reorganize
the free list.  This puts the blocks in sequence but there WILL STILL be
gaps.  Thus it reduces but does not eliminate fragmentation unless all
files are first removed, as noted by Earl in his comment above.

Another factor affecting the degree of defragmentation would be the
frequency with which the fsck is run.  I have set up a cron entry that
runs it with the -S option on a daily basis (in the wee hours of the
morning).  The -S form will only reorganize the free list if there are no
problems found in the file system structure and can be run while in
multi-user mode without apparent problems (I have been doing this for
nearly a year now.  If anyone has any info on why I shouldn't, I'd sure
like to know!).

It is still worthwhile to occasionally backup ALL files in an fs and do
the mkfs on it, but the method I've outlined has helped keep my system
relatively free of fragmentation problems longer than without it.

I am running XENIX 2.3.2 on a 386 system with ESDI 150M HD.

Bob McGowan  (standard disclaimer, these are my own ...)
Customer Education, Wyse Technology, San Jose, CA
..!uunet!wyse!bob
bob at wyse.com