Hammer - block size

[Matthew Dillon]

:When I write 10-byte files, does Hammer use a full 64K block for each
:file, and then if I extend/truncate a file but it stays < 64K, it stays in
:the same 64K block on the disk?
:
:Or does it pack multiple files into the 64K block, with file A being the
:first 10 bytes, file B being the next 10?  Then when I extend file A to 20
:bytes (and do an fsync), I get 10 unused bytes where A originally was
:located, file B for 10 bytes, the new file A for 20 bytes, and the
:reblocker comes along later and fixes this block when the amount of
:fragmented space in the 64K block becomes excessive or the block is full
:(but has holes)?
:
:Jim

    For any file less then 16K HAMMER writes out a single 16-byte
    variable-length record.  A 10 byte file thus will allocate only
    16 bytes of data space.

    The B-Tree element overhead is 64 bytes, though, and the inode eats
    128 bytes plus a second 64-byte B-Tree element.  The absolute best
    case for a small file is thus 16+64+64+128 = ~272 bytes of disk space.

    Though each meta-data type is allocated from a different big-block.
    Once you accumulate enough small files together though it will be
    fairly well packed.

    Once you get over 16K HAMMER uses 16K blocks.  Once the file gets
    over 1MB HAMMER uses 64K blocks.

    --

    If you rewrite a block HAMMER allocates a new one and the old one
    becomes historical and will eventually be pruned out and the space
    it used recovered.

						-Matt