devicemapper: Change default basesize to 100G #14709
Conversation
Current default basesize is 10G. Change it to 100G. Reason being that for some people 10G is turning out to be too small and we don't have capabilities to grow it dyamically. This is just overcommitting and no real space is allocated till container actually writes data. And this is no different then fs based graphdrivers where virtual size of a container root is unlimited. Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
|
I heard people complaining in the past about that 10G limitations, which I had no idea was on our end. I think it's a good thing to do yes: LGTM. |
|
LGTM |
devicemapper: Change default basesize to 100G
devicemapper: Change default basesize to 100G Docker-DCO-1.1-Signed-off-by: Brian Goff <cpuguy83@gmail.com> (github: rhatdan)
|
I guess going back to 10G (or possibly 20G) size is reasonable. And those who need bigger sizes will use dm.basesize=100G for now. Will be good to also provide capability to specify container size during creation. That way those who need bigger containers can specify per container size. Shishir has a working patch to specify per container size during create time. @shishir-a412ed can you please generate a PR with that patch. |
|
I wanted to put my comments in issue #18314 |
|
How cloud I assign the container mapper device size more than 10G? |
|
@rootsongjc Use dm.basesize=100G |
|
mark. 👍 |
|
I have a question regarding the resize. After changing the size to 20 GB in the configuration file and restarting docker daemon, I can see the default device size been changed using "docker info". However, after pulling image and re-running the container, the container size is still 10GB (default). Does anyone have an idea about this? |
|
@littleday I think you can try to use Overlay rather than device mapper, that have no container local storage limit. |
Fixes issue #14678
Current default basesize is 10G. Change it to 100G. Reason being that for
some people 10G is turning out to be too small and we don't have capabilities
to grow it dyamically.
This is just overcommitting and no real space is allocated till container
actually writes data. And this is no different then fs based graphdrivers
where virtual size of a container root is unlimited.
Signed-off-by: Vivek Goyal vgoyal@redhat.com