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

[Alex Lyakas <alex.btrfs@zadarastorage.com>]

Hi Jan,

On Thu, Jan 24, 2013 at 7:13 PM, Jan Schmidt <list.btrfs@jan-o-sch.net> wrote:
> 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.
Agree, but I don't think we have any such thing. Receiver just obeys
the commands in the stream, not tries to analyze them. Or perhaps you
mean something else by "sparse detector"?

>
> 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.

So, if I understand you correctly, you do suggest to distinguish
between punch-hole and preallocate on send side (e.g., by using
different send commands), and do appropriate things on the receive
side by using/not using the FALLOC_FL_PUNCH_HOLE flag to the fallocate
API on the receive side. If yes, then this was also my opinion.

Thanks!
Alex.


>
> -Jan