From: Phil Turmel <philip@turmel.org>
To: Dark Penguin <darkpenguin@yandex.ru>, linux-raid@vger.kernel.org
Subject: Re: md failing mechanism
Date: Fri, 22 Jan 2016 14:29:13 -0500 [thread overview]
Message-ID: <56A28309.9080806@turmel.org> (raw)
In-Reply-To: <56A26E11.2090703@yandex.ru>
Hi,
On 01/22/2016 12:59 PM, Dark Penguin wrote:
> Greetings,
>
> Recently, I've had my first drive failure in a software RAID1 on a file
> server. And I was really surprised about exactly what happened; I always
> thought that when md can't process a read request from one of the
> drives, it is supposed to mark that drive as faulty and read from
> another drive; but, for some reason, it was deliberately trying to read
> from a faulty drive no matter what, which apparently caused Samba to
> wait until it's finished, and so the whole server was rendered
> inaccessible (I mean, the whole Samba).
What you've described does sound like a bug, maybe. It also sounds
similar to traditional timeout mismatch caused by cheap desktop drives
used in a raid array.
In a properly functioning array, the normal sequence of events for a
simple failing sector is:
1) read from sector X fails and is reported by the drive to the kernel
2) kernel tells MD "read failed"
3) MD reads from different mirror or from peers & parity to reconstruct
the failed sector
4a) MD supplies reconstructed sector to upper layer/user.
4b) MD writes reconstructed sector back to failed location to fix it or
relocate it. If this write succeeds (either case), the device stays in
the array.
The above sequence of events is disturbed when a drive takes too long in
step 1.
It would be good to see your dmesg of this event to see what failure
mode is present.
Meanwhile, some reading material for you:
http://marc.info/?l=linux-raid&m=139050322510249&w=2
http://marc.info/?l=linux-raid&m=135863964624202&w=2
http://marc.info/?l=linux-raid&m=135811522817345&w=1
http://marc.info/?l=linux-raid&m=133761065622164&w=2
http://marc.info/?l=linux-raid&m=132477199207506
http://marc.info/?l=linux-raid&m=133665797115876&w=2
http://marc.info/?l=linux-raid&m=142487508806844&w=3
http://marc.info/?l=linux-raid&m=144535576302583&w=2
next prev parent reply other threads:[~2016-01-22 19:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 17:59 md failing mechanism Dark Penguin
2016-01-22 19:29 ` Phil Turmel [this message]
2016-01-22 20:00 ` Wols Lists
2016-01-22 21:44 ` Dark Penguin
2016-01-22 22:18 ` Phil Turmel
2016-01-22 22:50 ` Dark Penguin
2016-01-22 23:23 ` Edward Kuns
2016-01-22 23:34 ` Wols Lists
2016-01-23 0:09 ` Dark Penguin
2016-01-22 22:37 ` Edward Kuns
2016-01-22 23:07 ` Dark Penguin
2016-01-22 23:39 ` Wols Lists
2016-01-23 0:09 ` Dark Penguin
2016-01-23 0:34 ` Phil Turmel
2016-01-23 10:33 ` Dark Penguin
2016-01-23 15:12 ` Phil Turmel
2016-01-22 23:40 ` James J
2016-01-23 0:44 ` Phil Turmel
2016-01-23 14:09 ` Wols Lists
2016-01-23 19:02 ` James J
2016-01-24 22:13 ` Adam Goryachev
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=56A28309.9080806@turmel.org \
--to=philip@turmel.org \
--cc=darkpenguin@yandex.ru \
--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).