linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrik Jonsson <patrik@ucolick.org>
To: Andy Smith <andy@lug.org.uk>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Checking the sanity of SATA disks
Date: Tue, 04 Oct 2005 08:59:40 -0700	[thread overview]
Message-ID: <4342A6EC.7090208@ucolick.org> (raw)
In-Reply-To: <20051004142913.GK6594@strugglers.net>

Hi,

There is a patch that can be applied to libata that enables SMART for 
SATA drives. It's not 100% stable, so running smartd is not recommended, 
but I've been running nightly SMART selftests and 5-minute temperature 
logging on our 8-drive array since June and has never run into a problem 
(though it's not a very heavily used machine). ymmv... See e.g. 
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/2304.html

/Patrik

Andy Smith wrote:

>Hello,
>
>I have a home fileserver with 4 SATA disks in a RAID 5.  As I am
>sure you are aware, SATA devices in Linux currently cannot be
>queried for SMART info, so I can't do SMART health checks of these
>devices.
>
>Also there is still the tendency for Linux Software RAID to kick
>devices out of the array as soon as there is any error on them.
>
>I really don't want to be in the situation where a drive dies, I fit
>a new one, and during the resync another device is kicked out
>because of spontaneously finding a bad sector.
>
>I tried simply doing a
>
>        dd if=/dev/sd[abcd] of=/dev/null
>
>To check each disk in a very unsubtle fashion, but it drives the
>load average on the machine way way up (like to 20+) and makes it
>very unresponsive (wait several minutes for a keypress to be
>acknowledged), even if I run it under nice -n 19.
>
>I don't notice any performance problems on this server during normal
>day to day use, and while it's not particularly beefy it is an AMD
>Sempron 1.8GHz so I am surprised that simply reading from one disk
>causes these performance issues.
>
>I know this isn't right, so has anyone got any advice in the way of
>tracking down which part of the system is at fault, possibly
>off-list if it's too offtopic?
>
>Thanks,
>Andy
>  
>
>------------------------------------------------------------------------
>
>!DSPAM:434291cc89982461629467!
>

  parent reply	other threads:[~2005-10-04 15:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-04 14:29 Checking the sanity of SATA disks Andy Smith
2005-10-04 14:42 ` Molle Bestefich
2005-10-04 14:56   ` Andy Smith
2005-10-04 15:02     ` Molle Bestefich
2005-10-04 15:59 ` Patrik Jonsson [this message]
2005-10-04 17:32 ` Dan Stromberg
2005-10-05 11:08   ` Andy Smith
2005-10-09 15:21 ` Mark Hahn
2005-11-07 19:22 ` Bill Davidsen

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=4342A6EC.7090208@ucolick.org \
    --to=patrik@ucolick.org \
    --cc=andy@lug.org.uk \
    --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).