From: Wols Lists <antlists@youngman.org.uk>
To: Daniel Sanabria <sanabria.d@gmail.com>,
Chris Murphy <lists@colorremedies.com>
Cc: Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Inactive arrays
Date: Wed, 14 Sep 2016 19:42:50 +0100 [thread overview]
Message-ID: <57D99A2A.8000006@youngman.org.uk> (raw)
In-Reply-To: <CAHscji2BKxNDLzZUonGHVB8PzeFbtuwn32NBaX315QPvvhOxyg@mail.gmail.com>
On 14/09/16 19:16, Daniel Sanabria wrote:
> Other than replacing the green drives with something more
> suitable (any suggestions are welcome)
WD Reds or Seagate NAS. I don't think they make them any more, but
Seagate Constellations are fine too. My Toshiba 2TB 2.5" laptop drive
would be fine.
The tl;dr version of the problem with Greens (and any other desktop
drive for that matter), if you haven't read it up yet, is that when the
kernel requests a read from a dodgy drive, it just sits there,
*unresponsive*, until the read succeeds or the drive times out. And the
drive will time out in its own good time.
If the kernel times out *before* the drive, and by default the kernel
does so after 7 secs, while the drive can take two minutes or more, then
the kernel will recreate the missing block and try to write it. The
drive is unresponsive, the write times out, and the kernel assumes the
drive is dead and kicks it from the array.
That's why you need to increase the kernel timeout, because you can't
reduce the drive timeout, and which is why a flaky hard drive will cause
system response to fall off horrendously.
Cheers,
Wol
next prev parent reply other threads:[~2016-09-14 18:42 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 7:36 Inactive arrays Daniel Sanabria
2016-08-02 10:17 ` Wols Lists
2016-08-02 10:45 ` Daniel Sanabria
2016-08-03 19:18 ` Daniel Sanabria
2016-08-03 21:31 ` Wols Lists
2016-09-11 18:48 ` Daniel Sanabria
2016-09-11 20:06 ` Daniel Sanabria
2016-09-12 19:41 ` Daniel Sanabria
2016-09-12 21:13 ` Daniel Sanabria
2016-09-12 21:37 ` Chris Murphy
2016-09-13 6:51 ` Daniel Sanabria
2016-09-13 15:04 ` Chris Murphy
2016-09-12 21:39 ` Wols Lists
2016-09-13 6:56 ` Daniel Sanabria
2016-09-13 7:02 ` Adam Goryachev
2016-09-13 15:20 ` Chris Murphy
2016-09-13 19:43 ` Daniel Sanabria
2016-09-13 19:52 ` Chris Murphy
2016-09-13 20:04 ` Daniel Sanabria
2016-09-13 20:13 ` Chris Murphy
2016-09-13 20:29 ` Daniel Sanabria
2016-09-13 20:36 ` Daniel Sanabria
2016-09-13 21:10 ` Chris Murphy
2016-09-13 21:46 ` Daniel Sanabria
2016-09-13 21:26 ` Wols Lists
2016-09-14 4:33 ` Chris Murphy
2016-09-14 10:36 ` Daniel Sanabria
2016-09-14 14:32 ` Chris Murphy
2016-09-14 14:57 ` Daniel Sanabria
2016-09-14 15:15 ` Chris Murphy
2016-09-14 15:47 ` Daniel Sanabria
2016-09-14 16:10 ` Chris Murphy
2016-09-14 16:13 ` Chris Murphy
2016-09-14 18:16 ` Daniel Sanabria
2016-09-14 18:37 ` Chris Murphy
2016-09-14 18:42 ` Wols Lists [this message]
2016-09-15 9:21 ` Brad Campbell
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=57D99A2A.8000006@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=sanabria.d@gmail.com \
/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.