*BSD News Article 22036


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: 7 Oct 1993 16:09:56 GMT
Organization: Zeno, IPST, University of Maryland
Lines: 36
Message-ID: <291f0k$8a1@hecate.umd.edu>
References: <28vbkj$eua@acsc.com>
NNTP-Posting-Host: elea.umd.edu

In article <28vbkj$eua@acsc.com>, Jerry Chen <jerry@acsc.com> wrote:
>It seems to me that if the file system code always makes the file
>system "consistent", then we can mount the file system even though
>it was not umounted cleanly.  By "consistent", I mean that the code
>follows some conservative rules, eg,

...several good rules were here...

>1. I agree with Mark Sienkiewicz that we should allow the mount even if
>   the file system is not clean (as long as we follow some conservative

Wow!  I knew if I stated the obvious for long enough, somebody would
agree with me. :) :) :)

>   rules).  However, after this mount, if we then umount successfully, then
>   the file system will look clean, even though some of the di_nlink may
>   be incorrect.  In that case, we will need to run fsck once in a while.

This is true.  Perhaps it would be better to save the fs_clean value
and put back the original value.  That way, mounting and then unmounting
a dirty filesystem doesn't make it look clean.

>2. If some file system code (say, you are implementing a new file system)
>   does not follow those conservative rules and it relies on the fsck if
>   the system crashes, ie, the file system may not be "consisten" after
>   the system crashes, then the code should reject the mount if file system
>   is not clean.

Even SVR4 does this. :)  I haven't closely checked the existing filesystem,
but BSD systems in general observe the right rules.

And here's another idea-- some systems let you defer *all* writes to improve
disk performance.  Of course, if you do this, you *must* run fsck on
*all* filesystems on reboot, because you don't even know that the
clean flag got written back out...