lehners@uniol.UUCP (Joerg Lehners) (09/07/89)
bob@wyse.wyse.com (Bob McGowen Wyse Technology Training) writes: >In article <1788@ncsp24Aug198920:30:10GMT jay@ncspm.ncsu.edu (Jay C. Smith) writes: >>From article <5176@ucdavis.ucdavis.edu>, by cck@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@DOLUNI1.BITNET | Ammerlaender Heerstrasse 114-118 | | UUCP/Eunet: lehners@uniol.uucp | D-2900 Oldenburg | +-------------------------------------+----------------------------------+ \ Unix-Wizards: let's zap away all stupid users. /