On Mon, Apr 06, 2020 at 11:51:20AM +0100, Filipe Manana wrote:
> On Sat, Apr 4, 2020 at 9:21 PM <fdmanana@xxxxxxxxxx> wrote:
> >
> > From: Filipe Manana <fdmanana@xxxxxxxx>
> >
> > When not using the NO_HOLES feature we were not marking the destination's
> > file range as written after cloning an inline extent into it. This can
> > lead to a data loss if the current destination file size is smaller than
> > the source file's size.
> >
> > Example:
> >
> > $ mkfs.btrfs -f -O ^no-holes /dev/sdc
> > $ mount /mnt/sdc /mnt
> >
> > $ echo "hello world" > /mnt/foo
> > $ cp --reflink=always /mnt/foo /mnt/bar
> > $ rm -f /mnt/foo
> > $ umount /mnt
> >
> > $ mount /mnt/sdc /mnt
> > $ cat /mnt/bar
> > $
> > $ stat -c %s /mnt/bar
> > 0
> >
> > # -> the file is empty, since we deleted foo, the data lost is forever
> >
> > Fix that by calling btrfs_inode_set_file_extent_range() after cloning an
> > inline extent.
> >
> > A test case for fstests will follow soon.
> >
> > Fixes: 9ddc959e802bf ("btrfs: use the file extent tree infrastructure")
> > Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx>
>
> Reported-by: Johannes Hirte <johannes.hirte@xxxxxxxxxxxxx>
> Link: https://lore.kernel.org/linux-btrfs/20200404193846.GA432065@latitude/
> Tested-by: Johannes Hirte <johannes.hirte@xxxxxxxxxxxxx>
Thanks, added to misc-next.
