#101 Difficult/impossible to see disk usage with default partitioning schema
Closed: Fixed a year ago by catanzaro. Opened 2 years ago by aday.

I'm filing this issue here because it touches on multiple components, and because it concerns our default partitioning schema and technology.

Today I tried to find out how much disk space I had left on my laptop, which is running F30 with the default partition schema. I looked in a variety of places, and failed to find the information I needed in every case:

  • Under Settings → Details, there was no indication of disk space used/free, despite it showing the size of the disk there
  • In Files, I went to Other Locations → On This Computer. It showed the root volume along with amount of space used/free. However, it wasn't clear what the root volume is for, and the home volume was missing, which is the thing I needed to know about (I assume this is true for other users).
  • In Disks, I looked at the entry for my disk. The partition table showed the LVM part, but that didn't show information for the volumes or the amount of space used (in contrast to the two boot partitions, where it does show the used/free space). (I later learned that the LVM volumes are listed separately under "Disks", which is confusing - they're not disks. The entries for these use a lot of technical jargon and it's difficult to tell what they are.)
  • I ran the Disk Usage Analyzer, but it didn't show a view of the disk space. Like Files, it showed the root volume with space used/free, without any clue as to what the root volume is for, and it showed my home directory, but it doesn't show the home volume.
  • I search for LVM in Software and discovered blivet-gui. This enabled me to see the size of the LVM volumes on my disk, but not the space used/free.

It appears that there's no way to actually see your disk usage on Fedora Workstation, with the default partition schema. This seems like a basic requirement and is something that people do need to be able to do.


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:

Screenshot_from_2019-08-08_08-49-24.png

Screenshot_from_2019-08-08_08-49-21.png

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

Screenshot_from_2019-08-08_08-50-14.png

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:

Screenshot_from_2019-08-08_08-56-37.png

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!

Metadata Update from @aday:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

2 years ago

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.

Metadata Update from @aday:
- Issue status updated to: Open (was: Closed)

2 years ago

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.

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

2 years ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

2 years ago

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

Screenshot_from_2020-04-15_23-39-12.png

Screenshot_from_2020-04-15_23-37-31.png

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.

Screenshot_from_2020-04-17_01-04-39.png

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

Screenshot_from_2020-04-17_01-35-12.png

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.

Metadata Update from @catanzaro:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata