From: Tejun Heo <htejun@gmail.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
linux-ide@vger.kernel.org, apiszcz@solarrain.com
Subject: Re: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
Date: Mon, 10 Dec 2007 17:14:54 +0900 [thread overview]
Message-ID: <475CF57E.7060406@gmail.com> (raw)
In-Reply-To: <4751AB91.2000207@tmr.com>
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.
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. :-)
--
tejun
next prev parent reply other threads:[~2007-12-10 8:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-01 11:26 Kernel 2.6.23.9 / 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.4.64.0712011155110.6257@p34.internal.lan>
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 [this message]
2007-12-13 22:27 ` Bill Davidsen
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
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=475CF57E.7060406@gmail.com \
--to=htejun@gmail.com \
--cc=apiszcz@solarrain.com \
--cc=davidsen@tmr.com \
--cc=jengelh@computergmbh.de \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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).