public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Clark <michael@metaparadigm.com>
To: Brian Jackson <brian-kernel-list@mdrx.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: md on shared storage
Date: Wed, 13 Nov 2002 21:22:07 +0800	[thread overview]
Message-ID: <3DD251FF.6000007@metaparadigm.com> (raw)
In-Reply-To: 20021113031518.8700.qmail@escalade.vistahp.com

Basically my last setup was ext3 + LVM1 + qla2x00 (6.0.1b3).
This is exactly what is in 2.4.19pre10aa4. With general fileserver
load using netatalk on one machine, openldap on another machine
and oracle on another. One of them would oops every 5-8 days.

I haven't come up with a repeatable test yet to generate the oops.

I intend on trying fsx + bonnie in parallel on a test setup with same
kernels to see if I can reproduce the oops. Then i'll see if I can
reproduce with qla2300 6.01 driver. If still not okay, i'll try dm
and evms. Basically I want a stable ext3 + volume manager + qla2x00

~mc

On 11/13/02 11:15, Brian Jackson wrote:
> 
> I am testing OpenGFS on this hardware(it is on loan from OSDL), I could 
> probably do some testing for you if you have some specifics you want to 
> try. I am having trouble with the volume management portion of OpenGFS 
> also(but I don't necessarily think they are related).
> --Brian Jackson
> 
> <snip>
> 
>>
>> I'm interested in finding what magic is required to get a stable
>> setup with qlogic drivers and LVM. I have tested many kernel 
>> combinations,
>> vendor kernels, stock, -aa and variety of different qlogic drivers
>> inclusing the one with the alleged stack hog fixes and they all ooops
>> when using LVM (can take up to 10 days of production load). Removing
>> LVM 45 days ago and now I have 45 days uptime on these boxes.
>> I'm currently building a test setup to try and excercise this problem
>> as all my other boxes with qlogic cards are production and can't be
>> played with. I really miss having volume management and a SAN setup
>> is really where you need it the most.
>> ~mc


  reply	other threads:[~2002-11-13 13:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-13  0:25 md on shared storage Brian Jackson
2002-11-13  1:19 ` Steven Dake
2002-11-13  3:00   ` Michael Clark
2002-11-13  3:15     ` Brian Jackson
2002-11-13 13:22       ` Michael Clark [this message]
2002-11-13  2:51 ` Michael Clark
2002-11-13 11:46 ` Lars Marowsky-Bree
2002-11-13 17:17   ` Steven Dake
2002-11-13 17:25     ` Joel Becker
2002-11-13 17:56       ` Steven Dake
2002-11-13 17:24   ` Joel Becker
2002-11-13 15:35 ` Eric Weigle
2002-11-13 18:33   ` Brian Jackson
  -- strict thread matches above, loose matches on Subject: below --
2002-11-13 19:25 Eric Weigle

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=3DD251FF.6000007@metaparadigm.com \
    --to=michael@metaparadigm.com \
    --cc=brian-kernel-list@mdrx.com \
    --cc=linux-kernel@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