How to show SD space still available?

Hi guys,
I recently discovered Nymea, but I really like it. I installed it on a Raspberry 0 with a 4GB SD. The system works quite well, and it is not my intention overloading it, I know I can’t ask for too much. It would be very useful to be able to have some other information in the state of the system, such as the SD space still available. As I could report on Nymea the data generated by a UNIX line command as “DF”:


nymea@nymea:~ $ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root        3443008 1967424   1299460  61% /
devtmpfs           88616       0     88616   0% /dev
tmpfs             219908       0    219908   0% /dev/shm
tmpfs              87964     908     87056   2% /run
tmpfs               5120       4      5116   1% /run/lock
/dev/mmcblk0p1    258095   50411    207685  20% /boot
tmpfs              43980       0     43980   0% /run/user/1000

Thanks

Hi @mosix,

That could probably fit into the systemmonitor plugin. Thanks for the suggestion.

@mosix I’ve added such a feature to the systemmonitor plugin. You can test it from the experimental repository. Currently it only shows the percentage of the disk usage for the root volume but that should be enough for most cases (including yours afaict).

Ciao Michael, and thank you for remembering my request. She is good news. I will try to use this value in a rule to be warned when a certain threshold is exceeded… it can be done, right? :grinning:

Yes, you can create rules that compare the disk usage and trigger actions.

I’ve just reworked the plugin a bit more and have split the functionality into 2 thing classes:

  • One named Process monitor which allows monitoring individual processes as the old one did, but additionally allowing to monitor other processes too, not just nymead itself.
  • The second named System monitor which would show CPU, memory and Disk usage for the overall system.

This may break your rule on the next update in experimental.

1 Like

Hi @mzanetti thanks for the nice upgrade of system monitor!
I will also use that now in a warning Notification, since some system logs filled up my SD.

I have a question regarding the Storage usage state:
Storage usage (in my case 48.53%) is /dev/root right?

The numbers would fit better to that backup SMB mount - so I am a bit confused:

nymea@nymea:/ $ df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/root             15G  7.0G  6.8G  51% /
devtmpfs             776M     0  776M   0% /dev
tmpfs                937M     0  937M   0% /dev/shm
tmpfs                375M  1.2M  374M   1% /run
tmpfs                5.0M  8.0K  5.0M   1% /run/lock
/dev/mmcblk0p1       247M   51M  196M  21% /boot
tmpfs                188M     0  188M   0% /run/user/1000
//10.0.0.10/Backups  500G  239G  262G  48% /home/nymea/backup

Additionally, I was also wondering that Memory usage says 90.09% even though htop says that it is just a bit over 30%.

Maybe you can help me to interpret the numbers correctly.

I’ve looked into this now. Turns out, the memory usage was indeed wrong. The used api didn’t exclude information about the cached memory (the yellow part in your htop screenshot). I’ve fixed this.

For the storage use, I believe it should be the correct volume, but the calculation is done slightly different. As you can see, the size of 15G doesn’t line up with Used (7) + Available (6.8), which is 13.8. The actual usable size is smaller than the total volume size, depending on various factors like FS type, block size etc. So, depending on which values are used for the calculation they may not line up. To be honest I’m still not sure how df exactly comes up with 51, but the closest I come is by using 100 * used / (used+available), which is 50.7%. This does line up in your particular example, but in my case it still doesn’t (44% vs 43,1%):

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  1,9T  769G 1013G  44% /

Anyhow, I did adjust the calculation in nymea to be as close as possible to df to reduce the confusion.

Thank you @mzanetti :relaxed: