Btrfs devel - Aug 2012 - 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