linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>
> 


  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).