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 ow...@bugs.debian.org
immediately.)
--
500838: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500838
Debian Bug Tracking System
Contact ow...@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 ---
