From: Roman Mamedov <rm@romanrm.net>
To: "David C. Rankin" <drankinatty@suddenlinkmail.com>
Cc: mdraid <linux-raid@vger.kernel.org>
Subject: Re: Linux 5.5 Breaks Raid1 on Device instead of Partition, Unusable I/O
Date: Mon, 2 Mar 2020 11:51:41 +0500 [thread overview]
Message-ID: <20200302115141.1e796b7c@natsu> (raw)
In-Reply-To: <920df583-1d9e-6037-1d61-cbd5e1133d4d@suddenlinkmail.com>
On Mon, 2 Mar 2020 00:38:16 -0600
"David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
> On 03/01/2020 11:25 PM, Roman Mamedov wrote:
> > On Sun, 1 Mar 2020 19:50:03 -0600
> > "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
> >
> >> Let me know if there is anything else I can send, and let me know if I
> >> should stop the scrub or just let it run. I'm happy to run any diagnostic you
> >> can think of that might help. Thanks.
> >
> > It doesn't seem convincing that the issue is raw devices vs partitions, or
> > even kernel version related, especially since you rolled it back and the issue
> > remains.
> >
> > What else you could send is "smartctl -a" of all devices;
> >
> > and most importantly, while the "slow" scrub is running on md4, start:
> >
> > iostat -x 2 /dev/sdc /dev/sdd
> >
> > (enlarge the terminal window) and see if any of the 2 devices is pegged into
> > 100.0 in the last "%util" column, or just showing much higher values there
> > than the other one.
> >
>
> Thank you Roman, iostat and smartctl -a for sdc/sdd attached,
>
> sdc has a few errors from a power hit taken 3000 hours ago or so, but since
> that time it has been fine. I had rolled back to several earlier kernels from
> Jan 14, Jan 21, and Jan 27 with no change, I then updated to current which is
> Archlinux 5.5.6-arch1-1.
These show not just a few errors, but that it is basically dying:
5 Reallocated_Sector_Ct 0x0033 089 089 010 Pre-fail Always 13648
197 Current_Pending_Sector 0x0012 085 085 000 Old_age Always 2544
198 Offline_Uncorrectable 0x0010 085 085 000 Old_age Offline 2544
> I'm not sure what to make of the iostat output, but the r_await looks
> suspicious. Could this all be due to one flaky disk without it throwing any
> errors?
Yes, replace the drive ASAP, and see if that solves it.
--
With respect,
Roman
next prev parent reply other threads:[~2020-03-02 6:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-02 1:50 Linux 5.5 Breaks Raid1 on Device instead of Partition, Unusable I/O David C. Rankin
2020-03-02 5:25 ` Roman Mamedov
2020-03-02 6:38 ` David C. Rankin
2020-03-02 6:46 ` David C. Rankin
2020-03-02 6:51 ` Roman Mamedov [this message]
2020-03-02 6:57 ` David C. Rankin
2020-03-02 7:08 ` Chris Murphy
2020-03-02 9:27 ` David C. Rankin
2020-03-02 11:44 ` Phil Turmel
2020-03-02 13:32 ` Wols Lists
2020-03-02 21:21 ` David C. Rankin
2020-03-02 21:09 ` Chris Murphy
2020-03-04 22:53 ` David C. Rankin
2020-03-05 17:18 ` Wols Lists
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200302115141.1e796b7c@natsu \
--to=rm@romanrm.net \
--cc=drankinatty@suddenlinkmail.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).