Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!fstgds15.tu-graz.ac.at!fstgds01.tu-graz.ac.at!not-for-mail From: chmr@edvz.tu-graz.ac.at (Christoph Robitschko) Newsgroups: comp.os.386bsd.questions Subject: Re: fsck summary info bad after every shutdown Date: 22 May 1993 20:20:20 +0200 Organization: Technical University of Graz, Austria Lines: 47 Message-ID: <1tlqt4INN7ni@fstgds01.tu-graz.ac.at> References: <davidb.738071772@otto> NNTP-Posting-Host: fstgds01.tu-graz.ac.at X-Newsreader: TIN [version 1.1 PL7] In article <davidb.738071772@otto> David Burren [Athos] (davidb@otto.bf.rmit.oz.au) wrote: -> The recent posting by someone in Austria (sorry, I've forgotten the name -> right now) hinting that the timestamp in the filesystem's superblock is -> part of the key seems in line to me. -> -> The fact that setting the time in BSD currently doesn't seem to have -> much effect on the RTC in the machine certainly wouldn't help. -> I've written a patch to set the RTC from 386bsd, it can be found on ftp.tu-graz.ac.at:pub/386BSD/0.1/unofficial/time . It probably won't install cleanly on a pk-0.2.3 system (or NetBSD), but I don't want to spend any more time on it. -> -> > [I've seen posts mentioning to have a flag indicating that a FS is -> > 'clean' and get 'fsck' to ignore clean FS's, but I think that that -> > proposal is on the wrong track. fsck is correct in noting that the fs -> > is dirty, and you might get a program which stuffs up one day and -> > constantly marks your FS as ok, when it's not. I don't want to take -> > that risk.] -> -> Well, a number of commercial Unix vendors do it this way, including DEC -> with Ultrix. The idea is that the superblock's "clean" flag is set when -> the filesystem is unmounted (which assumes that the FS has no bugs and -> thus does not corrupt a filesystem during normal operation :-). -> -> During a `fsck -p` these filesystems are ignored. They are not ignored -> during a "normal" fsck, so it _is_ possible to catch the errors that the -> filesystem leaves behind, but you have to remember to do a manual fsck -> every now and then :-) I've modified fsck to check the clean bit, and ufs_mount and ufs_unmount in the kernel to clear and set the clean bit, respectively. It works fine after I manually unmount a partition, but my problem is that the filesystems are not unmounted automatically on a shutdown. -> -> Actually, they usually keep a reference count in the superblock that's -> decremented on each mount and reset by fsck, and after 20 or so mounts -> they force (or in Ultrix's case merely advise) a real fsck. -> -> Having this functionality certainly makes booting a machine much faster, -> and with the (dare I say it) stable ufs we have, a scheme using the -> above ideas seems quite sensible to me. Fully agreed. Christoph