xfs
[Top] [All Lists]

Re: [PATCH] xfstests: Add pairing mount options test

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH] xfstests: Add pairing mount options test
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 13 Jan 2014 12:52:39 +1100
Cc: Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Eric Sandeen <sandeen@xxxxxxxxxx>, linux-btrfs <linux-btrfs@xxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52D342F0.5020402@xxxxxxxxxxx>
References: <1389162648-19309-1-git-send-email-quwenruo@xxxxxxxxxxxxxx> <52D01CA9.4040107@xxxxxxxxxxx> <52D33F92.2000609@xxxxxxxxxxxxxx> <52D342F0.5020402@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, Jan 12, 2014 at 07:35:44PM -0600, Eric Sandeen wrote:
> On 1/12/14, 7:21 PM, Qu Wenruo wrote:
> > On fri, 10 Jan 2014 10:15:37 -0600, Eric Sandeen wrote:
> >> On 1/8/14, 12:30 AM, Qu Wenruo wrote:
> >>> Test remount btrfs with different pairing options like barrier and no 
> >>> barrier.
> >> It seems that while this tests that the remount succeeds, and that
> >> the option string is present in /proc/mounts, it does not test that
> >> the mount option is actually in effect.
> > 
> > Yes, this is what the new test case is intended to do.
> > This case was just a test case tests the mount options themselves
> > to ensure all the pairing mount options works during remounting,
> > since most pairing options are missing before.
> >>
> >> I suppose for many of these options that would be hard to test; for
> >> i.e. acl though it should be trivial.
> >>
> >> What do you think, is this enough to ensure that remount handling
> >> is working as expected for all of these options?
> > In my opinion, this test should just focuses on the remount handling and
> > the pairing options.
> > For the detailed function should be examineed in other test cases.
> 
> Except those won't test that a remount with those options actually *worked*;
> in fact they don't do remount at all.
> 
> In other words, all this does is test that an option flag was set or unset in
> the superblock, but it doesn't really test whether the option has been
> properly set up (or torn down) as a result.
> 
> I won't say no to this, but it seems to be of somewhat limited use.

What happens to the test when mount options are deprecated/removed?
How are we going to handle the matrix of testable/untestable mount
options across kernels with different mount option support?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>