HN2new | past | comments | ask | show | jobs | submitlogin

We're using device-mapper thin provisioning technology. Same copy-on-write capabilities, but more compatible with upstream kernel versions


Cool. Are there any open issues where those of us who are interested can follow the details?

My main question is whether this will require users to create a fixed-size filesystem for each container up front, like you would have to do if you were using LVM snapshots directly.


Each container will have a "fixed-size filesystem", but:

- it will be thinly provisioned (i.e. it can be 10G or 100G but still use only a few MB on disk if it's essentially empty, like a sparse file), - it can be grown easily.

On the one hand, it's a bit less convenient because you have to care about the disk usage.

On the other hand, it's great because a single container can't eat up all your precious disk space (and if you want to run some public/semi-public stuff that's quasi mandatory).

If you want to check the current code, you can look here: https://github.com/alexlarsson/docker/tree/device-mapper3


No, the goal is for the current user experience to remain the same. By default docker will create a sparse file, loop-mount it, and use that for all containers. There is some magic in thin provisioning which allows for dynamically resizing when needed. We will add more details in the docs and mailing list in the coming weeks.

The best place to follow progress on this is to track docker-dev (https://groups.google.com/forum/#!forum/docker-dev) and the #docker-dev irc channel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: