On Mon, Mar 2, 2020 at 2:27 AM David C. Rankin <drankinatty@xxxxxxxxxxxxxxxxxx> wrote: > > On 03/02/2020 01:08 AM, Chris Murphy wrote: > > smart also reports for /de/sdc > > > > 40 53 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 > > > > > > So I'm suspicious of timeout mismatch as well. > > https://raid.wiki.kernel.org/index.php/Timeout_Mismatch > > > > > > Chris Murphy > > > > The strace between the virtualbox host and guess show and number of I/O waits > that would seem to fit some timeout issue like that. But according to the > page, both drives in this array provide: > > SCT capabilities: (0x1085) SCT Status supported. > Check the value 'smartctl -l scterc /dev/' Change the value 'smartctl -l scterc,70,70 /dev/' Of course no change needed if it's a value already below sysfs timeout value for each block device. Note that SCT ERC times are deciseconds. This is on the host. > Which should be able to handle the correction without stumbling into the > timeout problem. Something is FUBAR. On a Archlinux guest running on that > array, At a text console when you type your user name and press [Enter], the > login may timeout before the password: prompt is ever displayed. So this is > really giving virtualbox fits. Weird, I'm not sure what's causing that kind of latency in a vbox guest. > > On the host itself, you don't really notice much, other than a bit of slowdown > with readline and tab-completion every once in a while, but apps looking to > that array -- all bets are off. > > And still not a single error in the journal or mailed from mdadm. You would > think if it was going to take 26 days to scrub a 3T array, some error should > pop up somewhere :-) Yes. At the least the default SCSI command timer should spit back a hard link reset, both in the journal and to the device. I don't think mdadm will report that. -- Chris Murphy
