Comment # 10 on bug 1205740 from William Brown

(In reply to David Sterba from comment #9)
> 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.