05.03.2018 19:16, Marc MERLIN пишет: > Howdy, > > I did a bunch of copies and moving around subvolumes between disks and > at some point, I did a snapshot dir1/Win_ro.20180205_21:18:31 > dir2/Win_ro.20180205_21:18:31 > > As a result, I lost the ro flag, and apparently 'Received UUID' which is > now preventing me from restarting the btrfs send/receive. > > I changed the snapshot back to 'ro' but that's not enough: > > Source: > Name: Win_ro.20180205_21:18:31 > UUID: 23ccf2bd-f494-e348-b34e-1f28486b2540 > Parent UUID: - > Received UUID: 3cc327e1-358f-284e-92e2-4e4fde92b16f > Creation time: 2018-02-15 20:14:42 -0800 > Subvolume ID: 964 > Generation: 4062 > Gen at creation: 459 > Parent ID: 5 > Top level ID: 5 > Flags: readonly > > Dest: > Name: Win_ro.20180205_21:18:31 > UUID: a1e8777c-c52b-af4e-9ce2-45ca4d4d2df8 > Parent UUID: - > Received UUID: - > Creation time: 2018-02-17 22:20:25 -0800 > Subvolume ID: 94826 > Generation: 250714 > Gen at creation: 250540 > Parent ID: 89160 > Top level ID: 89160 > Flags: readonly > > If I absolutely know that the data is the same on both sides, how do I > either > 1) force back in a 'Received UUID' value on the destination
I suppose the most simple is to write small program that does it using BTRFS_IOC_SET_RECEIVED_SUBVOL. > 2) force a btrfs receive to work despite the lack of matching 'Received > UUID' > > Yes, I could discard and start over, but my 2nd such subvolume is 8TB, > so I'd really rather not :) > > Any ideas? > > Thanks, > Marc > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
