[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Fedora 26 change: using overlayfs as default
- From: Josh Berkus <jberkus redhat com>
- To: Vivek Goyal <vgoyal redhat com>
- Cc: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] Fedora 26 change: using overlayfs as default
- Date: Fri, 6 Jan 2017 13:59:28 -0800
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]