linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Benedict Singer <bzsing@dolby.com>
Cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org
Subject: Re: xfs/md filesystem hang on drive pull under IO with 2.6.35.13
Date: Wed, 18 Jul 2012 07:47:05 +1000	[thread overview]
Message-ID: <20120718074705.6a5521a6@notabene.brown> (raw)
In-Reply-To: <5005D661.8030200@dolby.com>

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

On Tue, 17 Jul 2012 14:17:21 -0700 Benedict Singer <bzsing@dolby.com> wrote:

> Hi XFS and MD experts,
> 
> I'm experiencing a problem with a setup running XFS on top of an MD 
> raid. The test I'm running is physically pulling a drive while the 
> system is running, to simulate hardware failure. When the system is 
> idle, this works fine; the md subsystem detects the missing drive and 
> degrades the arrays, and everything keeps running fine. If I pull a 
> drive while heavy IO activity (mostly if not completely reading) is 
> happening on the XFS filesystem, then very often the filesystem seems to 
> "hang" - both processes that were accessing the filesystem at the time 
> hang, as well as any new ones like 'ls'. Luckily, the kernel noticed the 
> hung processes and spit a bunch of useful information to syslog. The 
> relevant snippets are reproduced below, including the messages 
> indicating that the drive was pulled, along with other XFS/MD raid 
> information from the system. The filesystem in question is on 
> /dev/md126, mounted on /var/showstore, and the disk pulled was /dev/sda. 
> Note that at the time this information was collected, the disk had been 
> re-inserted and a rebuild was proceeding.
> 
> Is this a bug (seems like a race condition leading to a deadlock?), 
> and/or is there something to change in the way the system is set up to 
> mitigate or workaround this?

Looks a lot like a bug in md.  It is waiting for the metadata to be marked
'dirty', and is waiting forever. 

2.6.35 is a very old kernel.  It is entirely possible that the bug has been
fixed.
If you can reproduce with something newer I'd certainly be interested.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-07-17 21:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-17 21:17 xfs/md filesystem hang on drive pull under IO with 2.6.35.13 Benedict Singer
2012-07-17 21:47 ` NeilBrown [this message]
2012-07-17 22:04 ` Emmanuel Florac

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=20120718074705.6a5521a6@notabene.brown \
    --to=neilb@suse.de \
    --cc=bzsing@dolby.com \
    --cc=linux-raid@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 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).