Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reported disk space is not granular enough for big drives #494

Closed
thingsiplay opened this issue Jul 10, 2023 · 13 comments
Closed

Reported disk space is not granular enough for big drives #494

thingsiplay opened this issue Jul 10, 2023 · 13 comments
Labels
enhancement New feature or request

Comments

@thingsiplay
Copy link

Current state:

The reported available disk space for my big drives is in TiB, which are just whole numbers. That is not granular enough to me. Relevant parts of the discussion:

Disk (/): 122 GiB / 227 GiB (53%)
Disk (/media/Backup): 176 GiB / 917 GiB (19%)
Disk (/media/Emulation): 5 TiB / 5 TiB (84%)
Disk (/media/My): 1 TiB / 4 TiB (33%)
Disk (/media/System): 432 GiB / 916 GiB (47%)

Also rounding makes it worse. It's actually 5,4 TiB and 3,6 TiB, which is significantly different from 5 and 4.

Wanted state:

I would like be able to report the sizes in GiB units instead, just like the drives with smaller sizes. So the reported usage could be displayed like this (just showing suggested parts changed compared to previous):

Disk (/media/Emulation): 4.726 GiB / 5,4 TiB (84%)
Disk (/media/My): 1.132 GiB / 3,6 TiB (33%)

I suggest to introduce an option something called like this:

--disk-unit <unit>:                      Set measurement unit to display...

and <unit> could be one of MiB|GiB|TiB.

Why the change is sensible:

It would make it easier to understand how much space really is left or used up on the bigger drives. At the moment this information is not useful enough, as it is currently implemented, and I have to check it manually for those two drives.
@thingsiplay thingsiplay added the enhancement New feature or request label Jul 10, 2023
@CarterLi
Copy link
Member

I suggest to introduce an option something called like this:

--disk-unit <unit>:                      Set measurement unit to display...

and <unit> could be one of MiB|GiB|TiB.

This breaks small numbers.

I propose --ndigits <num>: The number of digits to keep after the decimal point. Is it enough for you?

@thingsiplay
Copy link
Author

I guess number of digits after decimal point would be an improvement and enough for daily usage. But for consistency reason with existing options I would name it --disk-digits <num>, just a suggestion.

For the breakage of small numbers. Maybe <unit> itself could be a list of allowed units, such as GiB|TiB and only falls to lower unit, if its less then 1.0 in example. I understand this proposal makes everything more complicated and most would not care. So your above suggestion to just add digits is good enough for simplicity sake, without introducing a complete new logic.

@CarterLi
Copy link
Member

But for consistency reason with existing options I would name it --disk-digits <num>, just a suggestion.

The algorithm is used by memory / swap / disk / GPU (GPU memory), not limited to disk.

I named it to --size-ndigits, and defaults to 2

Maybe itself could be a list of allowed units, such as GiB|TiB and only falls to lower unit

I will introduce a new option --size-max-prefix <int>. --size-max-prefix 0 means only B is allowed. --size-max-prefix 1 means only B and KiB are allowed. etc.

@thingsiplay
Copy link
Author

thingsiplay commented Jul 10, 2023 •
edited
Loading

I see. Let me know you need me to test it. Thank you for addressing this issue that quick. Edit: Just an idea to the option name. The prefix does not sound intuitive, I'll suggest --size-max-level or --size-max-unit instead.

@CarterLi
Copy link
Member 

$ ./fastfetch -s memory:swap:disk -l none
Memory: 5.51 GiB / 16.00 GiB (34%)
Swap: 480.62 MiB / 2.00 GiB (23%)
Disk (/): 647.99 GiB / 926.35 GiB (69%) - apfs

$ ./fastfetch -s memory:swap:disk -l none --size-ndigits 0 --size-max-prefix 2
Memory: 5654 MiB / 16384 MiB (34%)
Swap: 481 MiB / 2048 MiB (23%)
Disk (/): 663536 MiB / 948584 MiB (69%) - apfs

$ ./fastfetch -s memory:swap:disk -l none --size-max-prefix 0
Memory: 5912870912 B / 17179869184 B (34%)
Swap: 503971840 B / 2147483648 B (23%)
Disk (/): 695764955136 B / 994662584320 B (69%) - apfs

Please test the latest dev build

@thingsiplay
Copy link
Author

Great! So out of the box without options, I get this related part:

$ ./fastfetch --version
fastfetch 1.12.2-301 (x86_64)

$ ./fastfetch
Disk (/): 121.86 GiB / 227.21 GiB (53%) - ext4
Disk (/media/Backup): 175.71 GiB / 916.70 GiB (19%) - ext4
Disk (/media/Emulation): 4.57 TiB / 5.41 TiB (84%) - ext4
Disk (/media/My): 1.21 TiB / 3.58 TiB (33%) - ext4
Disk (/media/System): 432.28 GiB / 915.82 GiB (47%) - ext4

$ ./fastfetch -s memory:swap:disk -l none
Memory: 4.12 GiB / 15.57 GiB (26%)
Swap: 0 B / 512.00 MiB (0%)
Disk (/): 121.86 GiB / 227.21 GiB (53%) - ext4
Disk (/media/Backup): 175.71 GiB / 916.70 GiB (19%) - ext4
Disk (/media/Emulation): 4.57 TiB / 5.41 TiB (84%) - ext4
Disk (/media/My): 1.21 TiB / 3.58 TiB (33%) - ext4
Disk (/media/System): 432.28 GiB / 915.82 GiB (47%) - ext4

$ ./fastfetch -s memory:swap:disk -l none --size-ndigits 0 --size-max-prefix 2
Memory: 4208 MiB / 15945 MiB (26%)
Swap: 0 B / 512 MiB (0%)
Disk (/): 124784 MiB / 232658 MiB (53%) - ext4
Disk (/media/Backup): 179922 MiB / 938699 MiB (19%) - ext4
Disk (/media/Emulation): 4794393 MiB / 5676932 MiB (84%) - ext4
Disk (/media/My): 1271121 MiB / 3754445 MiB (33%) - ext4
Disk (/media/System): 442654 MiB / 937797 MiB (47%) - ext4

$ ./fastfetch -s memory:swap:disk -l none --size-max-prefix 0
Memory: 4426055680 B / 16719630336 B (26%)
Swap: 0 B / 536866816 B (0%)
Disk (/): 130845982720 B / 243960045568 B (53%) - ext4
Disk (/media/Backup): 188661948416 B / 984297123840 B (19%) - ext4
Disk (/media/Emulation): 5027285020672 B / 5952694763520 B (84%) - ext4
Disk (/media/My): 1332867035136 B / 3936820731904 B (33%) - ext4
Disk (/media/System): 464156491776 B / 983351140352 B (47%) - ext4

This is pretty good and solves my issue I had pretty well! I don't even need to use any options. The addition of digits after decimal point is sufficient. Maybe the GiB listing without decimal would make it more readable, and it's not really needed there. What about adding decimal points, if the numbers are low. Like 1.21 TB, 34.3 GB and nothing for 234 GB or bigger.

However, I noticed the output of the other stuff is very different from my native installed version. I'll show both full output without options (other than -l none, and without the color block). Is this expected, due to changes or so? The native installed version is compiling directly from the AUR. Note: Backslash at \fastfetch is so it does not interfere with any shell alias. The stuff is not correct in the new version from Git.

Native installed version from AUR:

$ \fastfetch --version
fastfetch 1.12.2 (x86_64)
$ \fastfetch -l none
tuncay@DOOM
-----------
OS: EndeavourOS x86_64
Kernel: 6.1.38-1-lts
Uptime: 2 days, 52 mins
Packages: 1131 (pacman), 29 (flatpak)
Shell: bash 5.1.16
Display: 2560x1440 @ 120Hz
DE: qtile
WM: Qtile 0.22.1 (X11)
Theme: Arc-Dark [GTK2/3]
Icons: Qogir-dark [GTK2/3]
Font: Cascadia Code (12pt) [GTK2/3]
Cursor: Qogir (0px)
Terminal: xfce4-terminal 1.0.4
Terminal Font: Cascadia Code (13pt)
CPU: Intel(R) Xeon(R) E3-1230 v3 (8) @ 3.7 GHz
GPU: NVIDIA GeForce GTX 1070
Memory: 4.12 GiB / 15.57 GiB (26%)
Disk (/): 122 GiB / 227 GiB (53%)
Disk (/media/Backup): 176 GiB / 917 GiB (19%)
Disk (/media/Emulation): 5 TiB / 5 TiB (84%)
Disk (/media/My): 1 TiB / 4 TiB (33%)
Disk (/media/System): 432 GiB / 916 GiB (47%)
Locale: en_US.UTF-8

