*BSD News Article 21839


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!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: 4 Oct 1993 19:55:30 GMT
Organization: Zeno, IPST, University of Maryland
Lines: 56
Message-ID: <28pv3i$1ch@hecate.umd.edu>
References: <28fmis$12b9@acsc.com> <28hoa4$ccg@umd5.umd.edu> <28iv78$1s6b@cpuserver.acsc.com>
NNTP-Posting-Host: elea.umd.edu

In article <28iv78$1s6b@cpuserver.acsc.com>,
Frank Mayhar <fmayhar@acsc.com> wrote
an argument for a different perspective on fs_clean and fsck:

>In article <28hoa4$ccg@umd5.umd.edu>,
>Mark Sienkiewicz <mark@elea.umd.edu> wrote:
>>The argument for allowing the mount is that the filesystem probably is not
>>in very bad shape.  You can *safely* run for *months* with blocks missing
>>from the free list or unreferenced inodes allocated.  So I don't want my
>>entire system failing (e.g. can't mount /usr) because I lost a temporary file.
>
>Yes, but.  What is stopping you from running fsck, hmm?  Certainly you must
>always mount root, but fsck should *always* be run before mounting a file
>system like /usr, and if it's a nonessential filesystem (in terms of system
>operation, not in terms of your application, of course), the mount failure
>should just tell you "Gee, I forgot to run fsck -- I better do that now."

If fsck should *always* be run, then you don't need fs_clean.  The whole
point is in finding a way to skip some fsck's.  How much you can do this
is dependent on the amount of risk you are willing to take.  For example,
before I wrote the fs_clean, I removed the fsck command from /etc/rc and
ran it manually once in a while.  For many systems, this is adequate.

When I do kernel hacking, I sometimes put a few lines at the top of /etc/rc
that say
	mount -a 
	update
	csh
and build/boot/crash 4 or 5 kernels between fsck's.  This was how I eventually
gathered enough evidence to know what was wrong with a not-really-16550
compatible serial board.

>>I also don't like systems that say "I won't do what you told me to do because
>>somebody programmed me to be smarter than you".   Computers that say that
>>are lying.  Maybe *I* know that the damage is not bad enough to prevent me
>>from doing what I want to do.
>
>Maybe *you* know that, but the *system* doesn't know that.

Yeah, but I'm running the thing.  And if I'm not, the fsck in /etc/rc
will see that fs_clean is not set and fsck the partition.

>>Ideally, one of these two behaviours could be selected by an option in
>>the config file.  e.g.
>
>No, it should be an option on the mount, e.g. -f (force), if that's not
>already taken.  Then change the mount vfsop to look for a 'force' flag
>as passed in the flags parameter of the mount syscall (this is true in
>AIX, the system I have at hand, I'm not sure about *BSD, and I don't
>have one easily available).  If force is clear and the fs is dirty,
>fail the mount, else do it anyway.

What you suggest is not incompatible with what I suggested.  In my 
configuration, "-f" wouldn't mean anything, but without the option,
it would still provide the safety net you are describing.