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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
