<html><head></head><body><div dir="auto">Thank you. If the move I did didn't help, I'll add more drives, build another array, and move all of the extents to that new array, then remove the bad disks from the system. <br><br>Or, maybe I should just add more drives as hot spares, then take those other drives offline. No change to the mdadm shape at all.</div><br><br><div class="gmail_quote"><div dir="auto">On February 5, 2026 9:24:58 AM MST, Zak Smith <zak@computer.org> wrote:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><div dir="auto">Hi,<br><br>I had a situation, actually on a Unifi appliance, where the raid<br>performance was dropping enough to cause it to be unfit for purpose,<br>but not enough to cause system errors, or even log anything in dmesg.<br>I was able to identify the single disk that was causing problems<br>because "smartctl -a" would hang for 5-10 seconds when run on *that*<br>drive, even though the output itself did not (at that time) show any<br>indicators of failure.<br><br><br><br>On Thu, Feb 05, 2026 at 08:01:39AM -0700, Grant Johnson wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto"> Based on that idea, since it is LVM across 2 RAID 1 arrays, I moved one<br> of my large partitions that seems to be the most trouble from the array<br> that was getting very high waits according to iostat to the other one<br> that is having less io wait. We will see tonight if the daily<br> snapshots run any smoother not that I moved the bkup volume group to<br> the array with less trouble.<br><br> Maybe those disks are faster, maybe the freshening of the data will<br> help. Not sure, but good ideas from all of you sent me at least in a<br> new direction that I have not tried before.<br><br><br> On Tue, 2026-02-03 at 15:43 -0700, Bob Proulx wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><div dir="auto">Grant Johnson wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><div dir="auto">What else should I be checking?<br></div></blockquote><div dir="auto"><br> Sometimes reading data from drives will start to take longer when the<br> data on the drives is very static over years. In those cases the<br> data<br> might degrade where more error correction from the drive is needed to<br> read the data. And the drive might have to retry reading those disk<br> sectors more times to get a good read.<br><br> This can be "fluffed" by reading and writing the entire drive. I<br> have<br> seen some drives have dramatic improvement. I have seen other drives<br> have no change at all.<br><br> The most direct way is to boot a live boot image so that nothing is<br> touching the disk and then read and write the entire disk in place.<br><br> time dd if=/dev/sdX of=/dev/sdX bs=1M iflag=fullblock<br> oflag=sync,direct<br><br> Of course doing so can take a long time on a big drive. I like to<br> see<br> progress. The utility I like the best for this is "pv" pipe-viewer.<br> If you have a new enough utility then it will have the --direct-io<br> option. But if not then use dd.<br><br> time pv /dev/sdX | dd of=/dev/sdX bs=1M iflag=fullblock<br> oflag=sync,direct<br><br> The pv utility can even be used as the reader and writer itself when<br> using the --direct-io option. But no control of block size so dd is<br> still useful.<br><br> Since the data being written is the data being read this is safe but<br> only if nothing else is touching the drive at the same time.<br><br> Bob<br><br></div></blockquote></blockquote><div dir="auto"><br>--<br>Zak Smith<br>307-543-7820 office<br>Please do not send private or confidential information via email.<br><br><br><br><br></div></pre></blockquote></div></body></html>