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

Bug#500838: marked as done (linux-image-2.6.24-etchnhalf.1-686-bigmem: MD raid5 array with XFS filesystem hangs (deadlock) after a while under heavy use)

Your message dated Sat, 28 Apr 2012 01:48:13 -0500
with message-id <20120428064813.GA19485@burratino>
and subject line Re: [etchnhalf] MD raid5 array with XFS filesystem hangs (deadlock) after a while under heavy use
has caused the Debian Bug report #500838,
regarding linux-image-2.6.24-etchnhalf.1-686-bigmem: MD raid5 array with XFS filesystem hangs (deadlock) after a while under heavy use
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
500838: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500838
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-2.6.24-etchnhalf.1-686-bigmem
Version: 2.6.24-6~etchnhalf.5
Severity: important

File operations hang after a while on a raid5 MD array with XFS filesystem on it. XFS may be irrelevant. Default parameters were used, so /sys/block/md*/md/stripe_cache_size was not changed.
No error messages appear in dmesg or elsewhere, so a deadlock is suspected.

A patch exists: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/broken-out/md-fix-an-occasional-deadlock-in-raid5.patch.
The patch seems to appear (slightly modified) in the 2.6.26 (testing) kernel.
The patch, or the version that appears in 2.6.26 is reported to solve the problem (I can not yet confirm).

Increasing /sys/block/md*/md/stripe_cache_size to 4096 or 8192 is also reported to solve the problem (I can not yet confirm).

The stable 2.6.18 kernel is not affected, though raid5 speed benefits from increasing /sys/block/md*/md/stripe_cache_size (confirmed).

I use lenny/testing with a stable kernel.

-- Package-specific info:

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-etchnhalf.1-686-bigmem (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.24-etchnhalf.1-686-bigmem depends on:
ii  debconf [debconf-2.0]         1.5.22     Debian configuration management sy
ii  initramfs-tools [linux-initra 0.92j      tools for generating an initramfs
ii  module-init-tools             3.4-1      tools for managing Linux kernel mo

Versions of packages linux-image-2.6.24-etchnhalf.1-686-bigmem recommends:
ii  libc6-i686                    2.7-13     GNU C Library: Shared libraries [i

-- debconf information excluded

--- End Message ---
--- Begin Message --- 
Version: 2.6.25-1

Hi Laslo,

Laszlo Kajan wrote:

> File operations hang after a while on a raid5 MD array with XFS
> filesystem on it. XFS may be irrelevant. Default parameters were
> used, so /sys/block/md*/md/stripe_cache_size was not changed.
> No error messages appear in dmesg or elsewhere, so a deadlock is
> suspected.
>
> A patch exists:
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/broken-out/md-fix-an-occasional-deadlock-in-raid5.patch.
> The patch seems to appear (slightly modified) in the 2.6.26 (testing) kernel.
> The patch, or the version that appears in 2.6.26 is reported to
> solve the problem (I can not yet confirm).

The patch mentioned above is v2.6.25-rc1~542 (md: fix an occasional
deadlock in raid5, 2008-02-06).  Therefore closing, but confirmation
either way about the fix would be welcome.

Thanks for a pleasant report, and sorry we lost track of this.

Sincerely,
Jonathan

--- End Message ---
Reply to: