dfc
dfc copied to clipboard
Feature absgraph
On #23 This is only a wip, I want to keep track of various things during development. There are still things tbd:
- [ ] translation of the new options in the help text & man page (I don't speak dutch or french so I can't do this)
- [x] support for absolute graphs in html output
- [x] support for absolute graphs in tex output
- [x] maybe also add an option the the rc file
- [x] what should we do with the summary line?
Anyways, here is a very basic version that works in text mode and showcases my idea.
For the record, on my server it looks like this:
/dev/sdb1 [=================---] 85.1% 138.8G 931.5G /media/00
/dev/mapper/vc1 [===========-- ] 91.7% 48.5G 585.8G /media/01
/dev/mapper/vc2 [===============-----] 82.0% 164.6G 915.9G /media/02
/dev/mapper/vc3 [========----- ] 69.0% 181.4G 585.8G /media/03
or in wide mode:
/dev/sdb1 [===========================================-------] 85.1% 138.8G 931.5G /media/00
/dev/mapper/vc1 [===========================---- ] 91.7% 48.5G 585.8G /media/01
/dev/mapper/vc2 [======================================----------- ] 82.0% 164.6G 915.9G /media/02
/dev/mapper/vc3 [====================----------- ] 69.0% 181.4G 585.8G /media/03
I think it worked out rather nicely. Am going to continue work on the other exports, have a nice evening.
Another problem I've encountered: On current upstream, the percentage is calculated using
100 % - blocks_avail / blocks
However, for the absolute graph, I calculate the percentage using
size_used / size
Note that I use the size while originally the block count is used. Also, size is not always this volume's size, but the greatest volume's size. I'm not sure, but I think that blocks of different volumes are not (always) comparable (because they might be of different size).
Because these are two different percentages, my fork displays different fs usages:
On my root partition the first one is 93,7 %
while the second one is only 85,75 %
(looks like lots of small files).
This partition is 100 gb btrfs.
I have to think of a way to solve this problem.
- The first calculation makes a lot more sense, so I can't really change the printed %AVAIL to also use the second calculation.
- However, as mentioned above, blocks on different disks aren't really comparable (correct me if I'm wrong) so I can't use the first calculation to print the absolute graphs.
Here is another thing I've noticed (this is with upstream dfc):
dev [--------------------] 0.0% 2.8G 2.8G /dev
run [=-------------------] 0.0% 2.8G 2.8G /run
Notice how both have 0.0% usage but the first one displays only dashes while the second row shows a single = followed by dashes.
This is because the 0.0 % of the first are accurately 0.0000 % while the second one is 0.04 % which gets rounded down on output.
I don't know whether that's the desired behaviour.
Also, I don't have any experience using cmake
.
At some point during the build it changes things in the /po/*.po
:
diff --git a/po/fr.po b/po/fr.po
index 1faabb9..14253d7 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -7,7 +7,7 @@ msgid ""
msgstr ""
"Project-Id-Version: dfc 3.1.1\n"
"Report-Msgid-Bugs-To: [email protected]\n"
-"POT-Creation-Date: 2017-09-11 13:26+0200\n"
+"POT-Creation-Date: 2020-12-05 09:09+0100\n"
"PO-Revision-Date: 2012-04-15 13:52+0200\n"
"Last-Translator: Robin Hahling <[email protected]>\n"
"Language-Team: French\n"
@@ -17,41 +17,43 @@ msgstr ""
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
-#: src/dfc.c:214
+#: src/dfc.c:218
#, c-format
... many more
Notice the change in the second-to-last-line. Should I commit these two or simply discard those changes?
~There are still things to do but this'd be the first part~
From what I can see, none of the comparable runtime flags can be set through the rc file, so I guess an option to set this new flag throught the rc file isn't wanted either.
d17a5df are the newly generated po files, I still don't know if the changes to them are needed. Discard the commit if not.
Ready for review @Rolinh
@scrouthtv Are you still working on this?
Here it is. I missed your comment on authors.md somehow. Tell me if there's anything else to fix.
Tell me if there's anything else to fix.
Yes, what I reported above:
It looks like the size of the bar for the sum is off.
What do you mean by off? I want the bar for the sum to be bigger than the rest (as big as all individual bars together) as all bars share the same scale. In your example, each character represents ~ 25.8 GB so
- /dev/nvme1n1p2 with 496 GB has 496 / 25.8 = 19 characters
- total of 608 GB has 608 / 25.8 = 24 characters
That's why the total bar is bigger than the rest. And I think even in your example, its size is correct.
Mmh I see. However, the columns after the bar are misaligned. It's probably just because the width of the sum bar is not taken into account to compute the column's width. This should be adjusted.
Ah, now I've got you. Looks like the 39 in text.c in line 172 is off. I will look into it.
48
is the correct value, but the other columns will still be off in wide mode.
As the columns are always in the same order, the offset I need adds up by
-
max.fsname
-
max.fstype
-
max.bar
Fixed:
Now I have to check if this is happening in other modes too.
Sorry for the slow work, I got drawn away by college stuff, should be done now.
@scrouthtv Sorry for my late reply. I think there still are issues with alignment of the sum row:
% ./build/bin/RELEASE/dfc -As
FILESYSTEM (=) USED FREE (-) %USED AVAILABLE TOTAL MOUNTED ON
dev [- ] 0.0% 31.4G 31.4G /dev
run [= ] 0.0% 31.4G 31.4G /run
/dev/nvme1n1p2 [========------------] 37.1% 575.4G 915.4G /
tmpfs [= ] 0.2% 31.3G 31.4G /dev/shm
tmpfs [- ] 0.0% 4.0M 4.0M /sys/fs/cgroup
tmpfs [= ] 0.0% 31.4G 31.4G /tmp
/dev/nvme1n1p1 [= ] 0.1% 510.7M 511.0M /efi
tmpfs [= ] 0.0% 6.3G 6.3G /run/user/1000
SUM: [=======----------------]
28.0% 707.7G 1.0T
Sorry for my late reply ;) I have a lot going on with college at the moment.
I think I finally fixed it:
~ git rev-parse --short HEAD
5da773a
~ ./build/bin/RELEASE/dfc -As
FILESYSTEM (=) USED FREE (-) %USED AVAILABLE TOTAL MOUNTED ON
dev [- ] 0.0% 3.7G 3.7G /dev
run [= ] 0.0% 3.7G 3.7G /run
/dev/sda1 [==------- ] 18.0% 160.6G 195.9G /
tmpfs [= ] 9.4% 3.4G 3.7G /dev/shm
tmpfs [- ] 0.0% 4.0M 4.0M /sys/fs/cgroup
tmpfs [= ] 1.4% 3.7G 3.7G /tmp
/dev/sdb1 [==------------------] 5.1% 434.1G 457.4G /data
/dev/mapper/home [==-------- ] 12.9% 187.8G 215.5G /home
tmpfs [= ] 0.2% 761.1M 763.0M /run/user/1000
SUM: [==-------------------------------------]
4.8% 797.8G 884.5G
~ ./build/bin/RELEASE/dfc -Asw
FILESYSTEM (=) USED FREE (-) %USED AVAILABLE TOTAL MOUNTED ON
dev [- ] 0.0% 3.7G 3.7G /dev
run [= ] 0.0% 3.7G 3.7G /run
/dev/sda1 [====------------------ ] 18.0% 160.6G 195.9G /
tmpfs [= ] 9.7% 3.4G 3.7G /dev/shm
tmpfs [- ] 0.0% 4.0M 4.0M /sys/fs/cgroup
tmpfs [= ] 1.4% 3.7G 3.7G /tmp
/dev/sdb1 [===-----------------------------------------------] 5.1% 434.1G 457.4G /data
/dev/mapper/home [====-------------------- ] 12.9% 187.8G 215.5G /home
tmpfs [= ] 0.2% 761.1M 763.0M /run/user/1000
SUM: [=====--------------------------------------------------------------------------------------------]
4.8% 797.7G 884.5G
Here is a bug I noticed: If the tty can only fit normal graph mode, but wide graph mode is passed as a cli parameter, the title bar is also off:
~ git checkout v3.1.1
~ git rev-parse --short HEAD
e5f8c3b
~ make
// Now resize the terminal to around 100 columns
~ ./build/bin/RELEASE/dfc -w
WARNING: TTY too narrow. Some options have been disabled to make dfc output fit (use -f to override).
FILESYSTEM (=) USED FREE (-) %USED AVAILABLE TOTAL MOUNTED ON
dev [--------------------] 0.0% 3.7G 3.7G /dev
run [=-------------------] 0.0% 3.7G 3.7G /run
/dev/sda1 [====----------------] 18.0% 160.6G 195.9G /
tmpfs [===-----------------] 10.2% 3.3G 3.7G /dev/shm
tmpfs [--------------------] 0.0% 4.0M 4.0M /sys/fs/cgroup
tmpfs [=-------------------] 1.4% 3.7G 3.7G /tmp
/dev/sdb1 [==------------------] 5.1% 434.1G 457.4G /data
/dev/mapper/home [===-----------------] 12.9% 187.8G 215.5G /home
tmpfs [=-------------------] 0.2% 761.1M 763.0M /run/user/1000
I'd say that this can be fixed by changing the value of max.bar
in util.c#auto_adjust()
(depending on which path was taken).