01.01.2021 00:36, Zygo Blaxell пишет: ... > > Yeah, I only checked that send completed without error and produced a > smaller stream. > > I just dumped the send metadata stream from the incremental snapshot now, > and it's more or less garbage at the start: > > # btrfs sub create A > # btrfs sub create B > # date > A/date > # date > B/date > # mkdir A/t B/u > # btrfs sub snap -r A A_RO > # btrfs sub snap -r B B_RO ... > # btrfs send A_RO | btrfs receive -v /tmp/test > At subvol A_RO > At subvol A_RO > receiving subvol A_RO uuid=995adde4-00ac-5e49-8c6f-f01743def072, > stransid=7329268 > write date - offset=0 length=29 > BTRFS_IOC_SET_RECEIVED_SUBVOL > uuid=995adde4-00ac-5e49-8c6f-f01743def072, stransid=7329268 > # btrfs send B_RO -p A_RO | btrfs receive -v /tmp/test > At subvol B_RO > At snapshot B_RO > receiving snapshot B_RO uuid=4aa7db26-b219-694e-9b3c-f8f737a46bdb, > ctransid=7329268 parent_uuid=995adde4-00ac-5e49-8c6f-f01743def072, > parent_ctransid=7329268 > ERROR: link date -> date failed: File exists > > The btrfs_compare_trees function can handle arbitrary tree differences,
I am not sure. It apparently relies on the fact that inodes are ever monotonically increasing. This is probably true for clones of the same subvolume (I assume clone inherits highest_objectid) but two subvolumes created independently have the same range of inode numbers. Also I am not sure if using later clone as base for difference to earlier clone will work for the same reason. > but something happens in one of the support functions and we get a > bogus link command. The rest of the stream is OK though: we fill > in the contents of B_RO/date, rename A_RO/t to B_RO/u, and update all > the timestamps. > > Oh well, I didn't say send didn't have any bugs. ;) >
signature.asc
Description: OpenPGP digital signature
