# Docker disk usage issue c. Sept 1 2017
**URL:** https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194
**Category:** Self-hosting
**Created:** [1 september 2017 om 09:52 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194 "2017-09-01T09:52:21Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [1 september 2017 om 09:52 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194/1 "2017-09-01T09:52:21Z")
If you do a fresh install, as I did recently for my [sandbox](https://discourse.angusmcleod.com.au/), you may, despite all the improvements in the cleanup scripts and docker itself, still encounter the dreaded disk usage creep issue; i.e. after rebuilding a number of times you see your disk usage go steadily upwards until the instance is no longer usable.
This issue has had a number of iterations (hence ‘circa Sept 1 2017’). The current iteration seems to be un-removed `aufs/diff` files.
Specifically, after a fresh Discourse install on a DO 1G Memory / 30G HD droplet, and running `./launcher rebuild app` a few times my `/var/lib/docker/aufs/diff` folder looked like this
```plaintext
root@discourse:/var/discourse# sudo du -hd 1 /var/lib/docker/aufs/diff | sort -hrk 1 | head -20
19G /var/lib/docker/aufs/diff
1.8G /var/lib/docker/aufs/diff/4164965e95f8bbe50b181d96e92ca48658ce57edfeefa0143d484bb1dd894653
1.1G /var/lib/docker/aufs/diff/d40d45c7274e8dea5a14f0705bdcf92cdf966b85d654e18f32e97c7bec0b20f3-removing
1.1G /var/lib/docker/aufs/diff/ba1aae9ec74952b960f9286a7d76f6792054f055aaafb2c1855660be92b15c6d-removing
1.1G /var/lib/docker/aufs/diff/b1c46d5904681264046779dfb1bef34659f592859481f679d33bf64a48f85363-removing
1.1G /var/lib/docker/aufs/diff/a42be4d77fddbfd1e0b3fc4c8580db017413bffcc258dc9696186e38ceb6a9b9-removing
1.1G /var/lib/docker/aufs/diff/7f4fffafb2d96f038e3b40739d602ab4c038de21effa163900a1a8987b301770-removing
1.1G /var/lib/docker/aufs/diff/4e6c6a7c74c7a6df64f5852f44ee4fb01998d0271ed9b9f30fe1176269cc6f58-removing
1.1G /var/lib/docker/aufs/diff/3dd6e740aee8af437d70a49fe5cfc73fc091dc976bb170629bd3a4a953a05786-removing
1.1G /var/lib/docker/aufs/diff/1e93113fcc299cccd8d90c22e46b6c5a6f5b3fda14c046d0403cc604731abd6d
1020M /var/lib/docker/aufs/diff/f7397e9843aa175361686a5edeb7c77ac5c6754bf5e4662d7f507ccb1f012a71-removing
1020M /var/lib/docker/aufs/diff/c3647165501e41129687594b06b73acd8fd96f7959014f5c6ae3fa71caa13824-removing
1020M /var/lib/docker/aufs/diff/9393f77e06db23cb200b465cf0baa38fb403ac9ae3d993ceca69a57cdc389bfd-removing
1020M /var/lib/docker/aufs/diff/862f2e0fb2caf2317cc3146461d48d23f193e8c0f22a58eb2c1078ea7e903ffc-removing
1020M /var/lib/docker/aufs/diff/0bd33c4272acaa9766982fd0f2251e0f9912b1d1a7cbc3b019362e0ac3a812b9-removing
1017M /var/lib/docker/aufs/diff/18b727db320d769b3ec4be54552872fea051c14d40cb62bcaa74a71287f011b3-removing
1016M /var/lib/docker/aufs/diff/8700c369592b80d5c1302a27fdb198581c218b2000d17e7c7a6b60137bd6f56f-removing
1014M /var/lib/docker/aufs/diff/329ae8ff791d6b41409b2ba06fef593bdf92d2361ac0629e07478ea88aa2f00c-removing
182M /var/lib/docker/aufs/diff/30b1731d18550c37e596b08a04a6896d0a777c0dfb40ff03c4008d1e7c7d71bc-removing
139M /var/lib/docker/aufs/diff/cdbd9d560aa8ab7eb8d5c6a05414645c4c58d8805113550653a957a199ce2a45-removing
```
None of the following touched it:
- `./launcher cleanup`
- Using Spotify’s `docker-gc` directly
- Docker’s own `docker system prune`
After reading the relevant [`moby/moby` issue](https://github.com/moby/moby/issues/22207) for this and trying all the suggested solutions, the only one that seems to work reliably at this stage is the proverbial ‘nuclear’ option:
```plaintext
sudo service docker stop
rm -rf /var/lib/docker
sudo service docker start
```
This ‘fixes’ the issue insofar as you are able to use your instance again - i.e. rebuild the app - and your data remains intact (as far as I can tell so far).
cc @Falco @sam
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [1 september 2017 om 11:25 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194/4 "2017-09-01T11:25:57Z")
Neither one of the people you pinged are available to look at this in the next 2 weeks.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [1 september 2017 om 11:26 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194/5 "2017-09-01T11:26:50Z")
That’s fine. I fixed it for my own purposes for now. I’m guessing others may encounter the issue and find this useful.
It’s not so much a Discourse issue as a Docker issue anyway.
---
### Author:  [@mc0e](https://meta.discourse.org/u/mc0e)
#### Post date: [1 september 2017 om 16:23 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194/6 "2017-09-01T16:23:48Z")
I’m having the same issue. I’ll be watching this space for a better clean-up method in case one is posted.
I’m not sure why this issue arises now on multiple installations where it hasn’t been an issue I’ve seen previously.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [18 september 2017 om 04:35 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194/7 "2017-09-18T04:35:28Z")
It looks like this issue is much improved on the latest version of Docker. I haven’t had to `rm -rf /var/lib/docker` for a while.
If you encounter this issue make sure your docker version is `17.06.2-ce` or later.
See further: [orphaned diffs · Issue #22207 · moby/moby · GitHub](https://github.com/moby/moby/issues/22207)
---
### Author:  [@jd2066](https://meta.discourse.org/u/jd2066)
#### Post date: [7 februari 2018 om 12:10 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194/8 "2018-02-07T12:10:36Z")
I just did some tests and found that to get an accurate count of disk usage for /var/lib/docker, you need to pass the -x option to du so it doesn’t count files in mounted overlay file systems.
Stopping docker, which unmounts the overlay filesystems will also work but of course is less convenient then just using the -x option for du.
At least this is the case when using the overlay2 docker backend, I would assume it’s the same for most of the docker backends.
Edit: Strangely the sizes reported by running ‘docker images’ shows image ‘local\_discourse/app’ with a size of 2.82GB and image ‘discourse/base’ with a size of 1.73GB.
Which would mean the images take 4.55 GB but running ‘du -sh /var/lib/docker’ shows 3.1GB total.
I’m not sure why there is a difference in size or why there are two images for discourse.
Maybe the images share files and the ‘docker images’ command doesn’t account for that.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [7 februari 2018 om 21:30 UTC](https://meta.discourse.org/t/docker-disk-usage-issue-c-sept-1-2017/69194/9 "2018-02-07T21:30:05Z")