btrfs send picks wrong subvolume UUID

btrfs send picks wrong subvolume UUID

[Dāvis Mosāns]

Hi,

I have a bunch of snapshots I want to send from one fs to another,
but it seems btrfs send is using received UUID instead of subvolumes own UUID
causing wrong subvolume to be picked by btrfs receive and thus failing.

$ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
2019-11-02/etc
        Name:                   etc
        UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
        Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
        Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403

$ btrfs send /mnt/fs/2019-11-02/etc | btrfs receive --dump | head -n 2
At subvol /mnt/fs/2019-11-02/etc
subvol          ./etc
uuid=15bd7d35-9f98-0b48-854c-422c445f7403 transid=1727996
chown           ./etc/                          gid=0 uid=0
$ btrfs send /mnt/fs/2019-11-02/etc | btrfs receive /mnt/newFS/2019-11-02/
At subvol /mnt/fs/2019-11-02/etc
At subvol etc

$ btrfs subvolume show /mnt/fs/2020-09-21/etc | head -n 5
2020-09-21/etc
        Name:                   etc
        UUID:                   1c6a0138-b23b-244f-82d8-e2fcaa20870f
        Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
        Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403

$ btrfs send -c /mnt/fs/2019-11-02/etc -p /mnt/fs/2019-11-02/etc
/mnt/fs/2020-09-21/etc | btrfs receive --dump | head -n 2
At subvol /mnt/fs/2020-09-21/etc
snapshot        ./etc
uuid=15bd7d35-9f98-0b48-854c-422c445f7403 transid=2148016
parent_uuid=15bd7d35-9f98-0b48-854c-422c445f7403
parent_transid=1727996
utimes          ./etc/
atime=2019-08-11T14:56:46+0300 mtime=2020-09-21T20:30:38+0300
ctime=2020-09-21T20:30:38+0300
$ btrfs send -c /mnt/fs/2019-11-02/etc -p /mnt/fs/2019-11-02/etc
/mnt/fs/2020-09-21/etc | btrfs receive /mnt/newFS/2020-09-21/
At subvol /mnt/fs/2020-09-21/etc
At snapshot etc

$ btrfs subvolume list -opuqR /mnt/newFS/
ID 373 gen 1965 parent 276 top level 276 parent_uuid -
                   received_uuid 15bd7d35-9f98-0b48-854c-422c445f7403
uuid 4a21e16f-ab4e-1f45-900a-541ead4e9fa4 path 2019-11-02/etc
ID 374 gen 1968 parent 276 top level 276 parent_uuid
4a21e16f-ab4e-1f45-900a-541ead4e9fa4 received_uuid
15bd7d35-9f98-0b48-854c-422c445f7403 uuid
7e19706d-4cf4-8245-ae02-1bdd99f92e48 path 2020-09-21/etc

As you can see received_uuid is same for both and it's not the UUID of
source subvolume


$ btrfs subvolume show /mnt/fs/2020-12-09/etc | head -n 5
2020-12-09/etc
        Name:                   etc
        UUID:                   2902708e-2ebf-654a-8b03-f854e031f8c7
        Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
        Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403

$ btrfs send -c /mnt/fs/2020-09-21/etc -p /mnt/fs/2020-09-21/etc
/mnt/fs/2020-12-09/etc | btrfs receive --dump | head -n 2
At subvol /mnt/fs/2020-12-09/etc
snapshot        ./etc
uuid=15bd7d35-9f98-0b48-854c-422c445f7403 transid=2212940
parent_uuid=15bd7d35-9f98-0b48-854c-422c445f7403
parent_transid=2148016
utimes          ./etc/
atime=2019-08-11T14:56:46+0300 mtime=2020-12-08T17:50:18+0200
ctime=2020-12-08T17:50:18+0200
$ btrfs send -c /mnt/fs/2020-09-21/etc -p /mnt/fs/2020-09-21/etc
/mnt/fs/2020-12-09/etc | btrfs receive /mnt/newFS/2020-12-09/
At subvol /mnt/fs/2020-12-09/etc
At snapshot etc
ERROR: unlink o86334-1390558-0/d42ee4920c54898f1957cd2f38799f735dfa05
failed: No such file or directory

