Chris, Thank you for your reply. Responses in-line.
On 2019-09-25T13:08:34, Chris Murphy wrote: > On Wed, Sep 25, 2019 at 8:50 AM Pallissard, Matthew <m...@pallissard.net> > wrote: > > > > Version: > > Kernel: 5.2.2-arch1-1-ARCH #1 SMP PREEMPT Sun Jul 21 19:18:34 UTC 2019 > > x86_64 GNU/Linux > > You need to upgrade to arch kernel 5.2.14 or newer (they backported the fix > first appearing in stable 5.2.15). Or you need to downgrade to 5.1 series. > https://lore.kernel.org/linux-btrfs/20190911145542.1125-1-fdman...@kernel.org/T/#u > > That's a nasty bug. I don't offhand see evidence that you've hit this bug. > But I'm not certain. So first thing should be to use a different kernel. Interesting, I'll go ahead with a kernel upgrade as that easy enough. However, that looks like it's related to a stacktrace regarding a hung process. Which is not the original problem I had. Based on the output in my previous email, I've been working under the assumption that there is a problem on-disk. Is that not correct? > Next, anytime there is a crash or powerfailur with Btrfs raid56, you need to > do a complete scrub of the volume. Obviously will take time but that's what > needs to be done first. I'm using raid 10, not 5 or 6. > OK actually, before the scrub you need to confirm that each drive's SCT ERC > time is *less* than the kernel's SCSI command timer. e.g. I gather that I should probably do this before any scrub, be it raid 5, 6, or 10. But, Is a scrub the operation I should attempt on this raid 10 array to repair the specific errors mentioned in my previous email? Thanks again. Matt Pallissard
signature.asc
Description: PGP signature
