Zero-filled blocks in HAMMER

[Tomohiro Kusumi]

Yes, I think the original post (in 2015) was talking about H1, which
allocates all zero-bytes out of blockmap unless deduped.

Anyhow thanks for explaining H2.

2016-08-30 3:43 GMT+09:00 Matthew Dillon <dillon at backplane.com>:
> Urk.,  Sorry.  I got H2 and H1 mixed up.  Hammer2 does the zero testing.
> Hammer1... actually might not.  But Hammer1 can do DEDUP and will DEDUP all
> the zero'd blocks into never-never land.
>
> Originally the intention was to support it in H1 via live_dedup, but live
> dedup was disabled long ago (because it caused corruption and I gave up
> trying to find out why).  Batch dedup will still catch the zerod blocks
> though so eventually they won't take up any real space.
>
> -Matt
>
> On Mon, Aug 29, 2016 at 11:39 AM, Matthew Dillon <dillon at backplane.com>
> wrote:
>>
>> For any copy-on-write filesystem there is no point pre-zeroing a file to
>> 'allocate' its blocks, because any overwrite will reallocate the block.
>> Thus, the expectation is that most copy-on-write filesystems will detect
>> blocks which contain all-zeros and not bother to actually allocate disk
>> space for such blocks, instead just leaving a 'hole' in the file (which
>> reads as zeros when the file is read).  (If writing all zeros into a block
>> which was previously non-zero, Hammer simply removes the block from the
>> B+Tree to create a hole).
>>
>> In the original UFS, writing zeros would actually write blocks full of
>> zeros into the file, but this was desireable because UFS is not a
>> copy-on-write filesystem.  So the concept of preallocating space works.  UFS
>> also always supported file holes via lseek()/write() to skip the 'hole' you
>> want to leave, as do numerous earlier filesystems.  So 'Sparse Files' is
>> actually a very old concept.
>>
>> -Matt
>>
>>
>> On Sun, Aug 28, 2016 at 9:25 AM, Tomohiro Kusumi
>> <kusumi.tomohiro at gmail.com> wrote:
>>>
>>> This might be off topic as I brought this from tux3 ml archive,
>>> but what does "FS converted zerod blocks to hole like hammerfs"
>>> supposed to mean here ?
>>>
>>> Is this talking about sparse file ?
>>> (and do BSDs including DragonFly even support sparse file ?)
>>>
>>> http://phunq.net/pipermail/tux3/2015-August/002327.html
>>> > Also, if FS converted zerod blocks to hole like hammerfs, simply ENOSPC
>>> > happens.
>>>
>>>
>>> This is the result of
>>> # dd if=/dev/zero of=xxx bs=16384 count=10
>>> against a newly created fs, and there are 10 zero-filled data records,
>>> which is what I was expecting to see in fs level from the way hammer
>>> is implemented.
>>>
>>> --
>>> HAMMER zone statistics
>>>         zone #  blocks       items              used[B]
>>> used[%]
>>>         zone 0  0            0                  0                   0
>>>         zone 1  0            0                  0                   0
>>>         zone 2  0            0                  0                   0
>>>         zone 3  0            0                  0                   0
>>>         zone 4  0            0                  0                   0
>>>         zone 5  0            0                  0                   0
>>>         zone 6  0            0                  0                   0
>>>         zone 7  0            0                  0                   0
>>>         zone 8  1            1                  4096
>>> 0.0488281
>>>         zone 9  1            4                  572
>>> 0.00681877
>>>         zone 10 1            10                 163840
>>> 1.95312
>>>         zone 11 0            0                  0                   0
>>>         zone 12 0            0                  0                   0
>>>         zone 13 0            0                  0                   0
>>>         zone 14 0            0                  0                   0
>>>         zone 15 0            0                  0                   0
>>>
>>> ----------------------------------------------------------------------
>>>         total   3            15                 168508
>>> 0.669591
>>
>>
>