Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!yoyo.aarnet.edu.au!myall.awadi.com.au!myall!blymn From: blymn@awadi.com.au (Brett Lymn) Newsgroups: comp.os.386bsd.questions Subject: Re: what is fs_clean for? Date: 3 Oct 93 17:56:36 Organization: AWA Defence Industries Lines: 59 Message-ID: <BLYMN.93Oct3175636@mallee.awadi.com.au> References: <28fmis$12b9@acsc.com> <28hoa4$ccg@umd5.umd.edu> NNTP-Posting-Host: mallee.awadi.com.au In-reply-to: mark@elea.umd.edu's message of 1 Oct 1993 17:10:28 GMT >>>>> On 1 Oct 1993 17:10:28 GMT, mark@elea.umd.edu (Mark Sienkiewicz) said: Mark> NNTP-Posting-Host: elea.umd.edu Mark> In article <28fmis$12b9@acsc.com>, Jerry Chen <jerry@acsc.com> wrote: >During the mount time, what should be done if the file system is not clean? >Should the mount request be rejected or should the mount succeed? Thanks >for the answer. Mark> There are two answers to this: Mark> WRONG: Reject the mount of filesystems that are not clean. Mark> RIGHT: Mount it anyway. Mark> You may detect a bit of bias in my statements. :) And IMHO you are wrong :-) Mark> The argument for rejecting it is that you don't know that the filesystem Mark> is clean - by mounting it, you can make it worse. Also, you might have Mark> a detrimental effect on the rest of the system. Exactly. Mark> The argument for allowing the mount is that the filesystem probably is not Mark> in very bad shape. You can *safely* run for *months* with blocks missing Mark> from the free list or unreferenced inodes allocated. So I don't want my Mark> entire system failing (e.g. can't mount /usr) because I lost a temporary file. Similarly I do not want my system crashing down around my ears some months down the track because a block allocated to /usr/bin/login just happened to make it's way onto the free list. Mark> I also don't like systems that say "I won't do what you told me to do because Mark> somebody programmed me to be smarter than you". Computers that say that Mark> are lying. True in some cases but you would have a difficult time convincing me that you could inspect a file system and tell me that there are no inconsistencies that are not going to cause a catastrophe later. Mark> Maybe *I* know that the damage is not bad enough to prevent me Mark> from doing what I want to do. And how would you know this? Mark> Ideally, one of these two behaviours could be selected by an option in Mark> the config file. e.g. Mark> options NO_MOUNT_DIRTY # behaviour I thought was wrong Mark> # but some people might like Nope, better would be to make fsck (and other fs tools) pay attention to the fsclean flag, if the fs is clean then the fsck justs exits otherwise fsck does it's stuff. The only dodgy is handling the / filesystem but that one is special anyway (just consider which filesystem the / mount point is in....). -- Brett Lymn