Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!uwm.edu!cs.utexas.edu!uunet!yeshua.marcam.com!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Newsgroups: comp.os.386bsd.development Subject: Re: mount a dirty file system without fsck (was Re: what is fs_clean for?) Date: 16 Oct 1993 07:14:36 GMT Organization: Weber State University, Ogden, UT Lines: 46 Message-ID: <29o70s$sk3@u.cc.utah.edu> References: <2945gj$i0h@acsc.com> <adlerCEr6pt.Jwx@netcom.com> NNTP-Posting-Host: cs.weber.edu In article <adlerCEr6pt.Jwx@netcom.com> adler@netcom.com (Bruce Adler) writes: [ ... "cleanfs" bit and "dirty" mounts ... ] >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. I am curious as to what you would do for the O_WRITESYNC case for a file which coexisted in the same map space (but different actual blocks) as a file which was not being accessed that way. It seems to me that you would have to take the hit for both files. If you want to do file system design, fine, but it is almost necessary to start with a clean slate; in particular, the init code and static allocations must go, and the block management needs to be zoned (ala VIVA FS from UKY); then you might as well go to an allocation bitmap directly and decode the bytes; this is what the ACER Fast Filesystem does. And then ... and then ... and then ... Seriously, there is a lot more kernel work that wants to be done before real FS work can go very far. The NetBSD stuff is a lot farther along that route than the FreeBSD, but neither are far enough to be happy. And even then, there isn't that much benefit to be dervied; for instance, the SVR4 VXFS is only a couple percent faster than a UFS on the same device and using 8k blocks. The clean bit mods are a good idea; just disallow mounts of a dirty FS unless they are done read-only. If you get ambitious, make fsck keep a counter in the volume header (like Ultrix) and fsck anyway after so man boots. As long as the mark/unmount and unmark/mount are atomic, there shouldn't be any problems that wouldn't be there for a dirty case anyway. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.