Disk Usage calculation stuck

[mmolivier]

When I click the "Details" button under Server > Disk Usage it gets stuck at about 25%. The logs show it's hanging at the following line:

box:shell system: /usr/bin/sudo --non-interactive /home/yellowtent/box/src/scripts/du.sh /srv/[redacted]

This /srv/[redacted] directory is configured as a filesystem volume which contains various symlinks, of which:

1. products points to products_s3fs (this symlink is here as an 'entry point' so i can quickly switch to another target when necessary)
2. products_s3fs points to /media/path_to_s3fs
3. a lot of symlinks within subdirectories which point to paths relative to /app/data/public

I know s3fs isn't officially supported by Cloudron, but in theory du should simply skip/ignore these symlinks because they shouldn't resolve anywhere, as these paths only exist at app level. Maybe it gets stuck because of some recursion issue at the first symlink.

Maybe the solution is to simply never follow symlinks during disk usage calculation.

Any ideas? Thanks!

[joseph]

Can you check if running du manually works? du -DsB1 /srv/[redacted] ?

[mmolivier]

Hi @joseph,
I've tried:

• du -DB1 /srv/[redacted]: removed the s to see output, takes a while (it's a lot of symlinks) but it does complete
• du -B1 /srv/[redacted]: removed the D to no longer follow symlinks, much faster, same end result, does complete as well

Context: SSH session, logged in as root. Tried to log in as 'yellowtent' to retry using sudo but I got 'This account is currently not available.'

[nebulon]

Since cloudron here just runs the very same du command https://git.cloudron.io/platform/box/-/blob/master/src/scripts/du.sh?ref_type=heads I wonder if there might be some more information in error logs like in /home/yellowtent/platformdata/logs/box.log or maybe some timeouts seen in the browser, which would probably be bugs to fix?

[mmolivier]

@nebulon I think I'm seeing where it fails now. I have s3fs mounts set up and the Disk Usage Calculation seems to include these:

Jan 22 12:16:08 box:shell df: df -B1 --output=source,fstype,size,used,avail,pcent,target /mnt/[path_to_s3fs]

That will obviously fail (or at least take ages) because du will try to navigate my s3fs mounts.

Suggestion for a fix:

• Consider removing D because it slows things down a lot when there's lots of symlinks
• In case of mountpoints, instead of du -DsB1 /mnt/path you could du -DxB1 /mnt with some additional filtering/grouping, or just du -DxB1 /mnt | grep /mnt/path (less efficient obviously).

[girish]

-D only dereferences links in the command line and not inside the filesystem. I guess you want -P which the default.

       -D, --dereference-args
              follow only symlinks that are listed on the command line

       -P, --no-dereference
              don't follow any symbolic links (this is the default)

Can you please check again if -D is the one which makes such a big difference?

[girish]

I am happy to add -x if that helps. I think the intent was to keep results to the filesystem.

       -x, --one-file-system
              skip directories on different file systems

[mmolivier]

Hi @girish sorry for the delay.

I think -D does not necessarily impact performance, my test after removing -D was much quicker but after adding it again it was just as quick. Seems like there's some kind of filesystem caching. Maybe at some point I could analyse the differences but I suspect changing this doesn't impact performance so much.

The part that does impact performance a lot is the -x flag, but as far as I've seen, that will only prevent iteration on the remote (s3fs) filesystem if du is initiated on the parent dir, e.g. /mnt and not on the mount itself /mnt/s3fs.

Would be a lifesaver if you could add this, but understandable if it cannot be done. If it cannot be done, a workaround to exclude certain volumes from disk usage calculation would be fine too. Or maybe you could add an option to the Disk Usage UI: Offer an option to include/exclude certain volumes before actually executing calculation