need for remount btrfs rw

[jozzsi]

This issue is to discuss the following patch

https://github.com/garuda-linux/pkgbuilds/commit/26d7f8496c242265b6902ee9188f134194cd0c0b

Let's try to clarify when we need this btrfs remount.

• I assume remount only needed if there is a subvolume (no submodule has no issue) - can this be confirmed ?
• I assume if 'rw' command line flag is set this remount is not needed - can this be confirmed ?
• I assume if the goal is to have the top level and all subvolume mounted same way (e.g. all ro or all rw) remount is not needed - can this be confirmed ?
• This really feels like it should be a mount option, as this is not specific to initramfs mounting.

CC @dalto8 @sirlucjan @JustTNE

[jozzsi]

@mwilck - Do you have any thoughts on this btrfs related concern ? Thank you !

[JustTNE]

I believe I made a typo there when it comes to submodule. Submodule should be subvolume.

It should be clarified like this: As long as the btrfs volume is only mounted once, there is no need to remount as rw. If there are multiple mounts (say, a subvolume) then it needs to be remounted.

2. That would make sense, but in this case a precaution would have to be taken that the subvolume is not written to (snapshots are not supposed to be written to). I have not tested this however. Remember: btrfs allows setting entire subvolumes as RO in metadata without the use of the kernel parameters.

3. Yes. Well, more precisely, the goal is for all subvolumes to be mounted the same way as if the root subvolume was mounted rw. Meaning any ro subvolumes should still be mounted ro. But any rw subvolumes should be mounted rw (this is not the case if the first mount made from the btrfs volume is ro). In reality, this has nothing to do with the top level btrfs volume. Garuda Linux for instance never mounts the top level volume at all.

4. I'm not sure such an option exists.

[dalto8]

A couple of things to consider:

• At least in the case of EndeavourOS, we don't manage the snapshot booting process and have minimal control over the command flags passed when booting snapshots.
• Btrfs is a little interesting in that some of the mount options apply to all subvolumes even when defined at the subvolume level. When there are differences between mount options for different subvolumes, the first one mounted wins.

[mwilck]

I am not a btrfs expert. My gut feeling says that we should NOT generally do this.

[Vogtinator]

Btrfs is a little interesting in that some of the mount options apply to all subvolumes even when defined at the subvolume level. When there are differences between mount options for different subvolumes, the first one mounted wins.

Not entirely true.

What actually happens is that some mount options are applied to the FS ("superblock") and some are applied to the VFS ("mountpoint", in this case practically "subvolumes"). You can check that with findmnt -o TARGET,FS-OPTIONS,VFS-OPTIONS.

mount -o ro /dev/some-btrfs /mnt
findmnt -o TARGET,FS-OPTIONS,VFS-OPTIONS # /mnt is RO on FS and VFS
mount -o rw,subvol=/foo /dev/some-btrfs /mnt/foo
findmnt -o TARGET,FS-OPTIONS,VFS-OPTIONS # /mnt/foo is RW on FS and VFS, but /mnt is now RW on FS but RO on VFS
mount -o remount,ro /mnt # Makes the entire FS RO
findmnt -o TARGET,FS-OPTIONS,VFS-OPTIONS # /mnt is RO on FS and VFS, same for /mnt

If instead of remount,ro you use remount,ro=vfs, only the VFS options are impacted.

mount -o remount,ro=vfs /mnt
# /mnt is RW on FS, but RO on VFS. /mnt/foo stays RW on both FS and VFS.

[Vogtinator]

The issue the patch solves is probably that there is some entry in /etc/fstab or something else which does a mount -o ro,subvol=/... or mount -o remount,ro .... The fix is simply to use ro=vfs in all those cases. This is how we fixed this issue in openSUSE MicroOS where / is a read-only mounted subvolume.

[jozzsi]

@JustTNE @dalto8 - I think before this work can progress upstream, please consider taking an action based on the suggestion from @Vogtinator . It seems https://github.com/garuda-linux/pkgbuilds/commit/26d7f8496c242265b6902ee9188f134194cd0c0b can potentially be reverted.

[JustTNE]

It can not. We do not mount as ro explicitly, that's done through the btrfs ro flag.

https://btrfs.readthedocs.io/en/latest/Subvolumes.html#subvolume-flags

I do not believe we do any explicit ro mounting, but I might be wrong about that, I'm not at liberty to check right now.

[Vogtinator]

It can not. We do not mount as ro explicitly, that's done through the btrfs ro flag.

The subvolume flags have no impact on mounts and will not turn anything else read-only. There is definitely an explicit read-only mount somewhere. Could be just the entry for / in /etc/fstab which is re-applied by systemd-remount-fs.service.

[dalto8]

There is definitely an explicit read-only mount somewhere.

Which raises the question, what is mounting it ro? I just looked at both the bootloader and fstab and there is nothing being mounted read-only in either place.

[jozzsi]

Could it be dracut's fault to mount `ro' ?

Would it be possible for now to always pass 'rw', at least so that dracut does not just assume 'ro' - at least until the dracut bug (if any) is found and fixed ?

I am not suggesting the bug is here, but dracut seems to make some wrong assumptions here - https://github.com/dracut-ng/dracut-ng/blob/main/modules.d/70fs-lib/fs-lib.sh#L222

[Vogtinator]

Could it be dracut's fault to mount `ro' ?

The initial rootfs mount is usually ro (unless the rw parameter or rootflags=rw,... is passed on the kernel cmdline), but that should not have any negative effects. Whatever subvolume is mounted read-write afterwards flips the FS options to rw.