Zach Brown 1012ee5e8f scoutfs: use block mapping items
Move to static mapping items instead of unbounded extents.
We get more predictable data structures and simpler code but still get
reasonably dense metadata.

We no longer need all the extent code needed to split and merge extents,
test for overlaps, and all that.  The functions that use the mappings
(get_block, fiemap, truncate) now have a pattern where they decode the
mapping item into an allocated native representation, do their work, and
encode the result back into the dense item.

We do have to grow the largest possible item value to fit the worst case
encoding expansion of random block numbers.

The local allocators are no longer two extents but are instead simple
bitmaps: one for full segments and one for individual blocks.  There are
helper functions to free and allocate segments and blocks, with careful
coordination of, for example, freeing a segment once all of its
constituent blocks are free.

_fiemap is refactored a bit to make it more clear what's going on.
There's one function that either merges the next bit with the currently
building extent or fills the current and starts recording from a
non-mergable additional block.  The old loop worked this way but was
implemented with a single squirrely iteration over the extents.  This
wasn't feasible now that we're also iterating over blocks inside the
mapping items.  It's a lot clearer to call out to merge or fill the
fiemap entry.

The dirty item reservation counts for using the mappings is reduced
significantly because each modification no longer has to assume that it
might merge with two adjacent contiguous neighbours.

Signed-off-by: Zach Brown <zab@versity.com>
2017-09-19 11:25:38 -07:00
2017-09-19 11:25:38 -07:00
Description
No description provided
8 MiB
Languages
C 87%
Shell 9.3%
Roff 2.5%
TeX 0.8%
Makefile 0.4%