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 <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