Here it fails because it actually used target's 2019-11-02/etc
subvolume as parent instead of 2020-09-21/etc like we specified.
We can see that in strace:
$ btrfs send -c /mnt/fs/2020-09-21/etc -p /mnt/fs/2020-09-21/etc
/mnt/fs/2020-12-09/etc | strace btrfs receive /mnt/newFS/2020-12-09/
2>&1 | grep -E '2019-11-02|SNAP_CREATE'
At subvol /mnt/fs/2020-12-09/etc
ioctl(4, BTRFS_IOC_INO_LOOKUP, {treeid=276, objectid=261} =>
{name="2019-11-02/"}) = 0
openat(4, "2019-11-02/etc", O_RDONLY|O_NOATIME) = 5
ioctl(3, BTRFS_IOC_SNAP_CREATE_V2, {fd=5, flags=0, name="etc"} =>
{transid=0}) = 0

Best regards,
Dāvis

Re: btrfs send picks wrong subvolume UUID

[Andrei Borzenkov]

On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
>
> Hi,
>
> I have a bunch of snapshots I want to send from one fs to another,
> but it seems btrfs send is using received UUID instead of subvolumes own UUID
> causing wrong subvolume to be picked by btrfs receive and thus failing.
>
> $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
> 2019-11-02/etc
>         Name:                   etc
>         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
>         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
>         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
>

btrfs send will always use received UUID if available, it works as
designed and is not a bug. Bug is to have received UUID on read-write
subvolume. btrfs does not prevent it and it is the result of wrong
handling on the user side. You should never ever change read-only
subvolume used for send/receive to read-write directly - instead you
should always create writable clone from it.

This was discussed extensively, see e.g.
https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/

Re: btrfs send picks wrong subvolume UUID

[Dāvis Mosāns]

svētd., 2022. g. 2. janv., plkst. 22:37 — lietotājs Andrei Borzenkov
(<arvidjaar@gmail.com>) rakstīja:
>
> On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
> >
> > Hi,
> >
> > I have a bunch of snapshots I want to send from one fs to another,
> > but it seems btrfs send is using received UUID instead of subvolumes own UUID
> > causing wrong subvolume to be picked by btrfs receive and thus failing.
> >
> > $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
> > 2019-11-02/etc
> >         Name:                   etc
> >         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
> >         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
> >         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
> >
>
> btrfs send will always use received UUID if available, it works as
> designed and is not a bug. Bug is to have received UUID on read-write
> subvolume. btrfs does not prevent it and it is the result of wrong
> handling on the user side. You should never ever change read-only
> subvolume used for send/receive to read-write directly - instead you
> should always create writable clone from it.
>
> This was discussed extensively, see e.g.
> https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/

I consider it as bug. How can anyone know they shouldn't do that. It
is perfectly valid use case for sending subvolumes from one system to
another system. After sending using "btrfs property set ro false" to
set RW. Sounds very logical, why should I create a new snapshot? I
just sent new one. Original system's subvolume could even be deleted
with no plans to ever do any incremental sends. And seems many people
have had this issue which just proves my point it's a bug. And if this
is not supported, then why there exists such "btrfs property set ro
false" at all who lets you shoot yourself in foot? If it didn't exist
then everyone would use only other option by creating new RW snapshot
which actually sounds more like a workaround for broken property set.
So I would say first bug that needs fixing is changing "btrfs property
set ro false" in kernel so that it clears received_uuid and
regenerates new subvolume uuid because such modified subvolume isn't
same as source and would still causes issue if it stayed same.
That would fix it for future but wouldn't solve it for many people who
already have such subvolumes. And it's pretty hard problem to track
down unless you already know it. Like it took me a lot of time to
figure out why send is failing. ro->rw was done 7 years ago and all
snapshots since then have same received_uuid but I noticed btrfs send
not working only now. For me, easiest way I'll just patch kernel to
always use subvolume's uuid and ignore received_uuid, then btrfs send
all snapshots so it will work fine for me. As for others, in general
seems proper fix would be that btrfs send would give both uuid and
received_uuid. Then btrfs receive could have a flag to ignore
received_uuid and just use uuid. Or search by uuid and then fallback
to received_uuid.

Re: btrfs send picks wrong subvolume UUID

[Nikolay Borisov]

