Post by Mario GoebbelsPost by C. BergströmPost by James C. McPhersonhttp://www.osnews.com/story/21920/A_Short_History_of_btrfs
*very* interesting article.. Not sure why James didn't directly link to
it, but courteous of Valerie Aurora (formerly Henson)
http://lwn.net/Articles/342892/
I'm trying to understand the argument against the SLAB allocator
approach. If I understood correctly how BTRFS allocates space, changing
and deleting files may just punch randomly sized holes into the disk
layout. How's that better?
It's an interesting article, for sure. The core of the article is actually
how a solution (b+trees with copy-on-write) found a problem (file systems).
To answer the question, the article claims that reallocation is part of the
Post by Mario GoebbelsDefragmentation is an ongoing process - repacking the items
efficiently is part of the normal code path preparing extents to be
written to disk. Doing checksums, reference counting, and other
assorted metadata busy-work on a per-extent basis reduces overhead
and makes new features (such as fast reverse mapping from an extent
to everything that references it) possible.
It sure suggests what is happening, but I haven't got a clue on how the above
makes a difference. Translating this to the ZFS design, I guess it involves
delaying the block layout to the actual txg i/o phase, while zfs already
decides this when a block enters the txg, it's layout has been decided already.
This allows for blocks to be dumped into a slog device as soon as it is available.
Cheers,
Henk