Hello, I'm currently implementing parts of a send/receive tool that walks through all inodes and records changes into a tar/pax archive. Changes are determined by the transid of inodes and the generation number of file extent items. An inode/extent is considered to be changed if the transid/generation is higher then a specified generation. While testing the code I found a problem with files where parts where cloned with the BTRFS_IOC_CLONE_RANGE ioctl. When the extents get cloned, their generation is cloned too. Which means, that even if the file was actually changed, my checks may say that it is unchanged because the extents generation numbers are lower then the specified generation number. The same problem may occur when BTRFS_IOC_CLONE was used. I could also imagine that deduplication would result in the same issue when a recent change to the file (which increased the generation) would allow deduplication on the changed parts of the file. In that case, we may get extents injected into the file that have an old generation number. Any ideas how these issues could be handled/fixed? Would it for example be possible to increase generation numbers when extents get cloned? BTW: Why is it sometimes called transid (e.g. in inodes) and sometimes generation (e.g. in extents). In btrfs_inode_item I also see a field named "generation" but the comment above this field says "nfs style generation number" so I don't know if this represents the same value as the transid. Can someone explain this? Alex. -- 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
