That's what I meant -- you have to completely tear down all /var/lib/docker in order for the size change to take effect. You would have to then pull down all your images, basically starting from scratch. Quite a price to pay; so that's why we're bumping the default to 100G (btw, 10G was an arbitrary, nice round number chosen when the devicemapper driver was first implemented).
But the real thing to keep in mind here is that you should be putting your persistent data onto a volume, when you go to production (as Matt also mentioned). Hope that makes sense. On Thu, Aug 6, 2015 at 12:44 PM, Carl Mosca <[email protected]> wrote: > I have read that bumping the size has no effect on the 10GB images. > > When I tried it, I saw no change in new containers > > On Aug 6, 2015 11:34 AM, "Jeremy Eder" <[email protected]> wrote: >> >> Unfortunately, not at this time. We have some PRs out there to make >> it configurable. Short term, we've bumped the default devicemapper >> container size from 10G to 100G (will show up in a future release). >> >> For now, you can adjust the --storage-opt dm.basesize=XYZG value >> passed to the docker daemon via /etc/sysconfig/docker-storage. The >> downside of that is it requires users to tear down their docker >> storage and re-create it, in order to apply the new dm.basesize value. >> >> On Wed, Aug 5, 2015 at 11:19 PM, Carl Mosca <[email protected]> wrote: >> > Is it possible to resize a container's filesystem? >> > >> > TIA, >> > Carl >> > >> > -- >> > Carl J. Mosca >> >> >> >> -- >> >> -- Jeremy Eder -- -- Jeremy Eder
