*BSD News Article 22091


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!acsc.com!acsc.com!jerry
From: jerry@acsc.com (Jerry Chen)
Newsgroups: comp.os.386bsd.development
Subject: mount a dirty file system without fsck (was Re: what is fs_clean for?)
Date: 8 Oct 1993 16:46:11 GMT
Organization: Advanced Computing Systems Company
Lines: 40
Distribution: world
Message-ID: <2945gj$i0h@acsc.com>
NNTP-Posting-Host: cpuserver.acsc.com

As I learn more and more from the UFS source code, it seems 
dangerous to me if we allow the BSD system to mount a dirty UFS file system.  
Here is one problem:

If we are writing a file _synchronously_ and the system crashes for some
reason, here is one of the situations that can happen.
 
Say, the system crashes right after the uiomove() in ufs_write().  Assume the
user is writing a new block, say, logical block # 20.  Then, since the data
block on the disk has not been updated on the disk, it will look like this on
the disk:

   valid inode1 ----> valid indirect block ----> obsolete data block

The problem is that the block map is written by bdwrite() in alloccg().  So,
the block map may not be updated on the disk yet.  fsck will find the 
inconsistency between the data block and the map and update the map hopefully
(to tell the truth, I have not read the fsck code yet).

Now, if we mount the dirty UFS file system without fsck first.  The same data 
block can be allocated again.  So, another file may also use the block as the
following:

   valid inode1 ----> valid indirect block ----> obsolete data block <---+
                                                                         |
                                                                         |
   valid inode2 ----> valid indirect block ------------------------------+

In this case, the file system is in an inconsistent state.

To fix the problem and allow the BSD to mount a dirty UFS file system, it
seems to me we need to update the map synchronously in alloccg().  Of
course, if we start to update the disk synchronously in more and more 
places, we will lose the performance.  In the write path in which
the performance is very important, it is not a good solution.  Therefore,
we may have to reject the mount of a dirty UFS file system.

Please correct me if I missing anything.  Thanks.

Jerry Chen