On Mon, 25 Aug 2014 17:28:52 +1000 Tim Boundy <gigap...@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
signature.asc
Description: PGP signature
