Earthmen are sooo clever

[Joerg Lehners]

bob at wyse.wyse.com (Bob McGowen Wyse Technology Training) writes:
>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):
>>[some text delete]

>[text about -s option deleted]

>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!).

I really hope that you umount the filesystem before running any fsck.

I'm told (and I have the experience :-() that a fsck -s on a mounted
filesystem *can* be very dangerous. This is because the kernel has it's
own copy of parts of the free list. If you run fsck -s, it modifies
the free list thru the block special or character special device WITHOUT
telling the kernel to throw away the possibly now invalid in core version
of some parts of the free list.
Another risk is: fsck (at least the fsck on the machine I use) automatically
clears all inodes of unreferenced (but possibly still used) files
(if the files has 0 reference and isn't open, this is due to some kernel
bugs or machine crashes).
Ie: all unnamed pipes and unlinked but still openend files.
The risk here: the blocks used by the so cleared files are put back into
the free list, but there may still be writes on these blocks !!

There is another risk with accesses to the character special (raw)
device of the disk while the filesystem is mounted: accesses to the
filesystem's files or the block special device go thru the buffer cache
of the kernel. Accesses to the raw device don't.
A write to the raw divice may invalidate the buffer cache, and if some
page of the buffer cache is marked dirty (ie: has to be written to the
disk) a previous write to the raw device may be undone by the page in
the buffer cache.

>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.
This is right, but the work is enourmous on really big disks and small
backup media (not the 'intelligent' work, just the 'waiting' work).

>I am running XENIX 2.3.2 on a 386 system with ESDI 150M HD.
I use Campus machines with Munix V.3 and 387 MB SMD HD.

  Joerg
--
/ Joerg Lehners                       | Fachbereich 10 Informatik ARBI   \
|                                     | Universitaet Oldenburg           |
| BITNET/EARN: 066065 at DOLUNI1.BITNET  | Ammerlaender Heerstrasse 114-118 |
| UUCP/Eunet:  lehners at uniol.uucp     | D-2900 Oldenburg                 |
+-------------------------------------+----------------------------------+
\          Unix-Wizards: let's zap away all stupid users.                /