Disk space usage leak in Docker for Mac
github.com
github.com
Switching to `virtio-scsi` and sending regular TRIMs could fix this issue. It looks like they're also allowing people to configure the maximum size of the qcow2 image, which puts a hard upper bound on how much space the VM will take.
You're completely right -- it's a problem caused by lack of TRIM in the storage path. In the next beta of Docker for Windows (beta 31 due today hopefully) TRIM should be enabled. The Mac will take a little longer as we need to switch protocols and do more work on the host side -- unfortunately the default Apple filesystem doesn't support sparse files so we can't "cheat" by simply passing the TRIM down to the filesystem layer. We'll probably need some kind of explicit block-level compaction to shuffle blocks from the end of the file into holes that have been created by TRIM.
https://forums.docker.com/t/file-access-in-mounted-volumes-e...
From what I can tell, that issue was never truly resolved. The advice is like the adage about finding romance, "Have enough storage, don't run out of storage." As long as you follow that advice, you will never have a problem.
Oh, you installed Docker on a cloud provider with limited local disk, or on your laptop? Silly you for thinking that a finite amount of storage and the default configuration of Docker was adequate.
In addition, they don't seem to care that the whole thing is useless in China - https://github.com/docker/docker/issues/28791 - also after emailing, no response.
I have contributed to Docker since very early days but am frankly not using it now because the project has for all intents and purposes entered a toxic-to-the-community stage where hype and marketing exceed capacity to resolve issues, total fails are occurring for me on all platforms, and AFAIK nobody in their over-funded San Franciscan office bubble seems to care. It's a typically arrogant startup: not listening to users, heading for a fall.
It's like they've decided to re-invent downloads (badly), re-invent cross-platform hypervisors (badly), re-invent orchestration (badly), re-invent storage (badly) and roll it all up in branded glue. I can't help but wonder if an approach with broader applicability and longevity would segregate the OS (anything container or VM-like at any layer, from Erlang to BSD jails to diskless clusters), and environment paradigm (container-based, paravirtualization-based, bare metal) from the workload and truly enable infrastructure agnoticism by removing the dependency on a single shifting-sands component, and allowing people to A/B test identical workloads on disparate paradigm infrastructures. I tried a few years ago, it worked: http://stani.sh/walter/cims
You filed a GitHub issue on the docker repo about their infrastructure deployment.
They kindly (and correctly) pointed out the better way to resolve the issue and you insulted them.
Sorry you haven't heard a response to email. Hopefully that works in China too.
From a consumer perspective, if you can't docker pull then docker is ~useless, so being a key software feature within the docker binary it's not unrealistic to expect the average person to report directly to docker on github.
The fact we have to report fundamental issues that should never have passed basic testing in an extremely well funded company is the really amazing thing here.
Even if they wish to maintain a separate issue resolution process via email, a better resolution would be "I have forwarded this to the email support team, please expect an email" (since github IDs all have email associated anyway, this should be easy).
Right now they have ~maximum friction, and no response at all.
You will be pleased to note that email works fine in China (obviously - otherwise how do you think global trade operates?), unless you use NSA/Google as your provider.
It's not all that terrible to manage this yourself under light-to-medium usage, but if you're constantly experimenting with new machines and run into this more than once a week I'd say it's time to use docker remotely.