https://bugzilla.suse.com/show_bug.cgi?id=1156421 https://bugzilla.suse.com/show_bug.cgi?id=1156421#c43 Jeff Mahoney <jeffm@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jeffm@suse.com) | --- Comment #43 from Jeff Mahoney <jeffm@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.