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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alex,

On Thu, January 24, 2013 at 19:06 (+0100), Alex Lyakas wrote:
> On Thu, Jan 24, 2013 at 7:13 PM, Jan Schmidt <list.btrfs@xxxxxxxxxxxxx> wrote:
>> 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"?

Sorry, I commented on the whole thread, in a single email. The above comment is
more in the direction of

---
On Thu, January 24, 2013 at 12:58 (+0100), Hugo Mills wrote:
> I disagree on the "content vs representation" comment above. I
> would very much hope that the reference receive implementation can
> turn a string of zeroes (or a hole) back into a sparse file. As a
> user, I'd be quite irritated if, say, one of my sparse VM images ended
> up 5 times the size when I backed it up with send/receive, simply
> because it's gone from holey to a huge bunch of zeroes. That
> particular issue can be dealt with at the receiver level, though.
---

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

Yes :-)
-Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux