On Thu, 22 February 2007 05:30:03 +0100, Juan Piernas Canovas wrote:
>
> DualFS writes meta-blocks in variable-sized chunks that we call partial
> segments. The meta-data device, however, is divided into segments, which
> have the same size. A partial segment can be as large a a segment, but a
> segment usually has more that one partial segment. Besides, a partial
> segment can not cross a segment boundary.
Sure, that's a fairly common approach.
> A partial segment is a transaction unit, and contains "all" the blocks
> modified by a file system operation, including indirect blocks and i-nodes
> (actually, it contains the blocks modified by several file system
> operations, but let us assume that every partial segment only contains the
> blocks modified by a single file system operation).
>
> So, the above figure is as follows in DualFS:
>
> Before:
> Segment 1: [some data] [ D0 D1 D2 I ] [more data]
> Segment 2: [ some data ]
> Segment 3: [ empty ]
>
> If the datablock D0 is modified, what you get is:
>
> Segment 1: [some data] [ garbage ] [more data]
> Segment 2: [ some data ]
> Segment 3: [ D0 D1 D2 I ] [ empty ]
You have fairly strict assumptions about the "Before:" picture. But
what happens if those assumptions fail. To give you an example, imagine
the following small script:
$ for i in `seq 1000000`; do touch $i; done
This will create a million dentries in one directory. It will also
create a million inodes, but let us ignore those for a moment. It is
fairly unlikely that you can fit a million dentries into [D0], so you
will need more than one block. Let's call them [DA], [DB], [DC], etc.
So you have to write out the first block [DA].
Before:
Segment 1: [some data] [ DA D1 D2 I ] [more data]
Segment 2: [ some data ]
Segment 3: [ empty ]
If the datablock D0 is modified, what you get is:
Segment 1: [some data] [ garbage ] [more data]
Segment 2: [ some data ]
Segment 3: [ DA D1 D2 I ] [ empty ]
That is exactly your picture. Fine. Next you write [DB].
Before: see above
After:
Segment 1: [some data] [ garbage ] [more data]
Segment 2: [ some data ]
Segment 3: [ DA][garbage] [ DB D1 D2 I ] [ empty]
You write [DC]. Note that Segment 3 does not have enough space for
another partial segment:
Segment 1: [some data] [ garbage ] [more data]
Segment 2: [ some data ]
Segment 3: [ DA][garbage] [ DB][garbage] [wasted]
Segment 4: [ DC D1 D2 I ] [ empty ]
You write [DD] and [DE]:
Segment 1: [some data] [ garbage ] [more data]
Segment 2: [ some data ]
Segment 3: [ DA][garbage] [ DB][garbage] [wasted]
Segment 4: [ DC][garbage] [ DD][garbage] [wasted]
Segment 5: [ DE D1 D2 I ] [ empty ]
And some time later you even have to switch to a new indirect block, so
you get before:
Segment n : [ DX D1 D2 I ] [ empty ]
After:
Segment n : [ DX D1][garb] [ DY DI D2 I ] [ empty]
What you end up with after all this is quite unlike you "Before"
picture. Instead of this:
> Segment 1: [some data] [ D0 D1 D2 I ] [more data]
You may have something closer to this:
> >Segment 1: [some data] [ D1 ] [more data]
> >Segment 2: [some data] [ D0 ] [more data]
> >Segment 3: [some data] [ D2 ] [more data]
You should try the testcase and look at a dump of your filesystem
afterwards. I usually just read the raw device in a hex editor.
Jörn
--
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
