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.