![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1205740
https://bugzilla.suse.com/show_bug.cgi?id=1205740#c10
--- Comment #10 from William Brown
This is not a bug. You seem to be preoccupied with concepts, terms and expectations from another filesystem, my guess is ZFS. You don't need to be a developer to distinguish a mount point, subvolume or a filesystem. If you start a task on a read-only mount it will fail, because that's the semantics of it. I would find confusing if it would work - read-only mount but I can do a write operation?
I am changing a property of the *filesystem* but it is being blocked because a *subvolume* is read-only. That's confusing no matter how you want to cut it.
If you're looking for a single administrative point, then there's no such thing. There are perhaps access points to the filesystem that are represented by mount points with respective RW/RO access, and the / is the most common one (but it's not necessarily the toplevel subvolume).
And this is the core of the bug. There is no single administration point of a filesystem, so subvolumes and filesystems are conflated/confused in btrfs administration causing subvolume properties to block administration of a filesystem.
Transactional server is a particular use case that is not a typical one, eg. because of a read-only mount. If you're doing manual changes to the layout you could expect some resistance, eg. to avoid accidental errors or getting out of sync with the system configuration.
ALP is likely to be transactional like this, so it's going to become typical. -- You are receiving this mail because: You are on the CC list for the bug.