Bump up 10GB size limit on container

[rickyzhang82]

In fedora and red hat, because of size limitation on image, I can't install large application larger than 10GB. I found an article about manually resizing container image. But I can't commit the resized container to image.

I have to bump up the hard code device mapper image size in source code. But I don't think it is a wise idea if this can't be adjusted in a dynamic way like lvm. It will be a headache in the long run.

Regarding to large size container and image, docker doesn't support very well or at least doesn't put much effort on that. Most of I/O operation goes through /tmp file system. In my case, /tmp is a half of the size of memory, so it won't work in all large image. Can this operation check /tmp file system size before proceeding? Or better, do a intelligent switch to any predefined physical disk when it is over the limit.

[unclejack]

#4202 will fix this problem.

[rickyzhang82]

That sounds great.

How about /tmp file system issues?

[unclejack]

@rickyzhang82 You can bind mount /tmp or any other directory you need from the host if you need greater performance. To bind mount a folder /storage/myapp1/tmp from the host to the container's /tmp, you can do something like: docker run -v /storage/myapp1/tmp:/tmp.

This should help you until #4202 gets merged. Does this help?

[rickyzhang82]

Regarding to image size, #4202 sounds like a solution. thanks!

[MoshiBin]

Requesting a reopen on this one, as #4202 has been declined (due to implementation).

[thaJeztah]

ping @rhvgoyal IIRC you looked into changing the size to 100G?

[unclejack]

We're not going to reopen this issue because this is already being tracked elsewhere:
#14678 - per container devicemapper size
#14709 - increase the default container basesize to 100 gigabytes

This issue will remain closed because #14709 has made this change and no further action is required. Please keep in mind that you'll have to set up devicemapper from scratch in order to use this new default.

[thaJeztah]

Thanks @unclejack #14709 was the one I meant, I didn't remember if it was merged or not :)