On Fri, Apr 11, 2014 at 6:49 PM, David Sterba <[email protected]> wrote: > On Tue, Apr 08, 2014 at 06:25:43PM +0100, Filipe David Borba Manana wrote: >> The following kernel commit changed the definition of the inline function >> btrfs_file_extent_inline_len(): >> >> commit 514ac8ad8793a097c0c9d89202c642479d6dfa34 >> Author: Chris Mason <[email protected]> >> Date: Fri Jan 3 21:07:00 2014 -0800 >> >> Btrfs: don't use ram_bytes for uncompressed inline items >> >> If we truncate an uncompressed inline item, ram_bytes isn't updated to >> reflect >> the new size. The fixe uses the size directly from the item header when >> reading uncompressed inlines, and also fixes truncate to update the >> size as it goes. >> >> Not having this new definition implies that the restore tool might misbehave >> when >> restoring files with an inline extent that got truncated on a kernel older >> than >> release 3.14. > > FYI, I get a compilation error where one instance of > btrfs_file_extent_inline_len lacks the slot parameter, fixed by > > --- a/cmds-check.c > +++ b/cmds-check.c > @@ -1166,7 +1166,7 @@ static int process_file_extent(struct btrfs_root *root, > extent_type = btrfs_file_extent_type(eb, fi); > > if (extent_type == BTRFS_FILE_EXTENT_INLINE) { > - num_bytes = btrfs_file_extent_inline_len(eb, fi); > + num_bytes = btrfs_file_extent_inline_len(eb, slot, fi); > if (num_bytes == 0) > rec->errors |= I_ERR_BAD_FILE_EXTENT; > rec->found_size += num_bytes; > ---
Thanks David. Can you add it please? I was using an older version of the integration branch. -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- 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
