On Fri, Sep 25, 2015 at 1:20 PM, Martin Raiber <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
