From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Yongqiang Yang <xiaoqiangnk@gmail.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
xfs-oss <xfs@oss.sgi.com>
Subject: Re: xfstests: device busy when umount
Date: Wed, 18 May 2011 16:31:53 +1000 [thread overview]
Message-ID: <20110518063153.GZ19446@dastard> (raw)
In-Reply-To: <BANLkTi=pZS6sTjS61UmpbOsj+vF+ithVvw@mail.gmail.com>
On Tue, May 17, 2011 at 06:01:14PM +0300, Amir Goldstein wrote:
> On Tue, May 17, 2011 at 5:32 PM, Eric Sandeen <sandeen@redhat.com> wrote:
> > On 5/17/11 4:03 AM, Yongqiang Yang wrote:
> >> Hi,
> >>
> >> I noticed that all tests which contain 'device busy' errors have
> >> falloc operations. Does the error have something to do with falloc?
<shrug>
Perhaps a bit more detail about what you are testing, how you've set
up xfstests, etc, and some analysis of the problem is in order first?
> > cc'ing xfs list since xfs devs maintain xfstests.
> >
> > What tests have "device busy" errors? What do the usual investigative
> > steps such as "lsof" and "fuser" tell you when this happens?
>
> I tried running lsof | grep $TEST_DIR before umount
> and I tried sleep 1 before umount and it didn't yield anything.
Which usually indicates that you've got some kind of reference
counting problem preventing the filesystem from being unmounted.
> > Are there loop devices that didn't get cleaned up, or processes that
> > have not terminated?
> >
> > What tests have these problems?
>
> for me 124 always fails to umount, and 198 and 213 sometimes fails to umount.
What, exactly, are you testing on? test 124 uses XFS_IOC_RESVSP
directly, not fallocate(), so all it is doing on a non-XFS
filesystem is iterating a loop that writes a 1MB file, reads it back
then unlinks it....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
Yongqiang Yang <xiaoqiangnk@gmail.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: xfstests: device busy when umount
Date: Wed, 18 May 2011 16:31:53 +1000 [thread overview]
Message-ID: <20110518063153.GZ19446@dastard> (raw)
In-Reply-To: <BANLkTi=pZS6sTjS61UmpbOsj+vF+ithVvw@mail.gmail.com>
On Tue, May 17, 2011 at 06:01:14PM +0300, Amir Goldstein wrote:
> On Tue, May 17, 2011 at 5:32 PM, Eric Sandeen <sandeen@redhat.com> wrote:
> > On 5/17/11 4:03 AM, Yongqiang Yang wrote:
> >> Hi,
> >>
> >> I noticed that all tests which contain 'device busy' errors have
> >> falloc operations. Does the error have something to do with falloc?
<shrug>
Perhaps a bit more detail about what you are testing, how you've set
up xfstests, etc, and some analysis of the problem is in order first?
> > cc'ing xfs list since xfs devs maintain xfstests.
> >
> > What tests have "device busy" errors? What do the usual investigative
> > steps such as "lsof" and "fuser" tell you when this happens?
>
> I tried running lsof | grep $TEST_DIR before umount
> and I tried sleep 1 before umount and it didn't yield anything.
Which usually indicates that you've got some kind of reference
counting problem preventing the filesystem from being unmounted.
> > Are there loop devices that didn't get cleaned up, or processes that
> > have not terminated?
> >
> > What tests have these problems?
>
> for me 124 always fails to umount, and 198 and 213 sometimes fails to umount.
What, exactly, are you testing on? test 124 uses XFS_IOC_RESVSP
directly, not fallocate(), so all it is doing on a non-XFS
filesystem is iterating a loop that writes a 1MB file, reads it back
then unlinks it....
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:[~2011-05-18 6:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-17 9:03 xfstests: device busy when umount Yongqiang Yang
[not found] ` <BANLkTi=sFDKSB=fVOQs5s49E54T+V2iQJg@mail.gmail.com>
[not found] ` <BANLkTi=dqUakbFw_k=FzDO99=9T33RzUsA@mail.gmail.com>
2011-05-17 11:49 ` Amir Goldstein
2011-05-17 11:55 ` Yongqiang Yang
2011-05-17 14:32 ` Eric Sandeen
2011-05-17 14:32 ` Eric Sandeen
2011-05-17 15:01 ` Amir Goldstein
2011-05-17 15:01 ` Amir Goldstein
2011-05-18 6:31 ` Dave Chinner [this message]
2011-05-18 6:31 ` Dave Chinner
2011-05-18 8:19 ` Amir Goldstein
2011-05-18 8:19 ` Amir Goldstein
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=20110518063153.GZ19446@dastard \
--to=david@fromorbit.com \
--cc=amir73il@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=xfs@oss.sgi.com \
--cc=xiaoqiangnk@gmail.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.