From: Eric Sandeen <sandeen@redhat.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: xfs@oss.sgi.com, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, dchinner@redhat.com
Subject: Re: [PATCH] xfstests: add disk failure simulation test
Date: Thu, 14 Feb 2013 09:15:46 -0600 [thread overview]
Message-ID: <511CFFA2.8030905@redhat.com> (raw)
In-Reply-To: <87621vngtw.fsf@openvz.org>
On 2/14/13 7:52 AM, Dmitry Monakhov wrote:
> On Wed, 13 Feb 2013 10:28:35 -0600, Eric Sandeen <sandeen@redhat.com> wrote:
>> On 2/13/13 9:41 AM, Dmitry Monakhov wrote:
<snip>
>>> +# get standard environment, filters and checks
>>> +. ./common.rc
>>> +. ./common.filter
>>> +
>>> +# TODO move it to common.blkdev if necessery
>>
>> maybe a comment as to why you do this? (presumably to find the right thing in /sys)
>> I hope this always works with all udev schemes etc?
> I just ment to say that functions below are good candidates to became
> common wrappers.
Sure, but what is the reason for the wrapper?
On inspection I think its' because you need the right sysfs name; it'd
just be nice to say that it's the reason for the readlink/basename
frobbing of the existing $SCRATCH_DEV. Not a huge deal.
>>> +SCRATCH_REAL_DEV=`readlink -f $SCRATCH_DEV`
>>> +SCRATCH_BDEV=`basename $SCRATCH_REAL_DEV`
>>> +
<snip>
>>> +_require_debugfs()
>>> +{
>>> + #boot_params always present in debugfs
>>> + [ -d "$DEBUGFS_MNT/boot_params" ] || _notrun "Debugfs not mounted"
>>> +}
>>
>> Would it make more sense to look for debugfs in /proc/filesystems
>> as a test for it being *available* (as opposed to mounted somewhere?)
>>
>> I wonder if a helper (maybe in _require_debugfs) should work out if
>> it's mounted, if not, try to mount it, and in the end, export DEBUGFS_MNT
>> for any test that wants to use it.
>>
>> Otherwise if it happens to be mounted elsewhere, this'll all fail.
>> Just a thought. Maybe that's unusual enough that there's no point.
>> But getting it mounted if it's not would be helpful I think.
Any thoughts on this? As it stands it requires debugfs to be
at /sys/kernel/debug (by default) *and* mounted prior to the test run.
So it's another (maybe unexpected) piece of pre-test setup which might
result in this test not getting run.
-Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@redhat.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
dchinner@redhat.com, xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: add disk failure simulation test
Date: Thu, 14 Feb 2013 09:15:46 -0600 [thread overview]
Message-ID: <511CFFA2.8030905@redhat.com> (raw)
In-Reply-To: <87621vngtw.fsf@openvz.org>
On 2/14/13 7:52 AM, Dmitry Monakhov wrote:
> On Wed, 13 Feb 2013 10:28:35 -0600, Eric Sandeen <sandeen@redhat.com> wrote:
>> On 2/13/13 9:41 AM, Dmitry Monakhov wrote:
<snip>
>>> +# get standard environment, filters and checks
>>> +. ./common.rc
>>> +. ./common.filter
>>> +
>>> +# TODO move it to common.blkdev if necessery
>>
>> maybe a comment as to why you do this? (presumably to find the right thing in /sys)
>> I hope this always works with all udev schemes etc?
> I just ment to say that functions below are good candidates to became
> common wrappers.
Sure, but what is the reason for the wrapper?
On inspection I think its' because you need the right sysfs name; it'd
just be nice to say that it's the reason for the readlink/basename
frobbing of the existing $SCRATCH_DEV. Not a huge deal.
>>> +SCRATCH_REAL_DEV=`readlink -f $SCRATCH_DEV`
>>> +SCRATCH_BDEV=`basename $SCRATCH_REAL_DEV`
>>> +
<snip>
>>> +_require_debugfs()
>>> +{
>>> + #boot_params always present in debugfs
>>> + [ -d "$DEBUGFS_MNT/boot_params" ] || _notrun "Debugfs not mounted"
>>> +}
>>
>> Would it make more sense to look for debugfs in /proc/filesystems
>> as a test for it being *available* (as opposed to mounted somewhere?)
>>
>> I wonder if a helper (maybe in _require_debugfs) should work out if
>> it's mounted, if not, try to mount it, and in the end, export DEBUGFS_MNT
>> for any test that wants to use it.
>>
>> Otherwise if it happens to be mounted elsewhere, this'll all fail.
>> Just a thought. Maybe that's unusual enough that there's no point.
>> But getting it mounted if it's not would be helpful I think.
Any thoughts on this? As it stands it requires debugfs to be
at /sys/kernel/debug (by default) *and* mounted prior to the test run.
So it's another (maybe unexpected) piece of pre-test setup which might
result in this test not getting run.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-14 15:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 15:41 [PATCH] xfstests: add disk failure simulation test Dmitry Monakhov
2013-02-13 16:28 ` Eric Sandeen
2013-02-14 13:52 ` Dmitry Monakhov
2013-02-14 15:15 ` Eric Sandeen [this message]
2013-02-14 15:15 ` Eric Sandeen
2013-02-19 11:14 ` Dmitry Monakhov
2013-02-19 11:14 ` Dmitry Monakhov
2013-02-13 21:32 ` Dave Chinner
2013-02-13 21:32 ` Dave Chinner
2013-02-22 3:27 ` Greg Freemyer
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=511CFFA2.8030905@redhat.com \
--to=sandeen@redhat.com \
--cc=dchinner@redhat.com \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@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.