From: Eric Sandeen <sandeen@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs mailing list <xfs@oss.sgi.com>,
ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] xfstests: enable many tests to run on ext2/3/4
Date: Sun, 24 May 2009 11:38:02 -0500 [thread overview]
Message-ID: <4A1977EA.3000604@redhat.com> (raw)
In-Reply-To: <20090524143945.GA32554@infradead.org>
Christoph Hellwig wrote:
> Wow, that's a nice start. The only important thing missing is checking
> the filesystems after each test run for the non-xfs case.
Yep, that was in the back of my mind. Probably needs more abstraction
to make that cleaner.
> Maybe we should put this in in stages? The _supported_fs generic
> thing is a nice cleanup already for the existing xfs/nfs/udf setup
> and should go in ASAP.
sure, I can break it up.
> The _scratch_mkfs output fix in 069 could also be a separate patch.
>
> The _setup_generic_testdir should be generalized to match XFS for the
> default case and just set testdir in _setup_testdir instead of
> another function. Also the comment there should be updated.
>
> Same for _cleanup_testdir.
>
> Btw, the way udf and nfs are currently handled look not very nice to me.
> We should not set up the test device by default for any filesystem but
> rather have a -setup or similar option to set it up if needed.
many of them likely fail, too, some of the acl & attr tests have some
assumptions about xfs limits.
> In common I would indeed prefer a new fstype option, but we might aswell
> put the current version in as-is. Especially if we could tie up a really
> generic fstype= that wouldn't require listing the filesystems if they
> don't require special mount options or similar.
Ok. I'd even thought that maybe by default, w/o options, it should just
run as whatever $TEST_DEV is formatted to (though that's trickier for
nfs I guess)
> The only thing preventing that is as far as I can see the current difference
> in _require_scratch for xfs and udf vs the rest. Which looks really weird
> to me, need to investigate what's going on.
I think this is because even for udf etc, it still expects $TEST_DIR to
be xfs, so swizzles around test & scratch. yeah, I agree that's messy.
> As for the generic group I must say I don't like it very much, the
> filtering of notrun (maybe only notrun because of the filesystem type
> mismatch) sounds much better to me.
yeah, after I ran it a bit more I think I tend to agree....
I'll work on breaking this up a bit and tidying up some of the loose
ends, since the basic approach seems sane to more than one person now :)
Thanks,
-Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
xfs mailing list <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfstests: enable many tests to run on ext2/3/4
Date: Sun, 24 May 2009 11:38:02 -0500 [thread overview]
Message-ID: <4A1977EA.3000604@redhat.com> (raw)
In-Reply-To: <20090524143945.GA32554@infradead.org>
Christoph Hellwig wrote:
> Wow, that's a nice start. The only important thing missing is checking
> the filesystems after each test run for the non-xfs case.
Yep, that was in the back of my mind. Probably needs more abstraction
to make that cleaner.
> Maybe we should put this in in stages? The _supported_fs generic
> thing is a nice cleanup already for the existing xfs/nfs/udf setup
> and should go in ASAP.
sure, I can break it up.
> The _scratch_mkfs output fix in 069 could also be a separate patch.
>
> The _setup_generic_testdir should be generalized to match XFS for the
> default case and just set testdir in _setup_testdir instead of
> another function. Also the comment there should be updated.
>
> Same for _cleanup_testdir.
>
> Btw, the way udf and nfs are currently handled look not very nice to me.
> We should not set up the test device by default for any filesystem but
> rather have a -setup or similar option to set it up if needed.
many of them likely fail, too, some of the acl & attr tests have some
assumptions about xfs limits.
> In common I would indeed prefer a new fstype option, but we might aswell
> put the current version in as-is. Especially if we could tie up a really
> generic fstype= that wouldn't require listing the filesystems if they
> don't require special mount options or similar.
Ok. I'd even thought that maybe by default, w/o options, it should just
run as whatever $TEST_DEV is formatted to (though that's trickier for
nfs I guess)
> The only thing preventing that is as far as I can see the current difference
> in _require_scratch for xfs and udf vs the rest. Which looks really weird
> to me, need to investigate what's going on.
I think this is because even for udf etc, it still expects $TEST_DIR to
be xfs, so swizzles around test & scratch. yeah, I agree that's messy.
> As for the generic group I must say I don't like it very much, the
> filtering of notrun (maybe only notrun because of the filesystem type
> mismatch) sounds much better to me.
yeah, after I ran it a bit more I think I tend to agree....
I'll work on breaking this up a bit and tidying up some of the loose
ends, since the basic approach seems sane to more than one person now :)
Thanks,
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-05-24 16:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 20:15 [PATCH] xfstests: enable many tests to run on ext2/3/4 Eric Sandeen
2009-05-21 20:15 ` Eric Sandeen
2009-05-24 14:39 ` Christoph Hellwig
2009-05-24 14:39 ` Christoph Hellwig
2009-05-24 16:38 ` Eric Sandeen [this message]
2009-05-24 16:38 ` Eric Sandeen
2009-05-25 15:31 ` Eric Sandeen
2009-05-25 15:31 ` Eric Sandeen
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=4A1977EA.3000604@redhat.com \
--to=sandeen@redhat.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=xfs@oss.sgi.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.