Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!library.ucla.edu!agate!howland.reston.ans.net!pipex!uunet!haven.umd.edu!umd5.umd.edu!elea.umd.edu!mark From: mark@elea.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.questions Subject: Re: what is fs_clean for? Date: 5 Oct 1993 15:17:51 GMT Organization: Zeno, IPST, University of Maryland Lines: 41 Message-ID: <28s36v$op3@hecate.umd.edu> References: <28fmis$12b9@acsc.com> <28hoa4$ccg@umd5.umd.edu> <BLYMN.93Oct3175636@mallee.awadi.com.au> NNTP-Posting-Host: elea.umd.edu In article <BLYMN.93Oct3175636@mallee.awadi.com.au>, Brett Lymn <blymn@awadi.com.au> wrote: > >Mark> You may detect a bit of bias in my statements. :) > >And IMHO you are wrong :-) Of course you think I'm wrong! :) >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? I know this by knowing what has happened since the last fsck. That, coupled with knowledge of how the filesystem driver works, gives me an idea of what the damage to the filesystem could be. >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....). I'm proposing that fsck *always* honor the fs_clean flag. Thus, in normal operations, the filesystem is always either clean or it gets checked. I also think that you should be able to mount a dirty read-only media if you want to. For example, I've had disks that I have absolutely no intention of cleaning-- I just want to get some files off them before I run newfs to fix it up. (One example had around 8100 bad files due to a failing disk controller writing garbage.) Of course, this example also brings up an argument why you shouldn't have fs_clean at all-- just because the host thinks the disk is ok doesn't mean the disk controller *really* wrote the data correctly. The filesystem might still be trashed. That's why you should run fsck once in a while, even if it is marked clean. Anyway, I think that we aren't really that far apart.