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