Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!news.crd.ge.com!sunblossom!knight.vf.ge.com!news.ge.com!combs!steve From: steve@@salem.ge.com (Stephen F. Combs) Newsgroups: comp.os.386bsd.questions Subject: Re: what is fs_clean for? Date: 11 Oct 1993 16:49:13 GMT Organization: GE Drive Systems, Salem, VA Lines: 80 Distribution: world Message-ID: <29c2q9$32v@alva.ge.com> References: <BLYMN.93Oct3175636@mallee.awadi.com.au> Reply-To: steve@@salem.ge.com NNTP-Posting-Host: 3.29.5.200 In article 93Oct3175636@mallee.awadi.com.au, blymn@awadi.com.au (Brett Lymn) writes: >>>>>> 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 Not to sound pedantic, or start a flame-war, BUT you should NEVER mount a filesystem which is suspect UNTIL you have cleaned it up. I've seen too many times when a system will barf at the LEAST acceptable time if you attempt to bypass stability checks. --- ======================================================================= Stephen F. Combs GE Industry Sales & Services My Employer is in NO way GE Drive Systems Responsible or Liable for Network Services Any Opinions expressed by 1501 Roanoke Blvd. Myself. Salem, VA 24153 Internet E-Mail: CombsSF@Salem.GE.COM Novell via Internet: Combs-SF@Salem.GE.COM =======================================================================