From: Dark Penguin <darkpenguin@yandex.ru>
To: Phil Turmel <philip@turmel.org>, linux-raid@vger.kernel.org
Subject: Re: md failing mechanism
Date: Sat, 23 Jan 2016 01:50:11 +0300 [thread overview]
Message-ID: <56A2B223.7060804@yandex.ru> (raw)
In-Reply-To: <56A2AAB1.6070305@turmel.org>
>> C) Suffer with desktop drives without SCTERC support. They cannot be
>> set to appropriate error timeouts. Udev or boot script assistance is
>> needed to set a 120 second driver timeout in sysfs. They do *not* work
>> properly with MD out of the box.
> the recommended timeout for 'C' has drifted upward to 180.
Yes, I saw this; but, is it really not possible to examine the default
timeout in a certain desktop drive, rather than follow rough estimates
like "about two of three minutes should be enough"?.. I wanted to make
sure it is indeed not possible, because that is hard to believe. Or do
they not have a specified timeout at all?..
> Since that was written, 'A' would now include almost-enterprise drives
> with RAID ratings like the Western Digital Red family.
Yes, I understand that; always make sure they support it.
>> Still, I don't think it has anything to do with what has happened to my
>> "small file server"...
>
> That's why I asked for the dmesg. It could have been a bug. No crisis
> if it's lost, so long as you've accepted one of A through D above.
I've moved all the data to another server, disassembled this one, and
reused the surviving hard drive, so I'm safe, but sadly, no logs. The
important thing is, I've confirmed that this is not the expected
behaviour - I was kind of ready to hear that "that's how it is with
softraids, faulty drives hang your entire system like they hang Windows".
I've checked all my hard drives in all my RAIDs; all of them support
"TL;DR" technology. They were all made before the "crippling" tendencies
took over, and they are mostly Hitachi, so I'm lucky.
--
darkpenguin
next prev parent reply other threads:[~2016-01-22 22:50 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
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 [this message]
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=56A2B223.7060804@yandex.ru \
--to=darkpenguin@yandex.ru \
--cc=linux-raid@vger.kernel.org \
--cc=philip@turmel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.