On 01/06/2017 01:48 PM, Vivek Goyal wrote: > On Fri, Jan 06, 2017 at 01:38:09PM -0800, Josh Berkus wrote: >> On 01/06/2017 11:24 AM, Vivek Goyal wrote: >>> On Thu, Jan 05, 2017 at 04:16:45PM -0800, Josh Berkus wrote: >>>> So, I've done some testing, thanks to Dusty's setup. >>>> >>>> I wasn't able to test on Kubernetes because of some setup issues. >>>> However, I hammered away at Docker using some IO-intensive applications, >>>> including PostgreSQL and Etcd, both of which write data frequently to >>>> some unexpected places. >>>> >>>> So far I haven't seen any unexpected IO errors from containers running >>>> under overlayfs. >>>> >>>> And having all of storage be one big volume is really nice; it >>>> eliminates a longstanding issue we've had with disk allocation; the >>>> whole disk is simply available. >>>> >>>> So +1 on moving to overlayfs for F26. >>> >>> Nice to hear that Josh. BTW, on fedora server and atomic, overlay storage >>> will still come from non-root fs partition. That will allow one to switch >>> back to devicemapper if overlay2 does not work for them. >> >> Why? It didn't when I just ran the test. Why can't we have a shared >> partition? > > We can have depending on what's the default configuration of storage. So > for atomic-host, rootfs was 3G by default and rest of the space was free > which used to be used by devicemapper. > > I think you are talking of some other image where default rootfs > configuration looks different. If rootfs is consuming all space available > on disk by default, then shared partition makes perfect sense. > > So whether to have shared partition by default or setup a separate logical > volume to store images/containers depends on default storage setup of > image.
Takign this discussion to the Paguire issue: https://pagure.io/atomic-wg/issue/186 -- -- Josh Berkus Project Atomic Red Hat OSAS
