From: Alberto Alonso <alberto@ggsys.net>
To: Doug Ledford <dledford@redhat.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Implementing low level timeouts within MD
Date: Sat, 27 Oct 2007 16:46:01 -0500 [thread overview]
Message-ID: <1193521561.7690.14.camel@w100> (raw)
In-Reply-To: <1193425254.10336.290.camel@firewall.xsintricity.com>
On Fri, 2007-10-26 at 15:00 -0400, Doug Ledford wrote:
>
> This isn't an md problem, this is a low level disk driver problem. Yell
> at the author of the disk driver in question. If that driver doesn't
> time things out and return errors up the stack in a reasonable time,
> then it's broken. Md should not, and realistically can not, take the
> place of a properly written low level driver.
>
I am not arguing whether or not MD is at fault, I know it isn't.
Regardless of the fact that it is not MD's fault, it does make
software raid an invalid choice when combined with those drivers. A
single disk failure within a RAID5 array bringing a file server down
is not a valid option under most situations.
I wasn't even asking as to whether or not it should, I was asking if
it could. Should is a relative term, could is not. If the MD code
can not cope with poorly written drivers then a list of valid drivers
and cards would be nice to have (that's why I posted my ... when it
works and when it doesn't, I was trying to come up with such a list).
I only got 1 answer with brand specific information to figure out when
it works and when it doesn't work. My recent experience is that too
many drivers seem to have the problem so software raid is no longer
an option for any new systems that I build, and as time and money
permits I'll be switching to hardware/firmware raid all my legacy
servers.
Thanks,
Alberto
next prev parent reply other threads:[~2007-10-27 21:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 17:12 Implementing low level timeouts within MD Alberto Alonso
2007-10-26 19:00 ` Doug Ledford
2007-10-27 10:33 ` Samuel Tardieu
2007-10-30 5:19 ` Alberto Alonso
2007-10-30 17:39 ` Doug Ledford
2007-11-01 5:08 ` Alberto Alonso
2007-11-01 14:14 ` Bill Davidsen
2007-11-01 19:16 ` Doug Ledford
2007-11-02 8:41 ` Alberto Alonso
2007-11-02 11:09 ` David Greaves
2007-11-02 17:47 ` Alberto Alonso
2007-11-02 12:44 ` Bill Davidsen
2007-11-02 15:45 ` Doug Ledford
2007-11-02 18:21 ` Alberto Alonso
2007-11-02 19:15 ` Doug Ledford
2007-11-02 21:24 ` Alberto Alonso
2007-10-27 21:46 ` Alberto Alonso [this message]
2007-10-27 23:55 ` Doug Ledford
2007-10-28 6:27 ` Alberto Alonso
2007-10-29 17:22 ` Doug Ledford
2007-10-30 5:08 ` Alberto Alonso
2007-10-30 12:12 ` Gabor Gombas
2007-10-30 17:58 ` Doug Ledford
2007-11-01 14:19 ` Bill Davidsen
2007-11-07 8:47 ` Goswin von Brederlow
2007-10-27 18:59 ` Richard Scobie
[not found] ` <1193522726.7690.31.camel@w100>
2007-10-27 23:46 ` Richard Scobie
2007-10-30 4:47 ` Neil Brown
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=1193521561.7690.14.camel@w100 \
--to=alberto@ggsys.net \
--cc=dledford@redhat.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).