On Thu, 20 Sep 2012 11:55:02 -0600 Chris Friesen [off-list ref]
wrote:
On 09/20/2012 10:52 AM, Chris Friesen wrote:
quoted
Hi,
I've got a fairly beefy (32 cpus, 64GB ram, isci-based SAS disks,
etc.) embedded system running 2.6.27.
We're seeing issues where disk operations suddenly seem to stall. In
the most recent case we had the hung-task watchdog indicate that
md1_resync was stuck for more than 120sec in raise_barrier().
There are a bunch of "normal" tasks also stuck in wait_barrier(), so
based on that I assume we're stuck in the second call to
wait_event_lock_irq().
Has anyone seen anything like this? Could commit 73d5c38 be related?
What about 1d9d524?
Could d6b42dc be related?
That last one seems more likely. Does the scenario fit your config.
i.e. is your RAID1 being used under LVM?
If it does, then I would say it is very likely this issue.
Also, what's the meaning of RESYNC_DEPTH?
The maximum number of resync requests that can be concurrently active.
RESYNC_WINDOW should really be RESYNC_BLOCK_SIZE * RESYNC_DEPTH
I wonder why it isn't.
NeilBrown