From: Vivek Goyal <vgoyal@redhat.com>
To: "Ernst, Eric" <eric.ernst@intel.com>
Cc: "mszeredi@redhat.com" <mszeredi@redhat.com>,
"kata-dev@lists.katacontainers.io"
<kata-dev@lists.katacontainers.io>,
Stefan Hajnoczi <stefanha@redhat.com>,
Amir Goldstein <amir73il@gmail.com>,
linux-unionfs@vger.kernel.org
Subject: Re: Virtio-fs as upper layer for overlayfs
Date: Mon, 6 Jan 2020 13:35:00 -0500 [thread overview]
Message-ID: <20200106183500.GA14619@redhat.com> (raw)
In-Reply-To: <7904C889-F0AC-4473-8C02-887EF6593564@intel.com>
On Mon, Jan 06, 2020 at 05:27:05PM +0000, Ernst, Eric wrote:
[CC linux-unionfs@vger.kernel.org and amir]
> Hi Miklos,
>
> One of the popular use cases for Kata Containers is running docker-in-docker. That is, a container image is run which in turn will make use of a container runtime to do a container build.
>
> When combined with virtio-fs, we end up with a configuration like:
> xfs/ext4 -> overlayfs -> virtio-fs -> overlayfs
>
> As discussed in [1], per overlayfs spec:
> "The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable."
>
I don't know exaactly the reasons why NFS is not supported as upper. Are
above only two reasons? These might work with virtio-fs depending on
underlying filesystem. If yes, should we check for these properties
at mount time (instead of relying on dentry flags only,
ovl_dentry_remote()).
I feel there is more to it. Just that I don't know. Miklos and Amir
will probably have more thoughts on this.
Vivek
> At this point, with virtio-fs this, [2], check fails.
>
> Vivek mentioned that bypassing this check *may* be feasible, [3]. Can you help identify if this is feasible, and rationale for NFS not being available as an upper (though, more importantly, understanding what needs to be done to add proper support for virtio-fs as upper layer).
>
> Thanks,
> Eric
>
> [1] - https://github.com/kata-containers/runtime/issues/1888
> [2] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/overlayfs/super.c#n753
> [3] - https://github.com/kata-containers/runtime/issues/1888#issuecomment-518259095
>
next parent reply other threads:[~2020-01-06 18:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7904C889-F0AC-4473-8C02-887EF6593564@intel.com>
2020-01-06 18:35 ` Vivek Goyal [this message]
2020-01-06 19:58 ` Virtio-fs as upper layer for overlayfs Miklos Szeredi
2020-01-06 22:24 ` eric.ernst
2020-01-07 9:48 ` Miklos Szeredi
2020-01-07 13:37 ` Vivek Goyal
2020-01-07 16:09 ` Vivek Goyal
2020-01-13 19:56 ` Vivek Goyal
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=20200106183500.GA14619@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=eric.ernst@intel.com \
--cc=kata-dev@lists.katacontainers.io \
--cc=linux-unionfs@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=stefanha@redhat.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).