On Thu, Sep 08, 2022 at 09:04:23AM +0200, Boris Kolpackov wrote:
> After upgrading from btrfs-progs 5.14.1-1 with Linux kernel 5.14.9 to
> btrfs-progs 5.18.1-1 with Linux kernel 5.18.16 (from current testing)
> I see the following new error when trying to clear the read-only
> property of a freshly received snapshot:
>
> btrfs property set -ts /btrfs/test/mysubvol ro false
> ERROR: cannot flip ro->rw with received_uuid set, use force if you really
> want that
>
> The subvolume is sent/received using the following command:
>
> sudo btrfs send mysubvol | ssh user@host sudo btrfs receive /btrfs/test/
>
> Adding the -f flag as suggested by the error message helps but it's not
> clear what the implication of this are. I tried to search the internet
> for this error but only found instances of others running into it with
> no insight into what it means.
If you modify the subvolume, you can't use it for incremental send/receive
anymore.
The commit that introduced this says:
Implement safety check when a read-only subvolume is getting switched
to read-write and there's received_uuid set.
This prevents accidental breakage of incremental send use case but
allows user to do the rw change anyway but resets the received_uuid in
that case.
The message given is indeed quite puzzling; what it means is "is the
received volume meant for use, or will it continue being a replica?".
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ ʀᴜꜱꜱɪᴀɴᴇꜱ ᴇᴜɴᴛ ᴅᴏᴍᴜꜱ
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄⠀⠀⠀⠀
