Re: Soft metadata updates paper w/code

Erik Andersen (andersen@inconnect.com)
Tue, 22 Jul 1997 10:50:34 -0600 (MDT)


How about a file system where before you write a file, you mark a
Writing-file flag, and then when you complete the write
of the the file to disk, you clear the flag. If at any time the
filesystem comes across a file that has the Writing-file flag set,
but it is not currently writing that particular file, it just blows
the file away, since it is invalid. Wouldn't this give the equivalent
of atomic operations? Of course the flag set/unset would only be done
on actual disk commits (not just having an open file descriptor).
Wouldn't this ensure that the filesystem was always in a safe and
sane state? Of course, I have never studied filesystem design, so
this may be a really bad idea for some reason I can't think of...

-Erik

--
Erik B. Andersen   Web:    http://www.inconnect.com/~andersen/ 
                   email:  andersee@debian.org
--This message was written using 73% post-consumer electrons--

On Tue, 22 Jul 1997, Rogier Wolff wrote:

> Colin Plumb wrote: > > > > Looking at reiserfs, I found a University of Michigan tech report > > on "soft updates" a technique to remove all synchronous writes > > from a file system yet maintain fsck-less crashes. > > > > (By always marking data in use before it's used and ensuring that > > data is not used before it's marked free, a crash can leave some > > If you first mark a block as used, and only then write the block, > the filesystem won't be corrupt when the system crashes inbetween. > However, your DATA will be corrupt. > > I think it's better to have fsck detect a broken filesystem, than to > have a file silently contain bad data. As far as I know, Linus also > thinks this way. > > You also eliminate the possibility of reordering writes at the > driver or drive level. (e.g. "tagged queuing" is forbidden...) > > All this would be very hard to debug: You'd have to try throwing > the switch on your system quite a few times to be sure it works. > > Roger. > > >