From: Josef Bacik <jbacik@fusionio.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Josef Bacik <jbacik@fusionio.com>, <linux-btrfs@vger.kernel.org>,
<xfs@oss.sgi.com>
Subject: Re: [PATCH] xfstests: btrfs/003: stat the dev we're removing to make sure its' really gone
Date: Thu, 22 Aug 2013 14:19:18 -0400 [thread overview]
Message-ID: <20130822181918.GA29654@localhost.localdomain> (raw)
In-Reply-To: <5214EE7F.8090507@sandeen.net>
On Wed, Aug 21, 2013 at 11:44:47AM -0500, Eric Sandeen wrote:
> On 8/21/13 11:03 AM, Josef Bacik wrote:
> > I've been periodically failing btrfs/003 because my box sometimes takes a little
> > longer to unregister the device when we remove it and so the output from btrfs
> > dev show doesn't match what we are wanting since it still sees the device. To
> > fix this just stat and sleep if we still see the device node and only continue
> > once udev or whatever actually removes the device node so that we don't get
> > random failures. Thanks,
> >
> > Signed-off-by: Josef Bacik <jbacik@fusionio.com>
> > ---
> > tests/btrfs/003 | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/tests/btrfs/003 b/tests/btrfs/003
> > index 5c88651..dba1a32 100755
> > --- a/tests/btrfs/003
> > +++ b/tests/btrfs/003
> > @@ -145,6 +145,12 @@ _test_replace()
> > _devmgt_remove ${DEVHTL}
> > dev_removed=1
> >
>
> This should probably go into _devmgt_remove,
> and possibly the reverse in _devmgmt_add as well, with
> a comment explaining what it's doing?
>
> Otherwise someone else will run into the same problem down the line.
Ok so I went to do this and realized we only send the formatted thing to the
function, ie '0 0 0' for host/target/lun or whatever the numbers line up to. We
don't have the actual device node to check at this point, so it needs to be done
on a case by case basis. I looked at the other tests and all they want is the
device removed for kernel stuff, which happens immediately. We are the weird
ones checking to make sure btrfs fi show actually notices that we've removed the
device, so it's only really specific to this case and not something I can easily
add to the helper. Thanks,
Josef
prev parent reply other threads:[~2013-08-22 18:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 16:03 [PATCH] xfstests: btrfs/003: stat the dev we're removing to make sure its' really gone Josef Bacik
2013-08-21 16:44 ` Eric Sandeen
2013-08-21 17:31 ` Josef Bacik
2013-08-22 18:19 ` Josef Bacik [this message]
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=20130822181918.GA29654@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).