Zero-filled blocks in HAMMER

[Matthew Dillon]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20160829/7ac18f90/attachment-0003.htm>