<div dir="ltr">After some additional testing, my issue appears related to <a href="http://thr3ads.net/ext3-users/2013/04/2300336-LONG-Delay-when-writing-to-ext4-LVM-after-boot">http://thr3ads.net/ext3-users/2013/04/2300336-LONG-Delay-when-writing-to-ext4-LVM-after-boot</a><div>
<br></div><div>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.</div>
<div><br></div><div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 August 2014 15:31, Tim Boundy <span dir="ltr"><<a href="mailto:gigaplex@gmail.com" target="_blank">gigaplex@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thanks, I'll give that a try and report back later.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 August 2014 15:21, NeilBrown <span dir="ltr"><<a href="mailto:neilb@suse.de" target="_blank">neilb@suse.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Sun, 24 Aug 2014 15:04:34 +1000 Tim Boundy <<a href="mailto:gigaplex@gmail.com" target="_blank">gigaplex@gmail.com</a>> wrote:<br>


<br>
> I've tried unmounting the file system, dropping caches via<br>
> /proc/sys/vm/drop_caches, then remounting the file system. I can't<br>
> reproduce the stalling issue on demand this way, I have to stop then<br>
> restart the array via mdadm to do so. Is there some caching of the mdadm<br>
> array itself going on that wasn't dropped when I unmounted the filesystem<br>
> and requested a cache drop? If not, then I'm not entirely convinced it's a<br>
> file system issue, but I'll ask for their input too.<br>
><br>
<br>
</div>There is some, but not much.<br>
<br>
If you write a small number to /sys/block/mdWATEVER/md/stripe_cache_size<br>
<br>
it will drop what little caching md does.  Then write the original number<br>
back in (256 by default).<br>
<br>
Another thing to try is to use "blktrace" on both the md device and the<br>
component device, then "blkparse" to look at the  result and see exactly<br>
what blocks are being read, and maybe who is reading them.<br>
<span><font color="#888888"><br>
NeilBrown<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>