Zero-filled blocks in HAMMER
Matthew Dillon
dillon at backplane.com
Mon Aug 29 11:43:49 PDT 2016
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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20160829/38f0a94e/attachment.html>
More information about the Users
mailing list