($INBOX_DIR/description missing)
 help / color / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Vivek Goyal <vgoyal@redhat.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 20:19:19 +0300
Message-ID: <CAOQ4uxj8Qhw-r8E+Fb-YYnMwmApkCPXD1136CA=oNo-81rzdVQ@mail.gmail.com> (raw)
In-Reply-To: <20200522143606.GB58162@redhat.com>

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

Sure. I will add:

2) Upper layer and middle layers will be created under base dir

> 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


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

You mean a way to specify different paths/fs to lower dirs?
It doesn't make much sense in the test.
The test rotates the upper layer 0 to be middle dir 0 and creates
upper dir 1. Most of the tests never rotate upper.

Currently, the most complex configuration you can run tests with
is rotating layers that end up with:
- Lowermost layer on user configurable lowerfs (*)
- Mid layers 0..M-1 on unique tmpfs instanced
- Layers M..N on same user configurable basefs.

(*) there is also the --squashfs option which formats the readonly
lowerfs with the test files.

Would you like a way to define a user configurable path
for upper dir 0? something else?

Which real life use case is this supposed to be simulating anyway?
for me this looks too much for no good reason.
If anyone comes forward with a reason and patches we can
consider that.


  reply index

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
2020-05-22 17:19                         ` Amir Goldstein [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOQ4uxj8Qhw-r8E+Fb-YYnMwmApkCPXD1136CA=oNo-81rzdVQ@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=gscrivan@redhat.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=vgoyal@redhat.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

($INBOX_DIR/description missing)

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-unionfs/0 linux-unionfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-unionfs linux-unionfs/ https://lore.kernel.org/linux-unionfs \
	public-inbox-index linux-unionfs

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git