*BSD News Article 22464


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.