To the extent your concern is related to our default partitioning rather than deficiencies in the GNOME tools: in #54 we agreed to eliminate the separate /home partition so that it is combined into / and then stop using LVM, but delayed implementation until #82 is solved because #82 might conflict with that decision.

But I think this is mostly an upstream design issue, rather than something that needs attention from the working group, yes?

It's possible to see disk usage in Disks, though this could be made clearer with a different design:

I think Disks does OK here. In contrast, Disk Usage Analyzer (baobab) presents a pretty useless result:

That's not great because it only shows me space used by my root volume, not by /home. That's a really weird choice. Moreover, actually trying to analyze either /home or / with baobab is extremely slow and never seems to work properly. It presents a horrible error message by default:

And the sizes reported are not even correct. You can see from the first screenshot that it thinks my / is 73.7 GB, which is incorrect: it's 70 GiB exactly, which is 75.16193 GB, not 73.7 GB. Then in the second screenshot it says 32.3 GB, which is ridiculous. I wondered if 32.3 GB might be space used, but according to Disks I have 29 GB free of 75 GB total, which means 46 GB used. So the results presented by baobab are outrageous. I wonder if it's ever worked properly.

Then when I tried to analyze /home, I got bored and gave up before baobab stopped spinning.

Lastly, we have nautilus. It's not discoverable, but easy to right click -> Properties in nautilus and see I have 641.2 GB free space in /home, which is displayed immediately without waiting. This conflicts with the information from Disks, though, which says I have 687 GB free. So one app or the other must be seriously incorrect. Noting that 687 GB is ~640 GiB, I suspect nautilus is mucking up the units by computing GiB but labeling it GB instead, perhaps in addition to some rounding issues. The result from Disks looks more trustworthy here.

Suggested actions:

• Remove baobab from core? Is it worth trying to fix?
• Create a bug report to nautilus regarding incorrect result

To the extent your concern is related to our default partitioning rather than deficiencies in the GNOME tools in #54 we agreed to eliminate the separate /home partition so that it is combined into / and then stop using LVM, but delayed implementation until #82 is solved because #82 might conflict with that decision.

If we were committed to the existing partitioning schema, I'd have said that we should update the GNOME tools to work well with it.

Since the decision has been made to change the schema, I think the appropriate course of action is to make sure that we should check that the new schema from #54 works well with our tools, particularly for common tasks like checking disk usage.

I'll close this and add a note to #54.

Thanks!

OK, just remember there's a substantial chance we'll change our minds about #54.

Lastly, we have nautilus. It's not discoverable, but easy to right click -> Properties in nautilus and see I have 641.2 GB free space in /home, which is displayed immediately without waiting. This conflicts with the information from Disks, though, which says I have 687 GB free. So one app or the other must be seriously incorrect. Noting that 687 GB is ~640 GiB, I suspect nautilus is mucking up the units by computing GiB but labeling it GB instead, perhaps in addition to some rounding issues. The result from Disks looks more trustworthy here.

Turns out nautilus is correct. Disks is displaying the wrong value. I don't know where it's coming from.

Issue turned out to be that Disks is displaying reserved space as available: https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues/146

I rather think this issue could be left open for tracking and discussion. It's related to, but ultimately orthogonal to partitioning scheme. Regardless of the scheme, users need reliable and discoverable ways to determine used and free space.

A central gotcha is IEC vs SI units. I'm more favorable to IEC, because the base unit for drives is 512 bytes, and files are subject to that base unit. But regardless, the principle really needs to be, completely and correctly label the units being used and quite a lot of tools fail at that, and on both platforms. Even df -h and df -H both claim the same unit: M, G, or T.

Cockpit gets this right.

I rather think this issue could be left open for tracking and discussion. It's related to, but ultimately orthogonal to partitioning scheme.

Fair enough; let's track this separately.

The observations in this issue constitute bugs; are any of them bad enough that it would serve as more than a minor incentive to NOT change partitioning schemes? In other words, are any of the bugs, or combination of them, likely to act as a liability to the changes implied by #54 and #82?

Does it make sense to prioritize fixing some of these bugs, as preliminary/preparatory work for whatever is decided in #54 and #82? And are there resources to do that in the F32 development cycle?

Does it make sense to prioritize fixing some of these bugs, as preliminary/preparatory work for whatever is decided in #54 and #82? And are there resources to do that in the F32 development cycle?

Good questions. If the fixes to these issues could be carried over to whatever we do for #54 and #82, that would certainly be an incentive. At the same time, I'm not sure I'd want to go to the effort of fixing the issues if those fixes aren't going to be relevant to the new defaults.

