public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: kwijibo@zianet.com
To: "Robert L. Harris" <Robert.L.Harris@rdlg.net>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Slowing down disk access?
Date: Fri, 28 Feb 2003 11:03:52 -0700	[thread overview]
Message-ID: <3E5FA488.2080208@zianet.com> (raw)
In-Reply-To: <20030228143528.GA2432@rdlg.net>

I have nearly an identical system as yours. Dual 1.6 Athlons,
two 3ware 7850's, 8 disks on each but with 160 gig drives.
I have kernel 2.4.19 on it with ext3.  My RAID is arranged
slightly different however.  I have each controller do a RAID 5
and then I software mirror the two.  This box gets hammered
pretty hard at times over NFS and other services but I have
never seen this type of behaviour come out of it.  Are you
sure one of your drives isn't going bad, it looks the error
is always coming from unit #7.  Do all of them do this?

Steve

Robert L. Harris wrote:

>  I've got a system I need to slow down disk access on it would seem.  The
>syerver, a dual 1.5Ghz Athalon has two 3ware IDE controllers, 8 disks
>each for a total of sixteen 180 Gig disks.  This system is laid out in
>four RAID5 arrays that it shares out via NFS.  kernel 2.4.19-ac4, ext3
>file systems.  I've got 7 of these.
>
>  This works great and provides a LOT of cheap disk that we use for
>staging backups before cloning off to tape.
>
>  The problem is that when the array's get pounded HARD, such as when
>legato is cleaning it's file devices (nsrstage -C) the machine will lock
>up and spew errors to my console:
>
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: Command failed: status = 0xc7, flags = 0x1b, unit #7.
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.             
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.
>3w-xxxx: scsi1: AEN: WARNING: ATA port timeout: Port #7.
>
>  This requires a hard reboot.  If I use the magic keys and reset it then
>it goes down but doesn't come back up properly, usually dieing around
>the LILO area, I believe the array or disks are left in an odd state.
>
>  Is there a way to actually slow down the disk access/read/write other
>than re-making the filesystems?  On the other systems the chunk size is
>at either 32K or 128K.  On this one in particular the chunk size is
>1024K which was determined by running a number of tests (bonnie, nfs
>reads/writes) and was found to be about the fastest for our money's
>worth.  The disk hangups didn't appear until just recently.  If there's
>no other choise I can leave the disks as read only until the data rolls
>off then remake them in 32 or 64K.
>
>Any other thoughts?
>  Robert
>
>  
>
>:wq!
>---------------------------------------------------------------------------
>Robert L. Harris                     | PGP Key ID: E344DA3B
>                                         @ x-hkp://pgp.mit.edu 
>DISCLAIMER:
>      These are MY OPINIONS ALONE.  I speak for no-one else.
>
>Diagnosis: witzelsucht  	
>
>IPv6 = robert@ipv6.rdlg.net	http://ipv6.rdlg.net
>IPv4 = robert@mail.rdlg.net	http://www.rdlg.net
>  
>



      reply	other threads:[~2003-02-28 17:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-28 14:35 Slowing down disk access? Robert L. Harris
2003-02-28 18:03 ` kwijibo [this message]

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=3E5FA488.2080208@zianet.com \
    --to=kwijibo@zianet.com \
    --cc=Robert.L.Harris@rdlg.net \
    --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