From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Giuseppe Scrivano <gscrivan@redhat.com>,
Miklos Szeredi <miklos@szeredi.hu>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [PATCH 2/2] Configure custom layers via environment variables
Date: Mon, 20 Apr 2020 15:14:53 -0400 [thread overview]
Message-ID: <20200420191453.GA21057@redhat.com> (raw)
In-Reply-To: <CAOQ4uxjvtGLn=SvLXy3KU6uKbonBUznL==OjdVVjjB6sM=-mgg@mail.gmail.com>
On Sat, Apr 18, 2020 at 12:57:27PM +0300, Amir Goldstein wrote:
> > > If I specify UNIONMOUNT_BASEDIR, then --samefs should be implied?
> > >
> >
> > This might have made sense with the meaning of UNIONMOUNT_BASEDIR
> > as it is in current posting, but with intended change, I suppose an empty
> > UNIONMOUNT_LOWERDIR could mean --samefs.
> > When both --samefs and UNIONMOUNT_LOWERDIR are specified, I'll
> > throw a warning that UNIONMOUNT_LOWERDIR is ignored.
> >
>
> Vivek,
>
> I updated the logic per some of your suggestions and push to:
> https://github.com/amir73il/unionmount-testsuite/commits/overlayfs-devel
> The example of how xfstests uses it is at:
> https://github.com/amir73il/xfstests/commits/unionmount
>
> Since I am mostly interested in feedback on config interface, I'll just
> paste the commit message here (same text is also in README).
>
> In short: if you set UNIONMOUNT_BASEDIR to virtiofs path and
> execute run --ov, all layers will be created under that virtiofs path.
This is nice. I tried following and it seems to work.
UNIONMOUNT_BASEDIR=/mnt/virtiofs/overlayfs-tests
UNIONMOUNT_MNTPOINT=/mnt/virtiofs/mnt
Got a question though. If somebody specifies a BASEDIR, whey not
automatically select mount point also inside that basedir. Is it because
of existing structure where basedir and mnt directory are separate and
defaults are different. Anway, I don't mind overlay mountpoint with
a separate environment variable.
>
> Let me know if this works for you.
> Thanks,
> Amir.
>
> commit 8c2ac6e0cd9d4b01e421375e0b9c3703e774cd9f
> Author: Amir Goldstein <amir73il@gmail.com>
> Date: Sun Apr 12 19:22:19 2020 +0300
>
> Configure custom layers via environment variables
>
> The following environment variables are supported:
>
> UNIONMOUNT_BASEDIR - parent dir of all samefs layers (default: /base)
> UNIONMOUNT_LOWERDIR - lower layer path for non samefs (default: /lower)
> UNIONMOUNT_MNTPOINT - mount point for executing tests (default: /mnt)
>
> When user provides paths for base/lower dir, they should point at
> existing directories and their content will be deleted.
> When the default base/lower paths are used, tmpfs instances are created.
>
> UNIONMOUNT_LOWERDIR is meaningless and will be ignored with --samefs.
> Empty UNIONMOUNT_LOWERDIR with non-empty UNIONMOUNT_BASEDIR imply --samefs,
What happens if I specify both UNIONMOUNT_LOWERDIR as well as
UNIONMOUNT_BASEDIR. Does that mean only upper and work will be setup in
UNIONMOUNT_BASEDIR.
> unless user explicitly requested non samefs setup with maxfs=<M>.
So if UNIONMOUNT_LOWERDIR is empty and I specify a UNIONMOUNT_BASEDIR and
use maxfs=<M>. All layers will still come from under UNIONMOUNT_BASEDIR,
right?
What's most intuitive to me is this.
- If user only specifies UNIONMOUNT_BASEDIR, all layers (lower, upper,
work and even mount point) comes from that directory.
- If user specifies both UNIONMOUNT_LOWERDIR and UNIONMOUNT_BASEDIR, then
lower layer path comes from UNIONMOUNT_LOWERDIR and rest of the layers
come from UNIONMOUNT_BASEDIR.
- If user specifies UNIONMOUNT_MNTPOINT, it is used as overlay mount
point. Otherwise one is selected from UNIONMOUNT_BASEDIR if user
specified one. Otherwise "/mnt" is the default.
Thanks
Vivek
>
> This is going to be used for running unionmount tests from xfstests.
>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
>
next prev parent reply other threads:[~2020-04-20 19:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 12:01 [PATCH 0/2] Prepare for running unionmount testssuite from Amir Goldstein
2020-04-15 12:01 ` [PATCH 1/2] Stop using bind mounts for --samefs Amir Goldstein
2020-04-15 12:01 ` [PATCH 2/2] Configure custom layers via environment variables Amir Goldstein
2020-04-15 15:30 ` Vivek Goyal
2020-04-15 16:27 ` Amir Goldstein
2020-04-15 19:42 ` Vivek Goyal
2020-04-16 7:10 ` Amir Goldstein
2020-04-16 12:58 ` Vivek Goyal
2020-04-16 13:49 ` Amir Goldstein
2020-04-18 9:57 ` Amir Goldstein
2020-04-20 19:14 ` Vivek Goyal [this message]
2020-04-21 5:57 ` Amir Goldstein
2020-05-17 8:45 ` Amir Goldstein
2020-05-22 14:36 ` Vivek Goyal
2020-05-22 17:19 ` Amir Goldstein
2020-05-24 10:28 ` Amir Goldstein
2020-05-26 12:54 ` 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=20200420191453.GA21057@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=gscrivan@redhat.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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).