> > the overhead was below 5% *in initial implementation*. Overhead compared
> > to async variant, that is. It can be done for Linux implementation but
> > we'll have to clean the VFS stuff up before.
>
> Stephen is doing full journalling.
>
> > are not independent. If we want to guarantee that on-disk copy is
> > consistent at any moment we must submit these changes in _some_ order. The
>
> No order provides total consistency without a journalling log as far as I can
> tell. Please provide an ordering example for extending a file that does not
> either expose unwritten blocks to the user (security failure) or potentially
> have to go and clean a block up afterwards
>
> Alan
Erm... What I really wonder is how much would we lose on the following
policy:
Request 1: <write new data block>, depends on <>
Request 2: <write new indirect block> or <add a pointer to existing one>,
depends on <1>
Request 3: <update inode block>, depends on <2>.
In the worst case it will give us lost block, not attached to
anything. BFD.
With the current ext2 + bdflush we can get _any_ order at all,
AFAI can see.
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/