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