Re: [PATCH v2 0/8] Implement progs support for removing received uuid on RW vols

[David Sterba <dsterba@suse.cz>]

On Tue, Sep 14, 2021 at 12:05:50PM +0300, Nikolay Borisov wrote:
> Here's V2 which takes into account Qu's suggestions, namely:
> 
> - Add a helper which contains the common code to clear receive-related data
> - Now there is a single patch which impements the check/clear for both orig and
> lowmem modes
> - Added Reviewed-by from Qu.
> 
> 
> Nikolay Borisov (8):
>   btrfs-progs: Add btrfs_is_empty_uuid
>   btrfs-progs: Remove root argument from btrfs_fixup_low_keys
>   btrfs-progs: Remove fs_info argument from leaf_data_end
>   btrfs-progs: Remove root argument from btrfs_truncate_item
>   btrfs-progs: Add btrfs_uuid_tree_remove
>   btrfs-progs: Implement helper to remove received information of RW
>     subvol
>   btrfs-progs: check: Implement removing received data for RW subvols
>   btrfs-progs: tests: Add test for received information removal

Patches 2-5 added to devel as they're preparatory and otherwise OK as
independent cleanups.

Regarding the rw and received_uuid, it's choosing between these options:

1) ro->rw resets received_uuid unconditionally

Pros:
- safe as it does not lead to unexpected results after incremental send

Cons:
- unconditional, so it's too easy to break the incremental send usecase,
  which is the main usecase, if that' for backups breaking the
  continuity is IMNSHO serious usability problem -- and main reason why
  I'm personally looking for other options

Issuing a warning when the ro status is changed by btrfs-progs is only
partially fixing that as the raw ioctl or it's wrapper in libbtrfsutil
will happily destroy the received_uuid. There's no log or other
information that would make it possible to restore it.

Note that received_uuid can be set to any value using the
BTRFS_IOC_SET_RECEIVED_SUBVOL ioctl, as long as the subvolume is
writable.

2) don't allow ro->rw if received_uuid is set, it must be cleared first

As mentioned above, the received_uuid can be changed or reset (setting
all zeros), but there's still the condition that the subvolume must be
writable.

After 'receive' the subvolume is snapshotted, updated from stream, set
received_uuid and set rw->ro.

Reusing the SET_RECEIVED_SUBVOL can't be used as-is, the subvol would
have to be rw first. Which is a chicken-egg problem.

The safe steps would be:

- (after receive, subvolume is RO)
- set it to RW
- clear received_uuid
- either keep it RW or set RO again

This would be the single "clear received_uuid manually" and it would be
up to the user to knowingly destroy the continuity of the incremental
send.

The fix here is that the above steps would have to be atomic from user
perspective, inside SET_RECEIVED_SUBVOL, eg. based on flag. And we'd
have to add a btrfs-progs command somewhere.