Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bruce.cs.monash.edu.au!monu6!escargot!otto!davidb From: davidb@otto.bf.rmit.oz.au (David Burren [Athos]) Newsgroups: comp.os.386bsd.questions Subject: Re: fsck summary info bad after every shutdown Date: 22 May 93 11:56:12 GMT Organization: Royal Melbourne Institute of Technology Lines: 48 Message-ID: <davidb.738071772@otto> References: <root.737640955@gimli> <1tk3raINN3h6@escargot.xx.rmit.OZ.AU> NNTP-Posting-Host: otto.bf.rmit.oz.au In <1tk3raINN3h6@escargot.xx.rmit.OZ.AU> s902113@minyos.xx.rmit.OZ.AU (Luke Mewburn) writes: > - NetBSD has a dirty fs after you've finished the major part of the > installation (which incidently, tells you to type 'reboot' to > start the whole thing going post-install). Maybe they should > recommend 'shutdown -h now' or 'reboot -q' until this problem is > solved. At this point of the proceedings the machine is really still in single-user, and traditionally `reboot` is the right thing to use at that point. By the way, I've seen 5 or so NetBSD installations take place, and in only one case was there a dirty filesystem detected during the boot cycle. 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 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 :-) 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. __ David B.