All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 02 Nov 2007 13:21:27 -0500	[thread overview]
Message-ID: <1194027687.11827.32.camel@w100> (raw)
In-Reply-To: <1194018326.25553.28.camel@firewall.xsintricity.com>

On Fri, 2007-11-02 at 11:45 -0400, Doug Ledford wrote:

> The key word here being "supported".  That means if you run across a
> problem, we fix it.  It doesn't mean there will never be any problems.

On hardware specs I normally read "supported" as "tested within that
OS version to work within specs". I may be expecting too much.

> I'm sorry, but given the "specially the RHEL" case you cited, it is
> clear I can't help you.  No one can.  You were running first gen
> software on first gen hardware.  You show me *any* software company
> who's first gen software never has to be updated to fix bugs, and I'll
> show you a software company that went out of business they day after
> they released their software.

I only pointed to RHEL as an example since that was a particular
distro that I use and exhibited the problem. I probably could of
replaced it with Suse, Ubuntu, etc. I may have called the early
versions back in 94 first gen but not today's versions. I know I 
didn't expect the SLS distro to work reliably back then. 

Thanks for reminding me on what I should and shouldn't consider 
first gen. I guess I should always wait for a couple of updates
prior to considering a distro stable, I'll keep that in mind in 
the future.

> I *really* can't help you.

And I never expected you to. None of my posts asked for support
to get my specific hardware and kernels working. I did ask for
help identifying combinations that work and those that don't.

The thread on low level timeouts within MD was meant as a forward
thinking question to see if it could solve some of these problems.
It has been settled that no, so that's that. I am really not trying
to push the issue with MD timeouts.

> No, your experience, as you listed it, is that
> SATA/usb-storage/Serverworks PATA failed you.  The software raid never
> failed to perform as designed.

And I never said that software raid did anything outside what it
was designed to do. I did state that when the goal is to keep the
server from hanging (a reasonable goal if you ask me) the combination
of SATA/usb-storage/Serverworks PATA with software raid is not
a working solution (neither it is without software raid for that
matter)

> However, one of the things you are doing here is drawing sweeping
> generalizations that are totally invalid.  You are saying your
> experience is that SATA doesn't work, but you aren't qualifying it with
> the key factor: SATA doesn't work in what kernel version?  It is
> pointless to try and establish whether or not something like SATA works
> in a global, all kernel inclusive fashion because the answer to the
> question varies depending on the kernel version.  And the same is true
> of pretty much every driver you can name.  This is why commercial

At time of purchase the hardware vendor (Supermicro for those
interested) listed RHLE v3, which is what got installed.

> companies don't just certify hardware, but the software version that
> actually works as opposed to all versions.  In truth, you have *no idea*
> if SATA works today, because you haven't tried.  As David pointed out,
> there was a significant overhaul of the SATA error recovery that took
> place *after* the kernel versions that failed you which totally
> invalidates your experiences and requires retesting of the later
> software to see if it performs differently.

I completely agree that retesting is needed based on the improvements
stated. I don't think it invalidates my experiences though, it does
date them, but that's fine. And yes, I see your point on always listing
specific kernel versions I will do better with the details in the
future.

> I've had *lots* of success with software RAID as I've been running it
> for years.  I've had old PATA drives fail, SCSI drives fail, FC drives
> fail, and I've had SATA drives that got kicked from the array due to
> read errors but not out and out drive failures.  But I keep at least
> reasonably up to date with my kernels.
> 
Can you provide specific chipsets that you used (specially for SATA)? 

Thanks,

Alberto



  reply	other threads:[~2007-11-02 18:21 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 [this message]
2007-11-02 19:15                   ` Doug Ledford
2007-11-02 21:24                     ` Alberto Alonso
2007-10-27 21:46   ` Alberto Alonso
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=1194027687.11827.32.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 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.