From: Bill Davidsen <firstname.lastname@example.org>
To: Tejun Heo <email@example.com>
Cc: Jan Engelhardt <firstname.lastname@example.org>,
Justin Piszcz <email@example.com>,
Subject: Re: Kernel 220.127.116.11 / P35 Chipset + WD 750GB Drives (reset port)
Date: Thu, 13 Dec 2007 17:27:39 -0500 [thread overview]
Message-ID: <4761B1DB.firstname.lastname@example.org> (raw)
Tejun Heo wrote:
> Bill Davidsen wrote:
>> Jan Engelhardt wrote:
>>> On Dec 1 2007 06:26, Justin Piszcz wrote:
>>>> I ran the following:
>>>> dd if=/dev/zero of=/dev/sdc
>>>> dd if=/dev/zero of=/dev/sdd
>>>> dd if=/dev/zero of=/dev/sde
>>>> (as it is always a very good idea to do this with any new disk)
>>> Why would you care about what's on the disk? fdisk, mkfs and
>>> the day-to-day operation will overwrite it _anyway_.
>>> (If you think the disk is not empty, you should look at it
>>> and copy off all usable warez beforehand :-)
>> Do you not test your drive for minimum functionality before using them?
> I personally don't.
>> Also, if you have the tools to check for relocated sectors before and
>> after doing this, that's a good idea as well. S.M.A.R.T is your friend.
>> And when writing /dev/zero to a drive, if it craps out you have less
>> emotional attachment to the data.
> Writing all zero isn't too useful tho. Drive failing reallocation on
> write is catastrophic failure. It means that the drive wanna relocate
> but can't because it used up all its extra space which usually indicates
> something else is seriously wrong with the drive. The drive will have
> to go to the trash can. This is all serious and bad but the catch is
> that in such cases the problem usually stands like a sore thumb so
> either vendor doesn't ship such drive or you'll find the failure very
> early. I personally haven't seen any such failure yet. Maybe I'm lucky.
The problem is usually not with what the vendor ships, but what the
carrier delivers. Bad handling does happen, "drop ship" can have several
meanings, and I have received shipments with the "G sensor" in the case
triggered. Zero is a handy source of data, but the important thing is to
look at the relocated sector count before and after the write. If there
are a lot of bad sectors initially, the drive is probably a poor choice
for anything critical.
> Most data loss occurs when the drive fails to read what it thought it
> wrote successfully and the opposite - reading and dumping the whole disk
> to /dev/null periodically is probably much better than writing zeros as
> it allows the drive to find out deteriorating sector early while it's
> still readable and relocate. But then again I think it's an overkill.
> Writing zeros to sectors is more useful as cure rather than prevention.
> If your drive fails to read a sector, write whatever value to the
> sector. The drive will forget about the data on the damaged sector and
> reallocate and write new data to it. Of course, you lose data which was
> originally on the sector.
> I personally think it's enough to just throw in an extra disk and make
> it RAID0 or 5 and rebuild the array if read fails on one of the disks.
> If write fails or read fail continues, replace the disk. Of course, if
> you wanna be extra cautious, good for you. :-)
Bill Davidsen <email@example.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
next prev parent reply other threads:[~2007-12-13 22:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-01 11:26 Kernel 18.104.22.168 / P35 Chipset + WD 750GB Drives (reset port) Justin Piszcz
2007-12-01 12:13 ` Jan Engelhardt
2007-12-01 12:23 ` Justin Piszcz
[not found] ` <20071201174733.646a5c35@absurd>
[not found] ` <Pine.LNX.firstname.lastname@example.org>
2007-12-02 9:11 ` Justin Piszcz
2007-12-10 8:23 ` Tejun Heo
2007-12-01 18:44 ` Bill Davidsen
2007-12-10 8:14 ` Tejun Heo
2007-12-13 22:27 ` Bill Davidsen [this message]
2007-12-06 22:00 ` Andrew Morton
2007-12-06 22:38 ` Justin Piszcz
2007-12-06 23:05 ` Andrew Morton
[not found] <fa.hhS4g1h0uppt8Xx/ZZfNNQfAv1Q@ifi.uio.no>
2007-12-01 20:08 ` Robert Hancock
[not found] ` <fa.YIWyRfjQw18aIH2fKaze37Gwuzo@ifi.uio.no>
[not found] ` <fa.ib4H8TQ3raADIWdsEBy+eSL/1RU@ifi.uio.no>
[not found] ` <fa.S4u1AwoYnqrSuegcUaP78D3SFXQ@ifi.uio.no>
[not found] ` <fa.H1nTe/xQV/oyEMTHAkOjqgqu7jY@ifi.uio.no>
[not found] ` <fa.YpQ6xCPOijQOCKsLJr1SDINFURI@ifi.uio.no>
2007-12-05 1:26 ` Robert Hancock
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).