Re: [PATCH] Btrfs/send: sparse and pre-allocated file support for, btrfs-send mechanism

[Jan Schmidt <list.btrfs@jan-o-sch.net>]

Hi Alex,

On Thu, January 24, 2013 at 09:53 (+0100), Alex Lyakas wrote:
> Looking, for example, here:
> http://man7.org/linux/man-pages/man2/fallocate.2.html
> 
> "Allocating disk space
> The default operation (i.e., mode is zero) of fallocate() allocates
> and initializes to zero the disk space within the range specified by
> offset and len."
> 
> "Deallocating file space
> Specifying the FALLOC_FL_PUNCH_HOLE flag (available since Linux
> 2.6.38) in mode deallocates space (i.e., creates a hole) in the byte
> range starting at offset and continuing for len bytes.  Within the
> specified range, partial file system blocks are zeroed, and whole file
> system blocks are removed from the file."
> 
> These are clearly two different modes of operation, and I don't think
> you or me can decide otherwise, at this point.
> 
> However, I may be not knowledgeable enough to confirm this.
> Jan/Alexander, can you perhaps comment on this?

We don't transfer the metadata itself and that's for good reason. The data
should look alike from a user's point of view where possible. In places where we
have no good solution, we make compromises (inode numbers come to mind).

So, as a general rule: If possible with reasonable effort, I like to keep as
much of the structure as possible. Therefore, I'd rather not see a sparse
detector in any receiver out there; if it's sparse, send it as sparse, and if
it's on disk, send it as zeros on disk.

Handling of preallocated space with this rule is, well, arguable. For me, such
space is more on disk than it's not. Applications preallocating space might do
so for a good reason, and I would not treat those blocks as if they were holes
for send and receive.

-Jan