Newest version from Git:

$ ./fastfetch --version
fastfetch 1.12.2-301 (x86_64)
$ ./fastfetch -l none
tuncay@DOOM
-----------
OS: EndeavourOS x86_64
Kernel: 6.1.38-1-lts
Uptime: 2 days, 53 mins
Packages: 1131 (pacman), 29 (flatpak)
Shell: bash 5.1.16
Display (DP-0): 2560x1440 @ 120Hz
DE: Gnome
WM: Qtile (X11)
Theme: Adwaita [GTK2/3/4]
Icons: Adwaita [GTK2/3/4]
Font: Cantarell (11pt) [GTK2/3/4]
Cursor: Adwaita (24px)
Terminal: xfce4-terminal 1.0.4
Terminal Font: Cascadia Code (13pt)
CPU: Intel(R) Xeon(R) E3-1230 v3 (8) @ 3.7 GHz
GPU: NVIDIA GeForce GTX 1070 (288.00 MiB) [Integrated]
Memory: 4.14 GiB / 15.57 GiB (26%)
Disk (/): 121.87 GiB / 227.21 GiB (53%) - ext4
Disk (/media/Backup): 175.71 GiB / 916.70 GiB (19%) - ext4
Disk (/media/Emulation): 4.57 TiB / 5.41 TiB (84%) - ext4
Disk (/media/My): 1.21 TiB / 3.58 TiB (33%) - ext4
Disk (/media/System): 432.28 GiB / 915.82 GiB (47%) - ext4
Locale: en_US.UTF-8

@CarterLi
Copy link
Member

However, I noticed the output of the other stuff is very different from my native installed version. I'll show both full output without options (other than -l none, and without the color block). Is this expected, due to changes or so?

It is expected. We are consistantly adding new features (detect more things) to fastfetch.

Please make comments if there are anything you dont like.

@thingsiplay
Copy link
Author

thingsiplay commented Jul 10, 2023 •
edited
Loading

But the output is plain wrong in the new version. My guess is, that the manually build version misses dependencies, and the AUR version compiles it with all optional packages to detect everything correctly. In example my graphics card in the new version is detected as GPU: NVIDIA GeForce GTX 1070 (288.00 MiB) [Integrated] or the Font, Icons, Themes and a few other stuff is incorrect. If the AUR package is updated, I can check if my theory is correct, but at the moment its still the "old" version.

And as you asked to comment things I don't like: I would rather not have a number for the option argument for readability. Instead --size-max-prefix 2 I suggest in example --size-max-prefix G.

@CarterLi
Copy link
Member

In example my graphics card in the new version is detected as GPU: NVIDIA GeForce GTX 1070 (288.00 MiB) [Integrated] or the Font, Icons, Themes and a few other stuff is incorrect.

File an new issue please

@CarterLi
Copy link
Member

Instead --size-max-phrefix 2 I suggest in example --size-max-prefix G.

ok

@thingsiplay
Copy link
Author

I did (not sure if I should link it here, because it is not related). Should I delete the part from my previous comment, that is now on the new issue?

@CarterLi
Copy link
Member

Instead --size-max-phrefix 2 I suggest in example --size-max-prefix G.

ok

Done

@CarterLi
Copy link
Member

I did (not sure if I should link it here, because it is not related). Should I delete the part from my previous comment, that is now on the new issue?

It's ok. Please close this issue if you have no more requirements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thingsiplay @CarterLi