All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Xiong Zhou <xzhou@redhat.com>
Cc: Eryu Guan <eguan@redhat.com>, Miklos Szeredi <miklos@szeredi.hu>,
	linux-unionfs@vger.kernel.org, fstests <fstests@vger.kernel.org>
Subject: Re: [PATCH v3 0/9] fstests: new way to run overlay tests
Date: Tue, 14 Feb 2017 08:15:22 +0200	[thread overview]
Message-ID: <CAOQ4uxgjNe86U5FZ-MZCrSve7M47iMsJDax6FYBkyO4+JK-iig@mail.gmail.com> (raw)
In-Reply-To: <20170214044028.y45ai2dwzm7qx3k5@XZHOUW.usersys.redhat.com>

On Tue, Feb 14, 2017 at 6:40 AM, Xiong Zhou <xzhou@redhat.com> wrote:
> On Mon, Feb 13, 2017 at 07:37:45AM +0200, Amir Goldstein wrote:
>> On Mon, Feb 13, 2017 at 6:19 AM, Xiong Zhou <xzhou@redhat.com> wrote:
>> > On Sun, Feb 12, 2017 at 10:43:35PM +0200, Amir Goldstein wrote:
>> >> Hi Eryu and all,
>> >>
>> >> The reason I started this work was to help catch overlayfs bugs
>> >> related to leaking objects in underlying (base) fs.
>> >
>> > So firstly, what's wrong with the existing way exactly ?
>> >
>>
>> One of the reasons that xfstests cycle mounts scratch partition
>> is that some bugs, such as object leaking bugs, are only discovered
>> when trying to unmount the file system.
>>
>> With overlayfs tests the cycling of overlay mount can detect bugs
>> related to overlayfs objects leaking, but not to base fs objects leaking.
>> OTOH, some bugs may be triggered in base fs when used under
>> overlayfs, but not when tests are run directly over the fs.
>>
>> The solution is to cycle mount both overlay mount and the base fs
>> underneath it to detect all those bugs.
>
> Good job.
>
>>
>> I started off (in V1) with a more complex way to manually configure
>> OVL_BASE_TEST_DEV, OVL_BASE_TEST_DIR, etc, but that
>> became very cumbersome.
>>
>> Eryu pointed out the over complication of this configuration, so
>> I decided to re-think the "old way", which I always thought was
>> a bit hackish.
>>
>> The "new way" enables running overlay tests over a range of
>> base fs configurations, which was not possible before without
>> using external scripts to wrap xfstests.
>>
>> But above all, the "new way" represents a different perspective
>> of overlayfs testing - testing overlayfs independently of the
>> underlying fs is doing half the job.
>>
>> You may say that overlayfs is closer to "MOUNT_OPTIONS"
>> then it is to "FSTYP". The truth is somewhere in the middle,
>> but the fact is that running a single "overlay" test does not cut it.
>> To tests overlay thoroughly, one would need to test overlay over
>> xfs, ext4, btrfs and to test xfs thoroughly, one would need to test
>> xfs, xfs+reflink, xfs+overlay, xfs+reflink+overlay, etc.
>>
>> The new way provides an easy way to configure those tests,
>> using semantics that people are used to when testing multiple
>> flavors of configurations.
>
> I'd like more comments or document for these NEW configurations, other
> than one or two lines in Examples.
>
> In other words, what kind of configuration your patches bringing
> support to ?
>

There are 2 parts for this answer:

1. Single section config file
====================

The answer here is there is no new configuration.
All you need to do is forget everything you knew about old overlay test config.

Take an existing test configuration you have and already use:
     TEST_DEV=/dev/sda5
     TEST_DIR=/mnt/test
     SCRATCH_DEV=/dev/sda6
     SCRATCH_MNT=/mnt/scratch
     FSTYP=xfs

and just run './check -overlay' whenever you want to test overlayfs
and './check' whenever you want to test native fs.

I could add more and more examples to README, but it's not like
README tells you much about how to use other configurations.
IMO, these 3 lines sums it up well:

        - for overlay tests: ./check -overlay [test(s)]
          The TEST and SCRATCH partitions should be pre-formatted
          with another base fs, where the overlay dirs will be created

2. Multi section config file
===================

Honestly, I never intended to make it work and there are many combinations
of sections that do not work today and some that will not work with overlay
(see email from Ted about patch 9/9)

I just realized that it may be useful to some and added the example howto
add overlay sections post non-overlay section, but I do not intend to fix
problems with this sort of setup, so I might as well remove the example
and leave this an undocumented feature for people who understand
how multi section works.

  reply	other threads:[~2017-02-14  6:15 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-12 20:43 [PATCH v3 0/9] fstests: new way to run overlay tests Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 1/9] fstests: sanity check that test partitions are not mounted elsewhere Amir Goldstein
2017-02-13 11:10   ` Eryu Guan
2017-02-13 11:44     ` Amir Goldstein
2017-02-13 13:33       ` Amir Goldstein
2017-02-14  5:51         ` Eryu Guan
2017-02-14  6:02           ` Amir Goldstein
2017-02-14  7:23             ` Eryu Guan
2017-02-14  8:05               ` Amir Goldstein
2017-02-16  8:53           ` Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 2/9] fstests: use _test_mount() consistently Amir Goldstein
2017-02-13 11:17   ` Eryu Guan
2017-02-12 20:43 ` [PATCH v3 3/9] fstests: canonicalize mount points on every config section Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 4/9] overlay: rename OVERLAY_LOWER/UPPER/WORK_DIR Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 5/9] overlay: allow SCRATCH_DEV to be the base fs mount point Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 6/9] overlay: configure TEST/SCRATCH vars to base fs Amir Goldstein
2017-02-13 11:28   ` Eryu Guan
2017-02-13 20:31     ` Amir Goldstein
2017-02-14 11:03       ` Eryu Guan
2017-02-15 14:59         ` Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 7/9] overlay: use OVL_BASE_SCRATCH_MNT instead of SCRATCH_DEV Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 8/9] overlay: fix test and scratch filters for overlay base fs Amir Goldstein
2017-02-13 20:39   ` Amir Goldstein
2017-02-12 20:43 ` [PATCH v3 9/9] overlay: mount/unmount base fs before/after running tests Amir Goldstein
2017-02-13 11:31   ` Eryu Guan
2017-02-13 11:59     ` Amir Goldstein
2017-02-14  0:23   ` Theodore Ts'o
2017-02-14  5:24     ` Eryu Guan
2017-02-14  6:43     ` Amir Goldstein
2017-02-14 17:07       ` Theodore Ts'o
2017-02-14 17:55         ` Amir Goldstein
2017-02-16  8:50           ` Amir Goldstein
2017-02-12 20:51 ` [PATCH v3 0/9] fstests: new way to run overlay tests Amir Goldstein
2017-02-13  4:19 ` Xiong Zhou
2017-02-13  5:37   ` Amir Goldstein
2017-02-14  4:40     ` Xiong Zhou
2017-02-14  6:15       ` Amir Goldstein [this message]
2017-02-14  9:25         ` Xiong Zhou
2017-02-14  9:51           ` Amir Goldstein
2017-02-13 11:02 ` Eryu Guan
2017-02-16  9:02   ` Amir Goldstein

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=CAOQ4uxgjNe86U5FZ-MZCrSve7M47iMsJDax6FYBkyO4+JK-iig@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=xzhou@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 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.