From: Vivek Goyal <firstname.lastname@example.org> To: Christian Brauner <email@example.com> Cc: Amir Goldstein <firstname.lastname@example.org>, Stephane Graber <email@example.com>, firstname.lastname@example.org, Miklos Szeredi <email@example.com>, Netdev <firstname.lastname@example.org>, overlayfs <email@example.com>, firstname.lastname@example.org, LSM List <email@example.com>, firstname.lastname@example.org, linux-fsdevel <email@example.com>, "zhangyi (F)" <firstname.lastname@example.org> Subject: Re: Overlayfs @ Containers and checkpoint/restart micro-conference at LPC2018 Date: Tue, 11 Sep 2018 09:52:59 -0400 [thread overview] Message-ID: <20180911135259.GB27845@redhat.com> (raw) In-Reply-To: <email@example.com> On Sun, Sep 09, 2018 at 11:18:54AM +0200, Christian Brauner wrote: [..] > My team hast just started to be more involved with shifts development a > few months back. Overlayfs is definitely an inspiration and we even once > thought about making shifts an extension of overlayfs. > Seth Forshee on my team is currently actively working on shifts and > getting a POC ready. > When he has a POC based on James' patchset there will be an RFC that > will go to fsdevel and all parties of interest. > There will also be an update on shifts development during the microconf. > So even more reason for developers from overlayfs to stop by. So we need both shiftfs and overlayfs in container deployments, right? shiftfs to make sure each container can run in its own user namespace and uid/gid mappings can be setup on the fly and overlayfs to provide union of multiple layers and copy on write filesystem. I am assuming that shiftfs is working on top of overlayfs here? Doing shifting at VFS level using mount API was another idea discussed at last plumbers. I saw David Howells was pushing all the new mount API patches. Not sure if he ever got time to pursue shifting at VFS level. BTW, now we have metadata only copy up patches in overlayfs as well(4.19-rc). That speeds up chown operation with overlayfs, needed for changing ownership of files in images for making sure they work fine with user namespaces. In my simple testing in a VM, a fedora image was taking around 30 seconds to chown. With metadata only copy up that time drops to around 2-3 seconds. So till shiftfs or shiting at VFS level gets merged, it can be used as a stop gap solution. Thanks Vivek
next prev parent reply other threads:[~2018-09-11 13:52 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-13 16:10 Stéphane Graber 2018-09-08 4:59 ` Stéphane Graber 2018-09-08 7:41 ` Amir Goldstein 2018-09-09 1:31 ` Christian Brauner 2018-09-09 6:31 ` Overlayfs @ " Amir Goldstein 2018-09-09 9:18 ` Christian Brauner 2018-09-11 13:52 ` Vivek Goyal [this message] 2018-09-11 15:13 ` James Bottomley 2018-09-11 15:36 ` Vivek Goyal 2018-09-09 19:08 ` [lxc-users] " Lucas Oketch 2018-09-09 15:30 ` James Bottomley 2018-09-09 17:38 ` Steve French
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180911135259.GB27845@redhat.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Overlayfs @ Containers and checkpoint/restart micro-conference at LPC2018' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).