I do think that the ability to support a complete UX around disk usage, like being able to see and understand how the disk is being used, is an important consideration for #54 and #82.

I was thinking that it would be good for the WG to review the state of #54 and #82 soon. When we do so, we should also factor in this issue.

The lack of reporting on /home is a problem for current or most any future layout.

And the current layout as a legacy layout will be around a while: supported for upgrades for at least two releases; and upgrades can't change the layout, making it a practical matter to support the layout even longer to avoid being disruptive; and Anaconda's custom partitioning offers this exact layout in the partition scheme drop-down as "LVM" and will for the foreseeable future.

This is useful information but not discoverable. Right-click on Home, and choose Properties.

Considering Silverblue and Workstation have different partitioning; and that half, or possibly more, members of the WG don't use default partitioning, I still wonder if it's worth at least exploring whether there's a generic approach? Free space in ~/ seems relevant in any case, but in particular when that free space might be very different among users in a systemd-homed loop-file arrangement. I'm imagining various possible behaviors on that front.

Considering Silverblue and Workstation have different partitioning; and that half, or possibly more, members of the WG don't use default partitioning, I still wonder if it's worth at least exploring whether there's a generic approach?

You might be right - both a single root partition and a separate home are fairly common.

I think my main doubt was whether supporting this with LVM is worthwhile, given the Workstation's direction of travel...

Considering [...] half, or possibly more, members of the WG don't use default partitioning

My workstation at work uses the default partitioning. Everything else (set up later) uses the default Btrfs layout.

I think my main doubt was whether supporting this with LVM is worthwhile, given the Workstation's direction of travel...

Maybe worthwhile and straightforward, since these are all fundamentally similar "partitioned" layouts, in that they separate sysroot from the user home:

1. sd-homed LUKS loop file mounted at ~/
2. LVM "fedora/home" LV mounted at /home
3. plain partition mounted at /home

The outlier is sd-homed. It mounts a file system at the user home, i.e. /home/chris and /home/allan with user switching means those are separate file system volumes. Whereas (2)(3) mount a shared file system at /home.

When I right-click on Home, and get Properties, I suspect the Free space value is based on /home not ~/. For sd-homed, it needs to be the latter. This also doesn't interfere with the other layouts.

The "one big file system" (without sd-homed) concept also fits with reporting ~/ Free space; it conflats all space as being ~/ which is true, even though it's also shared with /.

There's also, "Other Locations"

My system. This seems reasonable, agrees with the value for Home->Properties.

Default partitioning. This isn't showing Home at all. Computer reports only the fedora/root logical volume values.

Switching to a single btrfs filesystem will help with this issue - in the current setup the home volume isn't show in the Disk Usage Analyzer and it's hard to find in Disks. Since we wouldn't have a fixed sized home with btrfs, we no longer have that problem.

However, we still have some general UI problems around Disk Usage Analyzer. In my opinion this issue won't truly be fixed until those are resolved. I've filed an upstream issue for this which has some updated designs attached.

We should also maybe decide to what extent we care about non-default storage layouts, particularly separate storage for root and home, using either LVM or simple partitions. If we do care about those, then we still need to do things like:

• LVM with volumes for root and home:
  • Show logical volumes in "other locations" in Files
  • General improvements to Disks, so it's clear which physical device each logical volume belongs to
• Plain partitions for root and home:
  • Show the partitions in the "Other locations" view in Files
  • Improve the list rows in "Other locations", to give a better view of space used (the mount point column is confusing, too)
  • Show the partitions in the Disk Usage Analyzer overview, and present them better (this is covered in the upstream issue)

I'm confused, I really thought your plan was to replace Disk Usage Analyzer and System Monitor with Usage. If plans have changed, please let me know.

I'm confused, I really thought your plan was to replace Disk Usage Analyzer and System Monitor with Usage. If plans have changed, please let me know.

Christian Hergert was planning on rewriting Usage, and we had some fairly detailed conversations about it towards the end of last year. I don't think anything has happened since then, so I was assuming that Usage is on hold for now. I could be mistaken of course...

@aday I don't know about any plan about rewriting Usage. Usage was written from scratch few years ago. @feborges are you aware of anything? I think that our plan was to replace Disk Usage Analyzer and System Monitor in F34.

Wait, I thought our plan was to replace DUA and the system monitor in F33?

@catanzaro , @tpopela , @ngompa - let's discuss plans for Usage in #171

Closing since we no longer default to LVM.

(btrfs problems can be tracked under https://pagure.io/fedora-btrfs/project/issues.)