From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiong Zhou Subject: Re: [PATCH v3 0/9] fstests: new way to run overlay tests Date: Tue, 14 Feb 2017 17:25:11 +0800 Message-ID: <20170214092511.3b4i3c5i36o446lr@XZHOUW.usersys.redhat.com> References: <1486932224-17075-1-git-send-email-amir73il@gmail.com> <20170213041924.r5nho3xdkydzff6k@XZHOUW.usersys.redhat.com> <20170214044028.y45ai2dwzm7qx3k5@XZHOUW.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57340 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753031AbdBNJZM (ORCPT ); Tue, 14 Feb 2017 04:25:12 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-unionfs-owner@vger.kernel.org List-Id: linux-unionfs@vger.kernel.org To: Amir Goldstein Cc: Xiong Zhou , Eryu Guan , Miklos Szeredi , linux-unionfs@vger.kernel.org, fstests On Tue, Feb 14, 2017 at 08:15:22AM +0200, Amir Goldstein wrote: > On Tue, Feb 14, 2017 at 6:40 AM, Xiong Zhou 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 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. That's okay, i just need to know what I am testing for. With a "new way" to run tests, how I can control my test configuration with the config file, what every line in the config file means to the "new way". > > 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. Agree. It's fair enough to keep this "how the new way interprets old config file" in commit message. Ya.. finally i found that.. Still I think you can add more config examples in commit message or somewhere, for your saying: > >> 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. Then people can test your code with your examples. Ya, i'am lazy :) I guess -overlay option consider FSTYP as fs type for base fs. While with above config file FSTYP=xfs, if /dev/sda{5,6} are formated as ext4 fs before running, ./check -overlay generic/001 will test with base fs as ext4, (I don't get what i config for) ./check generic/001 will stop test "wrong fs type". Yes, it's human error. It's great if -overlay option can also stop test as general, to correct this error. Thanks for you time and Sorry for my bad questions. > 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.