Re: journaling filesystem

Rogier Wolff (
Thu, 14 May 1998 09:07:36 +0200 (MET DST)

Adam D. Bradley wrote:
> >
> > This is not possible, with a reasonable implementation.
> Sure it is, provided you can guarantee the atomicity of blocks being
> written to the disk. Every change to the filsystem is recorded in a
> single block, part of which are headers and part of which is data
> (which may be file content, whatever).
> One of the headers is "serial number, and a "depends on" field. If you
> can presume that the filesystem is in a consistent on-disk state
> before we begin, then it can be guaranteed that the on-disk state is
> always consistent (albeit it may be the original state)...
> block #1 is not written
> Block #2 -> depends on 1
> Block #3 -> depends on 2
> Blcok #4 -> depends on 1
> Block #5 -> depends on 0
> Then the on-disk image is still consistent, since only the initial
> state is "valid"; 2 is rejected because it depends on 1, and all the
> others are rejected because they either deepend on 1 implicitly or
> explicitly, or because their serial numbers are greater than 1 (so
> they may have an unstated but implicit relationship with 1, eg POSIX
> open-order semantics, etc).
> Of course, I don't have to tell you that run-time performance would
> absolutely suck for such a filesstem. ;-)

Right. This is an example of an implementation that becomes
"unreasonable" if you allow the disk to hold up "block #1"
indefinitively. I mean you could be recieving news for hours
(i.e. gigabytes), and on a crash this would all get undone.

Wether your fsck takes two hours, or wether you throw away hours of
work doesn't really matter.

You need to be able to tell the disk to sync everything to disk once
every 30 seconds or so.


If it's there and you can see it, it's REAL      |  |
If it's there and you can't see it, it's TRANSPARENT |  Tel: +31-15-2137555  |
If it's not there and you can see it, it's VIRTUAL   |__FAX:_+31-15-2138217  |
If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983  |_____|

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to