Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!cs.utexas.edu!uunet!yeshua.marcam.com!zip.eecs.umich.edu!umn.edu!csus.edu!netcom.com!adler From: adler@netcom.com (Bruce Adler) Subject: Re: mount a dirty file system without fsck (was Re: what is fs_clean for?) Message-ID: <adlerCEr6pt.Jwx@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <2945gj$i0h@acsc.com> Date: Mon, 11 Oct 1993 22:05:52 GMT Lines: 25 In article <2945gj$i0h@acsc.com> jerry@acsc.com (Jerry Chen) writes: > ... > 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. There's a better and more general solution than always updating the map synchronously. What you really need is ordered cache writes. If the system always updates the map blocks before the indirect and inode blocks then the disk would never be in an inconsistent state. This could be made to work with either synchronous or asynchronous file updates. If a user chooses to do synchronous file writes then of course his performance will suffer. But users who do delayed writes would not be penalized.