All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brad Campbell <brad@wasp.net.au>
To: Guy <bugzilla@watkins-home.com>
Cc: 'Mark Klarzynski' <mark.k@computer-design.co.uk>,
	linux-raid@vger.kernel.org
Subject: Re: good drive / bad drive  (maxtor topic)
Date: Sun, 28 Nov 2004 10:16:53 +0400	[thread overview]
Message-ID: <41A96D55.9090205@wasp.net.au> (raw)
In-Reply-To: <200411271806.iARI6SN24012@www.watkins-home.com>

Guy wrote:
> It would be handy if someone would do an extended test of all of the disk
> drives.  Consumer Reports does this type of thing all the time, just not on
> disk drives.  I don't think they do any extended tests on any computer
> hardware.  The testing should continue for 5 years.  And it could be mostly
> automated.  No user interaction unless something goes wrong.  Now we need
> someone with money!  :)
> 

Problem with this is by the time the test has any sort of meaningful data, the drives have been 
obsoleted/EOL'd.

For the record I have 12 Maxtor Maxline-II 250GB drives here which have 200 days on the clock and 
nary a hiccup. I don't doubt people have trouble with Maxtor drives, hell prior to the release of 
the Maxline-II drives I would not have looked at them sideways, too many previous bad experiences.
Having said that, I have had just as many Seagate drives fail and I won't touch them either. I had a 
bad run with WD and the dodgy firmware that failed when used in a RAID, and I have had a couple of 
them fail recently.

The only drives I have had long enough to consider a good sample were Quantum Fireballs, and I ran 
those for 5 years with no failures. A friend of mine, however was not so lucky and had a huge 
failure rate with them.

Besides the IBM deathstar fiasco I really believe there appears to be little rhyme or reason to 
patterns of failure. Bad batches, lousy operating conditions, different usage patterns, bad 
wholesaler/transport handling will all play a part.

I'm just crossing my fingers and making sure the drives are well cooled, have minimised temperature 
cycling (not shutting the box down unless I have to) and are well monitored.

I'm about to purchase another 25 Maxline-II's so that might help with the sample distribution.
(At least Maxtor have a decent RMA process, WD's internation RMA process sucks)

-- 
Brad
                    /"\
Save the Forests   \ /     ASCII RIBBON CAMPAIGN
Burn a Greenie.     X      AGAINST HTML MAIL
                    / \

  reply	other threads:[~2004-11-28  6:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-25 11:46 good drive / bad drive (maxtor topic) Mark Klarzynski
2004-11-27 18:06 ` Guy
2004-11-28  6:16   ` Brad Campbell [this message]
2004-11-28  6:56     ` Guy
  -- strict thread matches above, loose matches on Subject: below --
2004-11-24 17:36 Mark Klarzynski
2004-11-24 22:27 ` David Greaves

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=41A96D55.9090205@wasp.net.au \
    --to=brad@wasp.net.au \
    --cc=bugzilla@watkins-home.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=mark.k@computer-design.co.uk \
    /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.