#171 Replace disk-usage-analyzer and/or baobab (aka future of gnome-usage)
Opened 11 months ago by aday. Modified 4 months ago

There has been some confusion in #101 over the plan to replace disk-usage-analyzer and baobab with gnome-usage. Let's use this ticket to get on the same page and track progress.

We were planning on replacing disk-usage-analyzer and baobab with a new Usage app, and an initial implementation was written a while back

Since then, two things have happened:

  1. @hergertme took a look and came to the conclusion that the app needs some non-trivial changes to make it fit for purpose (his main issue being that a system monitor app shouldn't itself use a significant amount of resources), and requires technical and ui changes.
  2. On the design side, we've started to question whether it's appropriate to merge the system monitor and disk usage functionality, given that they are fairly different domains, which don't overlap that much in use, and which have distinct front and back ends.

As far as I understand it, we are currently waiting for @hergertme to get back to this, while simultaneously exploring what the future might be for disk usage. There's some relevant upstream discussion here.


Two relevant concepts:

  • Shared extents
  • Compression

Shared extents can exist on XFS and Btrfs, and are created by reflink copies. This is soon to be the default for cp. And reflinks are created by podman (and mobi/docker) used for container support. Shared extents are also created by Btrfs snapshots and deduplication.

Shared extents and compression thwart big picture accuracy with du reporting, leading to du overestimating space consumption. It reports only the uncompressed view of a directory, and will report shared extents as if they're exclusive to the enclosing directory. It's correct behavior from a narrow point of view, but misleading from a zoomed out perspective. So I think both will need to be accounted for, or it'll lead to unexpected outcomes.

Is it fair to say this is in-scope for Fedora 34 (or Future release), and not Fedora 33? If not feel free to flip the milestone as appropriate.

Metadata Update from @chrismurphy:
- Issue set to the milestone: Fedora 34

10 months ago

Is it fair to say this is in-scope for Fedora 34 (or Future release), and not Fedora 33? If not feel free to flip the milestone as appropriate.

This issue is mostly to track ongoing developments in this area and I don't think we have a specific target in mind, so setting it as future release.

Metadata Update from @aday:
- Issue set to the milestone: Future Release (was: Fedora 34)

10 months ago

Metadata Update from @catanzaro:
- Issue tagged with: default-apps

4 months ago

Login to comment on this ticket.

Metadata