On 3.01.22 г. 20:09, Dāvis Mosāns wrote:
> svētd., 2022. g. 2. janv., plkst. 22:37 — lietotājs Andrei Borzenkov
> (<arvidjaar@gmail.com>) rakstīja:
>>
>> On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I have a bunch of snapshots I want to send from one fs to another,
>>> but it seems btrfs send is using received UUID instead of subvolumes own UUID
>>> causing wrong subvolume to be picked by btrfs receive and thus failing.
>>>
>>> $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
>>> 2019-11-02/etc
>>>         Name:                   etc
>>>         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
>>>         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
>>>         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
>>>
>>
>> btrfs send will always use received UUID if available, it works as
>> designed and is not a bug. Bug is to have received UUID on read-write
>> subvolume. btrfs does not prevent it and it is the result of wrong
>> handling on the user side. You should never ever change read-only
>> subvolume used for send/receive to read-write directly - instead you
>> should always create writable clone from it.
>>
>> This was discussed extensively, see e.g.
>> https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/
> 
> I consider it as bug. How can anyone know they shouldn't do that. It
> is perfectly valid use case for sending subvolumes from one system to
> another system. After sending using "btrfs property set ro false" to
> set RW. Sounds very logical, why should I create a new snapshot? I
> just sent new one. Original system's subvolume could even be deleted
> with no plans to ever do any incremental sends. And seems many people
> have had this issue which just proves my point it's a bug. And if this
> is not supported, then why there exists such "btrfs property set ro
> false" at all who lets you shoot yourself in foot? If it didn't exist
> then everyone would use only other option by creating new RW snapshot
> which actually sounds more like a workaround for broken property set.
> So I would say first bug that needs fixing is changing "btrfs property
> set ro false" in kernel so that it clears received_uuid and
> regenerates new subvolume uuid because such modified subvolume isn't
> same as source and would still causes issue if it stayed same.
> That would fix it for future but wouldn't solve it for many people who
> already have such subvolumes. And it's pretty hard problem to track
> down unless you already know it. Like it took me a lot of time to
> figure out why send is failing. ro->rw was done 7 years ago and all
> snapshots since then have same received_uuid but I noticed btrfs send
> not working only now. For me, easiest way I'll just patch kernel to
> always use subvolume's uuid and ignore received_uuid, then btrfs send
> all snapshots so it will work fine for me. As for others, in general
> seems proper fix would be that btrfs send would give both uuid and
> received_uuid. Then btrfs receive could have a flag to ignore
> received_uuid and just use uuid. Or search by uuid and then fallback
> to received_uuid.


That behavior got fixed in btrfs-progs in version 5.14, in particular
commit:

https://github.com/kdave/btrfs-progs/commit/3b90ebc2d7eb4b4a4d5d55eff362e8127a673828

Of course it requires users upgrading btrfs-progs but even if we merged
some kernel-side fix (there's been one I authored couple of years ago
and it's been circulated on the mailing list but didn't get merged) it
would still require users upgrading their kernel eventually.

> 

Re: btrfs send picks wrong subvolume UUID

[Dāvis Mosāns]

otrd., 2022. g. 11. janv., plkst. 17:33 — lietotājs Nikolay Borisov
(<nborisov@suse.com>) rakstīja:
>
>
>
> On 3.01.22 г. 20:09, Dāvis Mosāns wrote:
> > svētd., 2022. g. 2. janv., plkst. 22:37 — lietotājs Andrei Borzenkov
> > (<arvidjaar@gmail.com>) rakstīja:
> >>
> >> On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have a bunch of snapshots I want to send from one fs to another,
> >>> but it seems btrfs send is using received UUID instead of subvolumes own UUID
> >>> causing wrong subvolume to be picked by btrfs receive and thus failing.
> >>>
> >>> $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
> >>> 2019-11-02/etc
> >>>         Name:                   etc
> >>>         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
> >>>         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
> >>>         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
> >>>
> >>
> >> btrfs send will always use received UUID if available, it works as
> >> designed and is not a bug. Bug is to have received UUID on read-write
> >> subvolume. btrfs does not prevent it and it is the result of wrong
> >> handling on the user side. You should never ever change read-only
> >> subvolume used for send/receive to read-write directly - instead you
> >> should always create writable clone from it.
> >>
> >> This was discussed extensively, see e.g.
> >> https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/
> >
> > I consider it as bug. How can anyone know they shouldn't do that. It
> > is perfectly valid use case for sending subvolumes from one system to
> > another system. After sending using "btrfs property set ro false" to
> > set RW. Sounds very logical, why should I create a new snapshot? I
> > just sent new one. Original system's subvolume could even be deleted
> > with no plans to ever do any incremental sends. And seems many people
> > have had this issue which just proves my point it's a bug. And if this
> > is not supported, then why there exists such "btrfs property set ro
> > false" at all who lets you shoot yourself in foot? If it didn't exist
> > then everyone would use only other option by creating new RW snapshot
> > which actually sounds more like a workaround for broken property set.
> > So I would say first bug that needs fixing is changing "btrfs property
> > set ro false" in kernel so that it clears received_uuid and
> > regenerates new subvolume uuid because such modified subvolume isn't
> > same as source and would still causes issue if it stayed same.
> > That would fix it for future but wouldn't solve it for many people who
> > already have such subvolumes. And it's pretty hard problem to track
> > down unless you already know it. Like it took me a lot of time to
> > figure out why send is failing. ro->rw was done 7 years ago and all
> > snapshots since then have same received_uuid but I noticed btrfs send
> > not working only now. For me, easiest way I'll just patch kernel to
> > always use subvolume's uuid and ignore received_uuid, then btrfs send
> > all snapshots so it will work fine for me. As for others, in general
> > seems proper fix would be that btrfs send would give both uuid and
> > received_uuid. Then btrfs receive could have a flag to ignore
> > received_uuid and just use uuid. Or search by uuid and then fallback
> > to received_uuid.
>
>
> That behavior got fixed in btrfs-progs in version 5.14, in particular
> commit:
>
> https://github.com/kdave/btrfs-progs/commit/3b90ebc2d7eb4b4a4d5d55eff362e8127a673828
>
> Of course it requires users upgrading btrfs-progs but even if we merged
> some kernel-side fix (there's been one I authored couple of years ago
> and it's been circulated on the mailing list but didn't get merged) it
> would still require users upgrading their kernel eventually.
>

The issue is not that users wouldn't update, but that old filesystems
are already present with this case. This is why fix in btrfs-progs
doesn't help. It prevents it only happening in future but not for
people who already have such filesystems thus kernel fix is necessary
as I described.

Re: btrfs send picks wrong subvolume UUID

[David Sterba]

On Tue, Jan 11, 2022 at 06:46:11PM +0200, Dāvis Mosāns wrote:
> otrd., 2022. g. 11. janv., plkst. 17:33 — lietotājs Nikolay Borisov
> (<nborisov@suse.com>) rakstīja:
> > On 3.01.22 г. 20:09, Dāvis Mosāns wrote:
> > > svētd., 2022. g. 2. janv., plkst. 22:37 — lietotājs Andrei Borzenkov
> > > (<arvidjaar@gmail.com>) rakstīja:
> > >>
> > >> On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> I have a bunch of snapshots I want to send from one fs to another,
> > >>> but it seems btrfs send is using received UUID instead of subvolumes own UUID
> > >>> causing wrong subvolume to be picked by btrfs receive and thus failing.
> > >>>
> > >>> $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
> > >>> 2019-11-02/etc
> > >>>         Name:                   etc
> > >>>         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
> > >>>         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
> > >>>         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
> > >>>
> > >>
> > >> btrfs send will always use received UUID if available, it works as
> > >> designed and is not a bug. Bug is to have received UUID on read-write
> > >> subvolume. btrfs does not prevent it and it is the result of wrong
> > >> handling on the user side. You should never ever change read-only
> > >> subvolume used for send/receive to read-write directly - instead you
> > >> should always create writable clone from it.
> > >>
> > >> This was discussed extensively, see e.g.
> > >> https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/
> > >
> > > I consider it as bug. How can anyone know they shouldn't do that. It
> > > is perfectly valid use case for sending subvolumes from one system to
> > > another system. After sending using "btrfs property set ro false" to
> > > set RW. Sounds very logical, why should I create a new snapshot? I
> > > just sent new one. Original system's subvolume could even be deleted
> > > with no plans to ever do any incremental sends. And seems many people
> > > have had this issue which just proves my point it's a bug. And if this
> > > is not supported, then why there exists such "btrfs property set ro
> > > false" at all who lets you shoot yourself in foot? If it didn't exist
> > > then everyone would use only other option by creating new RW snapshot
> > > which actually sounds more like a workaround for broken property set.
> > > So I would say first bug that needs fixing is changing "btrfs property
> > > set ro false" in kernel so that it clears received_uuid and
> > > regenerates new subvolume uuid because such modified subvolume isn't
> > > same as source and would still causes issue if it stayed same.
> > > That would fix it for future but wouldn't solve it for many people who
> > > already have such subvolumes. And it's pretty hard problem to track
> > > down unless you already know it. Like it took me a lot of time to
> > > figure out why send is failing. ro->rw was done 7 years ago and all
> > > snapshots since then have same received_uuid but I noticed btrfs send
> > > not working only now. For me, easiest way I'll just patch kernel to
> > > always use subvolume's uuid and ignore received_uuid, then btrfs send
> > > all snapshots so it will work fine for me. As for others, in general
> > > seems proper fix would be that btrfs send would give both uuid and
> > > received_uuid. Then btrfs receive could have a flag to ignore
> > > received_uuid and just use uuid. Or search by uuid and then fallback
> > > to received_uuid.
> >
> >
> > That behavior got fixed in btrfs-progs in version 5.14, in particular
> > commit:
> >
> > https://github.com/kdave/btrfs-progs/commit/3b90ebc2d7eb4b4a4d5d55eff362e8127a673828
> >
> > Of course it requires users upgrading btrfs-progs but even if we merged
> > some kernel-side fix (there's been one I authored couple of years ago
> > and it's been circulated on the mailing list but didn't get merged) it
> > would still require users upgrading their kernel eventually.
> 
> The issue is not that users wouldn't update, but that old filesystems
> are already present with this case. This is why fix in btrfs-progs
> doesn't help. It prevents it only happening in future but not for
> people who already have such filesystems thus kernel fix is necessary
> as I described.

The progs fix can do (and does) the same as what kernel would do (while
cluttering the ioctl implementation a bit).

Old filesystems, where ro/rw switch has happened on sent subvolumes will
be reported and warn in command 'btrfs subvolume show'. To reset the
received_uuid, flipping the ro/rw property works since 5.14.2, and this
is needed just once on any affected subvolume.

Updating the progs should be easier than updating kernel, so the fix is
there and available also for LTS kernels.

Re: btrfs send picks wrong subvolume UUID

[David Sterba]

On Mon, Jan 03, 2022 at 08:09:01PM +0200, Dāvis Mosāns wrote:
> svētd., 2022. g. 2. janv., plkst. 22:37 — lietotājs Andrei Borzenkov
> (<arvidjaar@gmail.com>) rakstīja:
> >
> > On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I have a bunch of snapshots I want to send from one fs to another,
> > > but it seems btrfs send is using received UUID instead of subvolumes own UUID
> > > causing wrong subvolume to be picked by btrfs receive and thus failing.
> > >
> > > $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
> > > 2019-11-02/etc
> > >         Name:                   etc
> > >         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
> > >         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
> > >         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
> > >
> >
> > btrfs send will always use received UUID if available, it works as
> > designed and is not a bug. Bug is to have received UUID on read-write
> > subvolume. btrfs does not prevent it and it is the result of wrong
> > handling on the user side. You should never ever change read-only
> > subvolume used for send/receive to read-write directly - instead you
> > should always create writable clone from it.
> >
> > This was discussed extensively, see e.g.
> > https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/
> 
> I consider it as bug. How can anyone know they shouldn't do that. It
> is perfectly valid use case for sending subvolumes from one system to
> another system. After sending using "btrfs property set ro false" to
> set RW. Sounds very logical, why should I create a new snapshot? I
> just sent new one. Original system's subvolume could even be deleted
> with no plans to ever do any incremental sends. And seems many people
> have had this issue which just proves my point it's a bug.

It may sound logical but breaks assumptions of send, so yes it is a bug
and the fix took more time than convenient, because just fixing the
kernel was not enough and later I realized that's the wrong place to fix
it. There's also updated documentation regarding the usecase so this
should address the "how can anyone know not to do it".

> So I would say first bug that needs fixing is changing "btrfs property
> set ro false" in kernel

So technically it gets cleared in kernel, using the
BTRFS_IOC_SET_RECEIVED_SUBVOL ioctl, but it's initiated by the command
'btrfs prop set ro false' for the subvolume. Effectively there's no
difference for you as a user.