Alex Lyakas
2012-Aug-27 12:22 UTC
Question about commit: Btrfs: fix btrfs send for inline items and compression, a9fa6848e4aae8d777f7af5e9f2d5b11331252dd
Hi Chris, I am looking at your fix in find_extent_clone(), and the code now looks like this: if (compressed == BTRFS_COMPRESS_NONE) extent_item_pos = logical - found_key.objectid; else extent_item_pos = 0; extent_item_pos = logical - found_key.objectid; So the "compressed" flag that you added has no effect, or am I missing something? Also, in send_write_or_clone(), the following code rounds up to the next page size: if (type == BTRFS_FILE_EXTENT_INLINE) { len = btrfs_file_extent_inline_len(path->nodes[0], ei); /* * it is possible the inline item won''t cover the whole page, * but there may be items after this page. Make * sure to send the whole thing */ len = PAGE_CACHE_ALIGN(len); Why it is ok to attempt to read-and-send more data than btrfs_file_extent_inline_len() indicates? I assume this code is intended to handle "hole between the end of the inline item and the start of the full extent", in which case it will read-and-send zeros up to the start of the next extent. But why it is bad just to use the original "len"? Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html