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.questions Subject: Re: what is fs_clean for? Date: 6 Oct 1993 21:00:03 GMT Organization: Advanced Computing Systems Company Lines: 53 Distribution: world Message-ID: <28vbkj$eua@acsc.com> NNTP-Posting-Host: cpuserver.acsc.com 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, 1. During the creation of a file, write synchronously the inode to the disk before updating the parent directory entry on the disk. 2. During the deletion of a file, update the parent directory entry on the disk first before freeing the on-disk inode. (The above rules will make sure that the directory entry is pointing to a valid inode even if the system crashes between 2 writes.) 3. To create a data block, write the data block to the disk first before writing the pointer to the data block in the inode or the indirect block to the disk. (This will make sure the pointer is pointing to a valid data block even though the system crashes between the 2 writes.) 4. To mkdir, write _synchronously_ the new inode first, then the parent inode (tp update the di_nlink), then the new directory. Finally, update the parent directory. I believe this is what the current UFS does. (This will make sure that the directory and inode are pointing to valid stuff even if the system crashes.) and so on. However, in rule #4, the di_nlink of a parent directory may not be correct if the system crashes right before the parent directory is updated on the disk. The parent directory will not have the new entry, but the di_nlink of the parent inode will have been increased. The result is that the parent directory cannot be removed before fsck is run. This is not a disaster. What is a disaster is that an inode points to some wrong data block or a directory entry points to an invalid inode. So, 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 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. 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. Jerry Chen