"detect-zeroes=unmap" support in Btrfs?

"detect-zeroes=unmap" support in Btrfs?

[Roman Mamedov]

Hello,

Qemu/KVM has this nice feature in its storage layer, "detect-zeroes=unmap".
Basically the VM host detects if a block written by the guest consists of
zeroes entirely, and instead of writing zeroes to the backing storage,
converts that into an "unmap" operation (FALLOC_FL_PUNCH_HOLE[1]).

I wonder if the same could be added into Btrfs directly? With a CoW filesystem
there is really no reason to store long runs of zeroes, or even spend
compression cycles on them (even if they compress really well), it would be
more efficient to turn all zero-filled blocks into file holes. (In effect
forcing all files with zero blocks into always being "sparse" files.)

You could say this increases fragmentation, but given the CoW nature of Btrfs,
any write to a file increases fragmentation already (except with "nocow"), and
converting zeroes into holes would be beneficial due to not requiring any
actual IO when those need to be read (reading back zeroes which are not stored
anywhere, as opposed to reading actual zeroes from disk).

[1] http://man7.org/linux/man-pages/man2/fallocate.2.html

-- 
With respect,
Roman

Re: "detect-zeroes=unmap" support in Btrfs?

[Roman Mamedov]

On Tue, 18 Jul 2017 16:57:10 +0500
Roman Mamedov <rm@romanrm.net> wrote:

> if a block written consists of zeroes entirely, instead of writing zeroes to
> the backing storage, converts that into an "unmap" operation
> (FALLOC_FL_PUNCH_HOLE[1]).

BTW I found that it is very easy to "offline" process preexisting files for
this, using "fallocate -d".

       -d, --dig-holes
              Detect  and  dig  holes. Makes the file sparse in-place, without
              using extra disk space. The minimal size of the hole depends  on
              filesystem I/O block size (usually 4096 bytes). Also, when using
              this option, --keep-size is implied. If no range is specified by
              --offset and --length, then all file is analyzed for holes.

              You  can think of this as doing a "cp --sparse" and renaming the
              dest file as the original,  without  the  need  for  extra  disk
              space.

So my suggestion is to implement an "online" counterpart to such
forced-sparsifying, i.e. the same thing done on FS I/O in-band.
(the analogy is with offline vs in-band dedup).

-- 
With respect,
Roman