All of lore.kernel.org
 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: Fri, 22 May 2020 10:36:06 -0400	[thread overview]
Message-ID: <20200522143606.GB58162@redhat.com> (raw)
In-Reply-To: <CAOQ4uxgVnT3ZXZZa4-YktZaRDpU1hHujPoEtZ2vdFmsGxj=66A@mail.gmail.com>

On Sun, May 17, 2020 at 11:45:59AM +0300, Amir Goldstein wrote:
> > >
> > > 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.
> >
> > OK.
> >
> > >
> > > - 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.
> >
> > DONE.
> >
> > >
> > > - 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.
> > >
> >
> > OK.
> >
> 
> Vivek,
> 
> I finally got around to implementing your suggestion (see [1]).
> 
> Quoting from README:
> 
>      When user provides UNIONMOUNT_LOWERDIR:
> 
>      1) Path should be an existing directory whose content will be deleted.
>      2) Path is assumed to be on a different filesystem than base dir, so
>         --samefs setup is not supported.
> 
>      When user provides UNIONMOUNT_BASEDIR:
> 
>      1) Path should be an existing directory whose content will be deleted.
>      2) If UNIONMOUNT_MNTPOINT is not provided, the overlay mount point will
>         be created under base dir.
>      3) If UNIONMOUNT_LOWERDIR is not provided, the lower layer dir will be
>         created under base dir.
>      4) If UNIONMOUNT_LOWERDIR is not provided, the test setup defaults to
>         --samefs (i.e. lower and upper are on the same base fs).  However,
>         if --maxfs=<M> is specified, a tmpfs instance will be created for
>         the lower layer dir.

Hi Amir,

Do you want to mention a word upper dir also when UNIONMOUNT_BASEDIR. That
is upperdir is also created under UNIONMOUNT_BASEDIR. IOW, all directories
lower, upper and mount point are under UNIONMOUNT_BASEDIR (until and
unless overridden by other environment variables).

For point 4, I understand that we will mount multiple instances of
tmpfs because maxfs tests on multiple different filessytems. I am
assuming that we will be creating lowerdir mount points under
UNIONMOUNT_BASEDIR for --maxfs.

I think this looks pretty good. Just one more thing. Is there a way to
specify multiple lowerdirs as well. If not, may be in future we can
add it once somebody needs to specify multiple lowerdirs.

Thanks
Vivek

> ----
> 
> I realize this last item (4) is a bit tricky.
> Let me know if you think it needs further clarification.
> 
> Thanks,
> Amir.
> 
> 
> [1] https://github.com/amir73il/unionmount-testsuite/commits/envvars
> 


  reply	other threads:[~2020-05-22 14:36 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
2020-04-21  5:57                   ` Amir Goldstein
2020-05-17  8:45                     ` Amir Goldstein
2020-05-22 14:36                       ` Vivek Goyal [this message]
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=20200522143606.GB58162@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.