Cloudron Forum

It looks like the problem is indeed gone with 8.1
Thank you!

As du is slow and resource hungry, maybe use an alternative?
Diskus is a parallelized version: https://github.com/sharkdp/diskus, claims to be 5-10 times faster.
Though not in the repos

Yes, that’s a build-in docker command that you can run in your ssh terminal

When I log in, the Empty Space has enlarged and back to the 16 Nov level. Weird though. Will keep an eye on it and report it if it rises again.

it's just a SSD so around 500 MB/s

@girish said in Why does refreshing Disk Usage take so long?:

Are you using a CIFS/Storage Box ? Doing a du -Dsb takes forever on those.

Yes, ah. So perhaps it's those that is taking forever anyway, and so adding little refresh buttons just for those probably wouldn't help too much. Ah well, nevermind. No biggie.

Maybe you have dangling images around, which are not deleted, can you see if docker image prune -a removes some?

The collabora app image is fairly large due to all the language support packages. So far we haven't found a way to make those dynamically selectable.

Also it appears you have a lot of data for the system itself, possibly you have some old leftover backups in /var/backups which could be purged, if you have configured a proper backup storage?

@jpodner I had the same issue. Solved it by following the instruction on this page to extend my LVM space.

https://packetpushers.net/ubuntu-extend-your-default-lvm-space/

Btw, I applied the changes of the system.js according to the changelog to solve this problem in my environment until the update is available. So at least for myself this Post could be set to "solved".

@3246 I think this is a known problem for people how have CIF/SSHFS/possible other mounts which is already fixed in the next version.

@girish said in Cloudron 7.3.2: "Analyze Disk" doesn't do anything:

OK, I have fixed this now. The code is was not handling CIFS/SSHFS volumes correctly.

@girish said in Cloudron 7.3.4: "Analyze Disk" doesn't do anything and no statistics shown...:

Thanks all. This issue was already fixed as well last month - https://git.cloudron.io/cloudron/box/-/commit/67cde5a62cf0394c8bf2d78ee3408e5995a220e7 . It's already in 7.3.5.

Essentially, if you have CIFS/NFS/SSHFS, there is a crash.

Thanks all. This issue was already fixed as well last month - https://git.cloudron.io/cloudron/box/-/commit/67cde5a62cf0394c8bf2d78ee3408e5995a220e7 . It's already in 7.3.5.

Essentially, if you have CIFS/NFS/SSHFS, there is a crash.

@girish said in Disk usage issue:

https://git.cloudron.io/cloudron/box/-/commit/67cde5a62cf0394c8bf2d78ee3408e5995a220e7 is the fix if you want to patch it yourself.

Thanks, I wouldn't know where to start with that, but I guess useful for others who do 🙂

This is already fixed in the upcoming patch release.

@RazielKanos So 11GB docker is reasonable but the Everything else is almost 46GB. That one is not. Where do you store your backups ? Please note that if you moved to a location outside the server, Cloudron does not delete the previous backups! The default Cloudron backup location is /var/backups . So, you might have to delete the things in /var/backups manually.

so this should be fixed with the next release now, where we replaced https://www.npmjs.com/package/@sindresorhus/df with our own implementation which calls the df command in a more locale safe way.

@nebulon Thanks guys.

@girish said in Cloudron 7.3.2: "Analyze Disk" doesn't do anything:

The code is not handling CIFS/SSHFS volumes correctly.

was not, is now?

If you make sure that newer backups are off-server so not anymore in /var/backups, you can safely delete all files from that folder.

@robi Good point ... I think it's this way because one way to expand boxdata/appdata/platformdata is using symlinks. Then there's volumes , backups. So, it was easier to filter out by known filesystems.