https://bugzilla.suse.com/show_bug.cgi?id=1205740 Thorsten Kukuk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1205740 https://bugzilla.suse.com/show_bug.cgi?id=1205740#c3 William Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #3 from William Brown --- No, this is not expected. Btrfs here is fundamentally confusing a "filesystem" (the mountpoint and the data within it) from the volume group (the collection of disks that provide space to the set of contained filesystems). This operation to re-balance is operating on the *volume group* and is not changing properties of the filesystem. Since "/" is listed as the default administration point of the volume group here, this means that on a transactional server, operations to either administer, repair or interact with the volume group will fail *incorrectly*. Also /home and / are the same volume group, but not the same filessytem. So the fact that a command which operates on the volume group fails on one filessytem, but not the other is inconsistent and confusing. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1205740 https://bugzilla.suse.com/show_bug.cgi?id=1205740#c5 --- Comment #5 from William Brown --- How am I thinking of this wrong? btrfs fi show displays: Label: none uuid: cfa4961a-bb45-4941-ae70-948bb27fdd9b Total devices 1 FS bytes used 64.52GiB devid 1 size 256.00GiB used 106.06GiB path /dev/nvme0n1p2 It's not listing all the filesystems/subvolumes here. So when I go to administer "that filesystem (rather, volume group)" why should it fail because a subvolume is readonly. But instead of taking a filesystem id or similar, btrfs expects a subvolume mountpoint, and is incorrectly saying that it can't be administered because the *subvolume* is read-only. There is nothing stopping administration of the fs, only a need to find a read-write subvolume. That's extremely counter intuitive. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1205740 https://bugzilla.suse.com/show_bug.cgi?id=1205740#c7 --- Comment #7 from Goldwyn Rodrigues --- Subvolumes are not flat but hierarchical. btrfs subvolume list / provides you with the information. man btrfs-subvolume also provides you with information how subvolumes are defined or managed. From the man page of btrfs-balance: From kernel 3.3 onwards, btrfs balance can limit its action to a subset of the whole filesystem, and can be used to change the replication con- figuration (e.g. moving data from single to RAID1). -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1205740 https://bugzilla.suse.com/show_bug.cgi?id=1205740#c8 --- Comment #8 from William Brown --- (In reply to Goldwyn Rodrigues from comment #7)

Subvolumes are not flat but hierarchical. btrfs subvolume list / provides you with the information. man btrfs-subvolume also provides you with information how subvolumes are defined or managed.

From the man page of btrfs-balance: From kernel 3.3 onwards, btrfs balance can limit its action to a subset of the whole filesystem, and can be used to change the replication con- figuration (e.g. moving data from single to RAID1).

The bug still exists though. When I want to act on the "filesystem" as a whole, I can't because you have to nominate a "subvolume" as the administration point, which incorrectly returns that you can't modify it. Generally, it seems like in this whole topic, that btrfs administration is very confused and may have a lot of usability traps. I think that needs to be addressed because not everyone is a btrfs developer like you, and people have jobs to do, so they need tools that work in predictable and reliable manners. Just humour me, go install transactional server, and try to make it raid1 with btrfs and see what the experience is like. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1205740 https://bugzilla.suse.com/show_bug.cgi?id=1205740#c10 --- Comment #10 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. -- You are receiving this mail because: You are on the CC list for the bug.