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 <[email protected]>: > 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 <[email protected]> > 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 >> <[email protected]> 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 >> >> >
