From: Dave Chinner <david@fromorbit.com>
To: Ed Peschko <horos22@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: handling device or resource busy errors.
Date: Thu, 10 Dec 2015 13:13:43 +1100 [thread overview]
Message-ID: <20151210021343.GI19802@dastard> (raw)
In-Reply-To: <CACQ+YcuwWv8g5zHk2sMfN_uRPGnW8Xb8WT6NGOLGigN2+0Toag@mail.gmail.com>
On Wed, Dec 09, 2015 at 04:25:06PM -0800, Ed Peschko wrote:
> All,
>
> we are 'getting device or resource busy' errors which we *know* are
> spurious (lsof shows nothing, no multipath daemon, the partition that we
> are trying to access was just created).
Please show your working - it saves us having to guess at how you
came to that conclusion.
> So the working theory is that the futex in question is spurious, that
> something didn't clean up after itself and we are stuck waiting for an
> non-existent process to fix it.
Sorry, what futex has anything to do with whether a block device can
be opened or not?
> And the force option doesn't work for some reason. So a couple of questions.
>
> 1. Why doesn't force work in this case? With parted and partx it does -
> in the case of mkfs.xfs it is a fatal error.
Because mkfs.xfs uses O_EXCL in it's open() call. If there are other
active references to the block device, then we sure aren't going to
overwrite anything on it.
> 2. could an 'extra force' option - one which ignored the futex - be
> added in cases of backwards compatibility?
What futex?
> 3. is there any way to list out what holds mutexes in the linux kernel
> so we could try to root out the ultimate cause of the issue? lsof is
> useless, as is dmesg and /var/log/messages.
sysrq-l
Does waiting a few seconds make the problem go away, what about
running 'udevadm settle' before mkfs?
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:[~2015-12-10 2:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 0:25 handling device or resource busy errors Ed Peschko
2015-12-10 2:05 ` Carlos E. R.
2015-12-10 2:18 ` Dave Chinner
2015-12-10 2:13 ` Dave Chinner [this message]
2015-12-10 7:58 ` Ed Peschko
2015-12-10 22:35 ` Dave Chinner
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=20151210021343.GI19802@dastard \
--to=david@fromorbit.com \
--cc=horos22@gmail.com \
--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.