"Platform data" and "Other" disk usage

  • With the new disk usage visualization I can see that "Platform data" takes up a whopping 19GB on a Cloudron instance of mine. "Other" is also hogging. Is that reasonable?


  • This does look a bit excessive. Can you dig a bit further there and see which part of platform data consumes much?
    You can see that with du -sh /home/yellowtent/platformdata/* via SSH.

  • I got helped out by gramakri. It was some 19GB log file taking up space. I will know where to look next time.

    Are there other optimizations possible? For instance, outdated docker images?

  • @yusf: Can you post your solution? Where is the log file located and what did you do with it (just delete it)? What about the "Other"?

  • I just noticed mine at 10.24 GB for "Other". What is that and how do we clear it up (if it's even safe to do so)?

    Side note: Would be great if the feature graph would also do the math to show how much remaining space exists so we don't have to do the math ourselves. 😉 I think I'll file that feature request separately later on.

  • @d19dotca Please check the size of /home/yellowtent/platformdata/logs. We have a logrotate issue which is not cleaning up logs properly. You can delete some of the old files there safely.

  • I have the same problem.

    I identified:

    47G /var/lib/docker

    30G /var/backups

    Backups i can understand but Docker folder is kind of big.

    Screenshot from 2019-11-06 21.57.25.png

    Any ideea?

    du -sh /home/yellowtent/platformdata/*

    4.0K /home/yellowtent/platformdata/INFRA_VERSION
    4.0K /home/yellowtent/platformdata/VERSION
    4.0K /home/yellowtent/platformdata/acme
    28K /home/yellowtent/platformdata/addons
    12K /home/yellowtent/platformdata/backup
    24K /home/yellowtent/platformdata/collectd
    67M /home/yellowtent/platformdata/graphite
    12K /home/yellowtent/platformdata/logrotate.d
    344K /home/yellowtent/platformdata/logs
    511M /home/yellowtent/platformdata/mongodb
    132M /home/yellowtent/platformdata/mysql
    60K /home/yellowtent/platformdata/nginx
    77M /home/yellowtent/platformdata/postgresql
    1.9M /home/yellowtent/platformdata/redis
    4.0K /home/yellowtent/platformdata/sessions
    108K /home/yellowtent/platformdata/update

  • @Warez Did you use du -hcs to get docker storage size? Because the du tool does not work correctly with the overlayfs that docker uses. Instead use docker system df output.

    Images 10 9 2.591GB 1.33GB (51%)
    Containers 10 9 0B 0B
    Local Volumes 22 18 21.79MB 31.76kB (0%)
    Build Cache 0 0 0B 0B

  • @Warez The 2.5GB there seems OK. Our docker app images are not disk usage optimized.

  • I understand, but why does cloudron report Other 82.82 GB?

  • "Other" might not be the best term in hindsight. Basically it is just the sum of everything else on the system. For example the Linux system/distro data itself, as well as data which is otherwise placed outside of Cloudron known folders, if any.

    If anyone has a better term for that, to convey this information, I am happy to adjust it, if we find a good one.

  • @nebulon what about just "System" 😉

  • Hi,

    I have another question regardiing this. The following is the output of docker system df.

    $ docker system df
    TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
    Images              34                  16                  9.857GB             6.508GB (66%)
    Containers          21                  18                  0B                  0B
    Local Volumes       160                 36                  5.274GB             3.964GB (75%)
    Build Cache         0                   0                   0B                  0B

    As you can see, docker claims that a lot of storage is reclaimable.

    Is it safe to run docker volume prune and docker image prune?

  • The prune commands should be safe to run. Unless there is some Cloudron bug, it shouldn't remove anything.

  • @girish thank you.

    That worked for docker volume prune. The other command (docker image prune) did not actually clean anything up though, but the output of docker system df stays with 66% reclaimable.

    Any further ideas?

Log in to reply