Comment # 27 on bug 1156421 from Goldwyn Rodrigues

(In reply to Fabian Vogt from comment #26)
> (In reply to Goldwyn Rodrigues from comment #25)
> > We had a discussion in the btrfs mailing list and it was concluded that
> > these changes would deviate from the "default" case [1]. Currently sys
> > admins are setting any subvolume read-only to set the root filesystem
> > read-only. While this is not ideal, this behavior has already been exploited.
> > 
> > [1]
> > https://lore.kernel.org/linux-btrfs/20220211164422.GA12643@twin.jikos.cz/T/#t
> 
> Ah, good ol' spacebar heating (https://xkcd.com/1172/).
> 
> Maybe the example doesn't really show the severity of the issue, as it
> focuses on the "root" mountpoint. This has more independent mounts of
> subvolumes:

Yes, this is a problem with any subvolume. *Any* subvolume setting to remount
read-only renders all subvolumes currently mounted of the entire filesystem
read-only. This is what was pointed out by Graham Cobb in the discussion.

> 
> dd if=/dev/zero of=btrfsfs seek=240 count=0 bs=1M
> mkfs.btrfs btrfsfs
> mkdir mnt
> mount btrfsfs mnt
> btrfs subvol create mnt/sv0
> btrfs subvol create mnt/sv1
> umount mnt
> 
> mkdir sv{0,1}mnt
> mount -o subvol=/sv0 btrfsfs sv0mnt
> mount -o subvol=/sv1 btrfsfs sv1mnt
> findmnt sv0mnt # RW
> findmnt sv1mnt # RW
> mount -o remount,ro sv0mnt
> findmnt sv0mnt # RO
> findmnt sv1mnt # RO!
> mount -o remount,rw sv1mnt
> findmnt sv0mnt # RW!
> findmnt sv1mnt # RW
> umount sv*mnt
> 
> Do we have any filesystems we can compare the behaviour with?

Unfortunately, btrfs is pretty unique in this front.