Update to the format rev which has large log segments that start with
bloom filter blocks, have items linked in a skip list, and item values
stored at offsets in the block.
Signed-off-by: Zach Brown <zab@versity.com>
pseudo_random_bytes() was accidentally copying the last partial long to
the beggining of the buffer instead of the end. The final partial long
bytes weren't being filled.
Signed-off-by: Zach Brown <zab@versity.com>
mkfs just needs to initialize bloom filter blocks with the bits for the
single root inode key. We can get away with these skeletal functions
for now.
Signed-off-by: Zach Brown <zab@versity.com>
We're going to need to start setting bloom filters bits in mkfs so we'll
add this trivial inline. It might grow later.
Signed-off-by: Zach Brown <zab@versity.com>
The initial bitmap entry written in the ring by mkfs was off by one.
Three chunks were written but the 0th chunk is also free for the supers.
It has to mark the first four chunks as allocated.
Signed-off-by: Zach Brown <zab@versity.com>
In the first pass we'd only printed the first map and ring blocks.
This reads the number of used map blocks into an allocation large enough
for the maximum number of map blocks.
Then we use the block numbers from the map blocks to print the active
ring blocks which are described by the super.
Signed-off-by: Zach Brown <zab@versity.com>
The use of 'log' for all the large sizes was pretty confusing. Let's
use 'chunk' to describe the large alloc size. Other things live in them
as well as logs. Then use 'log segment' to describe the larger log
structure stored in a chunk that's made up of all the little blocks.
Get rid of the explicit distinction between brick and block numbers.
The format is now defined it terms of fixed 4k blocks. Logs become a
logical structure that's made up of a fixed number of blocks. The
allocator still manages large log sized regions.
