On 04.06.2012 14:39, Alex Lyakas wrote: > > # How does one track changes in generic INODE_ITEM properties, like > "mode" or "uid/gid"? Whenever such property gets changed, INODE_ITEM > gets stamped with a new transid, but do we need to compare it with the > previous version on the receive side to realize what has changed? > # File size - is it required, again, to compare vs previous size, to > realize file truncation? (file grow perhaps can be realized via new > EXTENT_DATAs) The basic idea of send/receive is not to find anything that has changed since a given transid number, but to find the differences between 2 snapshots. This way you always have access to the old values. > # What should be done if INODE_ITEM::flags change (e.g., inode gets > nodatacow/nodatasum flags set). What should be done at receive side? > # How does one track deletion of INODE_ITEMs? Or, deletion and > re-creation of a INODE_ITEM with the same inode number? (I saw that > inode_cache mount option allows to re-use inode numbers, so I think it > can happen.) Does this mean that on receive side, it is required to > compare contents of each directory vs previous version? A recreated inode gets a new inode generation number. That's needed for NFS, otherwise NFS could also not detect this case. > # What should be done with INODE_ITEMs like block/char device, FIFO or a socket? Everything that can be created on the dest side, like device files, should be created. > # XATTR_ITEMs: although they have a transid stamp, again, need to > track deletion/re-creation of them. Again by comparing? as long as they end up identical on the destination, delete/recreate shouldn't matter. The rest of the question I leave for Jan and Alexander :) -Arne > # INODE_REFs: these seem most tough to me, because they don't have > transid stamps. How such scenario can be handled: an INODE_ITEM had > two INODE_REFs with names N1 and N2. But now on the send side, both > those INODE_REFs were deleted and INODE_REFs N3 and N4 were created. > Does that mean we need to always compare all INODE_REFs for each > INODE_ITEM, or we perhaps can use DIR_ITEMs/DIR_INDEXs of parent > INODE_ITEM to detect changes in INODE_REFs? > > All in all, it looks like the approach of navigating the FS tree and > trying to *understand* specifically which modifications were > performed, is quite error-prone. And I am sure there are modifications > I am not aware about. > > I was wondering, what state your work is in? Is it possible to look at > some code or prototype, to understand what approach have you taken, or > perhaps an overall description of the approach? > > Jan, I saw that you provided some new code for backref resolving. Can > you give a hint of how is that related to the send/receive > functionality? > > Thanks, > 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 -- 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
