Comment # 43 on bug 1156421 from Jeff Mahoney

(In reply to Thorsten Kukuk from comment #41)
> (In reply to Jeff Mahoney from comment #38)
> > Does mount --bind -oro,remount <mnt> work for you?
> 
> If I call this from the commandline, yes, works.
> If I add "bind" to /etc/fstab (ro,bind), no, this doesn't seem to work.
> 
> But we need something for /etc/fstab for the boot process.
> 
> Beside that, what would be the side effects of using this option?

Using ro or rw without bind in the fstab has the same effect.

If the initial mount is read-only, it will mark the entire file system
read-only.  If a another subvolume mount wants a read-write mount, it will
leave the first mountpoint read-only, remount the file system internally
read-write, and mark the new mount point read-write.  Writes to the first mount
will continue to be refused and will be allowed on the second mount.

For context, the read-only flag can be set in:
- Filesystem-wide superblock flags
- Mountpoint flags
- Subvolume flags

If the superblock flag or the subvolume flag is set, the subvolume will be
read-only no matter where it's mounted and regardless whether the mountpoint is
read-write.  If the mountpoint flag is set, the subvolume will be read-only
only at that mountpoint and could be writable at another location if the
subvolume was mounted more than once.

If you use mount -oremount,ro on a subvolume, that overrides that internal
remount to rw and you end up with the situation where the entire fs is
read-only.  If you use mount -oremount,ro --bind on a subvolume _mountpoint_ it
only applies to the mountpoint.  If you do that on a subvolume that isn't
explicitly mounted, it'll complain about it not being a mountpoint and fail
with an error.

All of this happens with flags that the VFS layer understands, using the
superblock and mountpoints.

The problem is that btrfs subvolumes don't have to be represented by a
mountpoint.  We do that explicitly to give the appearance of a coherent file
system.  As a result, there's no internal linkage between mount points and
subvolumes.  The mount point flags and the subvolume flags aren't connected.

This has some annoying UX effects.

1) You can set the mountpoint readonly status and it'll be enforced at that
mountpoint, but not subsequent mounts of the same subvolume unless those are
also mounted with the same read-only status.

This would either be mount --bind -oremount,r[ow] or by just specifying the
ro/rw flags in /etc/fstab.

2) You can set the btrfs subvolume readonly status and it'll be enforced
everywhere, but the mountpoint flags are all that's shown to the user via
'mount.'  To get the subvolume flags you'll need to use btrfs tools.  

This would be btrfs property set path read-only [true|false]

The subvolume flags are persistent, while the mountpoint flags are not. 
Unfortunately, mount points essentially don't exist to the underlying file
system.  The mount routine for a file system returns a dentry and _then_ the
mountpoint is created.  You will see a mount point used in the btrfs mount code
internally but it's only temporary and is released before the mount completes. 
So there's no way to have the mount point automatically reflect the flags of
the subvolume.

A long-term idea of mine has been to leverage the automount behavior in the VFS
to handle subvolumes.  The automount callback _does_ have access to the
vfsmount and so it could set those flags before returning it to the vfs.  I
haven't had the time to do this and we've never made it an official feature
request.

So, I'm not sure this helps but should at least explain why it's so confusing.