Re: handling device or resource busy errors.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs



[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux