Rogier Wolff replied:
> 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.
Let me clarify (or read the paper):
I was talking about the free bitmap vs. the inode pointing to the data.
That is, you always clear the free bit before setting the inode to point
to it, so you'll never have both thinking that they "own" the block.
You *also* have a dependency between the actual block data. You can't
overwrite a block until the previous owner knows he doesn't own it
any more, and you can't set the inode to point to it until the data is
written. So there are *two* prerequisutes for pointing the inode at a
data block: it has to be out of the free bitmap, and contain valid data.
I didn't explain all the details, as that's what the paper is for.
I'm sorry if my super-brief summary was confusing.
> You also eliminate the possibility of reordering writes at the
> driver or drive level. (e.g. "tagged queuing" is forbidden...)
No, although it cound get tricky. You can write data in any order that
you like; that's what the paper is about. Just the data that you write
differs depending on when it gets written. (Well, yeah, it makes
life trickier.)
> 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.
Fortunately, it's already been done. And it's logically quite simple,
so it's not likely to be a superbly fruitful source of bugs.
-- -Colin