
Disk space usage leak in Docker for Mac - ingve
https://github.com/docker/for-mac/issues/371
======
manacit
I am not sure that this belongs on the front page of HN, but the problem seems
to stem from the `virtio-blk` driver they're using not supporting TRIM, which
causes space to never deallocate once the VM writes to a block.

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.

~~~
djs55
(I'm a Docker employee working on this very issue. I guess my plan to take a
break by reading HN failed!)

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.

~~~
Cafey
Keep in mind the Apple file system is going to change early 2017! (APFS)

~~~
winkywooster
It's going to be a long time before it's widely deployed.

~~~
djs55
I'm looking forward to trying APFS, particularly support for sparse files. But
you're right, it'll take while before we can rely on it.

------
AaronFriel
Everything old is new again. I posted a Docker issue about the default storage
driver (DeviceMapper) not correctly freeing unused space nearly three years
ago:
[https://github.com/docker/docker/issues/3182](https://github.com/docker/docker/issues/3182)

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.

~~~
jsiepkes
Same here. I've also bumped into various storage issues with docker. Really
drove me mad a couple of times... And like parent stated, the Docker docs
about these issues reminded me of the XFS faq. Which stated about data loss
for unclean shutdown (powerloss, panic): "If you know it hurts don't do it".
In the end docker is just not as robust as for example SmartOS / Triton with
ZFS.

------
dawnerd
I've given up with Docker on mac. It's a complete joke that they even consider
it out of beta. The windows version is faster but doesn't handle file change
events yet (or something like that). I just said screw it and switched my dev
machine over to Ubuntu.

~~~
contingencies
Agreed. Forget usage leaks, Docker for Mac _doesn 't even work_ on my system,
and five days later after reporting it, nobody cares. It used to work, many
versions ago, but they've somehow broken it entirely between redesigning the
UI 2-3 times and switching from VirtualBox (which worked) to OSX
Virtualization (which so far doesn't). See [https://github.com/docker/for-
mac/issues/984](https://github.com/docker/for-mac/issues/984)

In addition, they don't seem to care that the whole thing is useless in China
-
[https://github.com/docker/docker/issues/28791](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](http://stani.sh/walter/cims)

~~~
paulddraper
> they don't seem to care that the whole thing is useless in China

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.

~~~
contingencies
Realistically, how they choose to divide their issue resolution is irrelevant
except in terms of how much friction it causes with users and developers.

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.

------
PopsiclePete
Docker for mac was the most blatantly not-ready-for-primetime piece of
software I've installed on my mac the past 10 years.

------
Steeeve
I suppose this is better than when the disk usage wouldn't grow at all.

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.

------
seaghost
I've gave up from Docker for Mac the first time I've tried it.

------
joesmo
Docker for Mac has issues that make it unusable? You don't say!

