Re: Incremental btrfs send/receive fails if file is unlinked and cloned afterwards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 25, 2015 at 1:20 PM, Martin Raiber <martin@xxxxxxxxxxxx> wrote:
> Hi,
>
> the commit "Btrfs: incremental send, check if orphanized dir inode needs
> delayed rename" causes incremental send/receive to fail if a file is
> unlinked and then reflinked to the same location from the parent
> snapshot. An xfstest reproducing the issue is attached.

Thanks for the report and test.
The problem is not related at all to reflinked files (or extent
cloning/dedup). You run into this problem by just creating a file with
the same name and at the same location, and it needs to be the file
with highest inode number in the snapshot.

I've sent a fix and modified your test too, as it didn't conform to
the xfstests coding style, had unnecessary requirements (cloner
program, cp with reflink support) and added a description of the
problem.

thanks

>
> Regards,
> Martin



-- 
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux