On Thu, Nov 12, 2015 at 05:28:41PM -0500, Joshua Kinard wrote: > running MD RAID5 and the XFS filesystem. I have /, /home, /usr, /var, > and /tmp on separate partitions, each a RAID5 setup. Hi, sorry for butting in, I have the same issue, on a regular consumer Haswell i5 box, with a setup very very similar to yours: 7x2TB disks, multiple partitions, for each: RAID-5, LUKS, LVM, XFS. The issue occurs during regular RAID check which I run daily (different partition/RAID each day, so it's more like a evenly distributed weekly check). I have an application that uses `find -size +100M` on a directory tree with ~3k subdirs and ~6k files in total. It doesn't do anything with the find result, it's purely informal. So no big data involved, even though the files themselves aren't small. Yet, it's slooow. The following tests were on a completely idle box, apart from a running RAID check on the same /dev/mdX device. Kernel 4.2.3, unpatched: real 0m53.555s user 0m0.013s sys 0m0.037s real 1m3.777s user 0m0.013s sys 0m0.037s real 1m3.453s user 0m0.014s sys 0m0.036s Kernel 4.2.3, reverted ac8fa4196d20: real 0m3.206s user 0m0.010s sys 0m0.030s real 0m0.450s user 0m0.003s sys 0m0.014s real 0m0.375s user 0m0.003s sys 0m0.012s I did echo 3 > /proc/sys/vm/drop_caches between each find. For some reason, subsequent calls in the reverted kernel are considerably faster regardless. In the original kernel it stays slow... if I don't drop_caches, the time is 0.006s. I don't normally reboot (while a RAID sync or check is running) but while switching between kernels I noticed the shutdown was very slow also in the original kernel. Are small requests getting delayed a lot or something? Regards Andreas Klauer -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
