Bug#759063: mdadm RAID5 array intermittently stalls during a write operation

NeilBrown neilb at suse.de
Mon Aug 25 08:02:44 UTC 2014


On Mon, 25 Aug 2014 17:28:52 +1000 Tim Boundy <gigaplex at gmail.com> wrote:

> After some additional testing, my issue appears related to
> http://thr3ads.net/ext3-users/2013/04/2300336-LONG-Delay-when-writing-to-ext4-LVM-after-boot
> 
> With clean restart of the array, followed by running dumpe2fs (presumably
> to prefetch bitmaps), the initial write delay is resolved. However I'm
> still confused as to why simply unmounting the filesystem, then flushing
> caches (echo 3 > /proc/sys/vm/drop_caches as well as changing the md
> stripe_cache_size) doesn't reproduce the issue. A full stop and reassemble
> cycle via mdadm is required to reproduce the issue.

That is a mystery.  Maybe the cache in the hard drives themselves is
providing the data...

> 
> One other point of note is that after a clean restart of the array and then
> running dumpe2fs, the only drive in the array that was read was /dev/sdd. I
> find it strange that all the relevant filesystem metadata would sit
> entirely on one drive in a multi drive array over a large range of LBAs.

That is not unexpected.  ext?fs tends to lay thing out in a way that ends up
aligning with stripes ... depending on the exact stripe size etc.

mke2fs has stride= and stripe_width= options to encourage it rotate the
bitmaps etc around the drives.

NeilBrown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20140825/ec5ab70a/attachment.sig>


More information about the pkg-mdadm-devel mailing list