From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: create a test for xfs log grant head leak detection
Date: Wed, 11 Jun 2014 06:56:03 -0400 [thread overview]
Message-ID: <20140611105603.GB39345@bfoster.bfoster> (raw)
In-Reply-To: <20140610233106.GJ9508@dastard>
On Wed, Jun 11, 2014 at 09:31:06AM +1000, Dave Chinner wrote:
> On Tue, Jun 10, 2014 at 07:17:50AM -0400, Brian Foster wrote:
> > On Tue, Jun 10, 2014 at 11:21:49AM +1000, Dave Chinner wrote:
> > > On Fri, Jun 06, 2014 at 09:14:43AM -0400, Brian Foster wrote:
> > > > +# real QA test starts here
> > > > +_supported_fs xfs
> > > > +_supported_os Linux
> > > > +
> > > > +_require_scratch
> > > > +_require_freeze
> > > > +
> > > > +if [ ! -e /sys/fs/xfs ]
> > > > +then
> > > > + _notrun "no kernel support for XFS sysfs attributes"
> > > > +fi
> > >
> > > _requires_xfs_sysfs
> > >
> >
> > I was mulling this over as I think we'll probably end up in a situation
> > where a test that depends on sysfs bits will need to check for a
> > specific attribute file. E.g., some new test comes along using a new
> > attribute file. Checking for /sys/fs/xfs is not sufficient for that test
> > once we release a version that so far only exports the log bits.
> >
> > I think we could handle that by supporting a parameter to
> > _requires_xfs_sysfs that specifies the sub-attribute that must exist
> > (similar to what we have for xfs_io commands). We don't need that at the
> > moment, but that's good enough for me to create the requires func.
>
> Yup, passing the name and/or sub-path of the paramter set required
> sounds fine to me. it would become:
>
> _requires_xfs_sysfs log
>
> in this case, because the presence of the /sys/fs/xfs/<dev>/log
> directory would be suficinet to indicate the test should run, yes?
>
Yep, that works. Should any new log attributes come along as a test
dependency, something like the following would be required:
_requires_xfs_sysfs log/logattr
So _requires_xfs_sysfs can basically just test for the existence of the
parameter under the xfs/<dev> path for TEST_DEV. I'll go with that.
Thanks.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: create a test for xfs log grant head leak detection
Date: Wed, 11 Jun 2014 06:56:03 -0400 [thread overview]
Message-ID: <20140611105603.GB39345@bfoster.bfoster> (raw)
In-Reply-To: <20140610233106.GJ9508@dastard>
On Wed, Jun 11, 2014 at 09:31:06AM +1000, Dave Chinner wrote:
> On Tue, Jun 10, 2014 at 07:17:50AM -0400, Brian Foster wrote:
> > On Tue, Jun 10, 2014 at 11:21:49AM +1000, Dave Chinner wrote:
> > > On Fri, Jun 06, 2014 at 09:14:43AM -0400, Brian Foster wrote:
> > > > +# real QA test starts here
> > > > +_supported_fs xfs
> > > > +_supported_os Linux
> > > > +
> > > > +_require_scratch
> > > > +_require_freeze
> > > > +
> > > > +if [ ! -e /sys/fs/xfs ]
> > > > +then
> > > > + _notrun "no kernel support for XFS sysfs attributes"
> > > > +fi
> > >
> > > _requires_xfs_sysfs
> > >
> >
> > I was mulling this over as I think we'll probably end up in a situation
> > where a test that depends on sysfs bits will need to check for a
> > specific attribute file. E.g., some new test comes along using a new
> > attribute file. Checking for /sys/fs/xfs is not sufficient for that test
> > once we release a version that so far only exports the log bits.
> >
> > I think we could handle that by supporting a parameter to
> > _requires_xfs_sysfs that specifies the sub-attribute that must exist
> > (similar to what we have for xfs_io commands). We don't need that at the
> > moment, but that's good enough for me to create the requires func.
>
> Yup, passing the name and/or sub-path of the paramter set required
> sounds fine to me. it would become:
>
> _requires_xfs_sysfs log
>
> in this case, because the presence of the /sys/fs/xfs/<dev>/log
> directory would be suficinet to indicate the test should run, yes?
>
Yep, that works. Should any new log attributes come along as a test
dependency, something like the following would be required:
_requires_xfs_sysfs log/logattr
So _requires_xfs_sysfs can basically just test for the existence of the
parameter under the xfs/<dev> path for TEST_DEV. I'll go with that.
Thanks.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-11 10:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 13:14 [PATCH] xfstests: create a test for xfs log grant head leak detection Brian Foster
2014-06-06 13:14 ` Brian Foster
2014-06-10 1:21 ` Dave Chinner
2014-06-10 1:21 ` Dave Chinner
2014-06-10 11:17 ` Brian Foster
2014-06-10 11:17 ` Brian Foster
2014-06-10 23:31 ` Dave Chinner
2014-06-10 23:31 ` Dave Chinner
2014-06-11 10:56 ` Brian Foster [this message]
2014-06-11 10:56 ` Brian Foster
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=20140611105603.GB39345@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=fstests@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.