Back in the days "when the silicon first cooled off" drives came with a bad sector list and you had to do a low level format with debug and enter the bad sectors. With modern drives all running perpendicular recording, I not surprised that there may be a lot of ECC corrected reads. I also can't imagine that they don't have a lot of bad sectors in "factory new" condition and develop more over time, but the intelligence built into the modern drive controllers masks that information from "mere mortals." In order to extract the maximum capacity for the lowest cost, I think, but haven't checked the specs, that most drives have all sorts of fancy thing going on "under the hood" like variable cluster counts per cylinder as the diameter of the platter increases and variable RPM, etc. All in all they are remarkable machines (wonder if there has been a "Modern Marvels" program about hard drives?) and I saw a Samsung 2TB for $69 after MIR on Newegg or TD this week! <br>
<br> Most folks probably wouldn't care or ever know that their drive had some "minor"
errors so long as their computer kept working. Seems everybody gets
"religion" about backing up immediately AFTER the drive crashes!<br><br>From the prices I see on 2.5" drives these days, I rather doubt that they are all covered with diamond dust. However, they have been made with glass platters for quite a while. The glass platters are stiffer than metal ones that [used to be] used on 3.5" drives so they don't flutter as much with minor bumps and this also helps account for their ruggedness. Smaller platters also mean smaller/less massive r/w heads which are less likely to flex enough to contact the media. I wonder if the diamond dust isn't/wasn't more a "pixie dust" marketing gimmick more than a real contributor to drive ruggedness? It would seem to me that the diamond dust would erode the heads in short order (can you say diamond grinding wheel?), rather than getting a gouge in the media surface; which would be better?<br>
GC<br> <br><br><br><div class="gmail_quote">On Wed, Jan 5, 2011 at 11:31 PM, Greg Freemyer <span dir="ltr"><<a href="mailto:greg.freemyer@gmail.com">greg.freemyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Wed, Jan 5, 2011 at 8:42 PM, Pat Regan <<a href="mailto:thehead@patshead.com">thehead@patshead.com</a>> wrote:<br>
> On Wed, 5 Jan 2011 19:23:10 -0500<br>
> Greg Freemyer <<a href="mailto:greg.freemyer@gmail.com">greg.freemyer@gmail.com</a>> wrote:<br>
><br>
>> The first thing I look at is POH (Power on Hours). In this case<br>
>> 27,871. This field has been pretty reliable in my experience to be<br>
>> exactly what it says. So my drive is not exactly new.<br>
><br>
> That's a pretty good specimen, 3 years powered on :)<br>
><br>
>> Then look at Reallocated_Sector_Ct. Mine is zero. That's cool.<br>
><br>
> I'm probably not telling you this, but when I see this number start to<br>
> move away from 0 I start ordering a replacement drive :)<br>
><br>
> Interestingly, the X25-M in my laptop is showing 1 relocated sector.<br>
><br>
>> But Hardware_ECC_Recovered is 140,010,573. That may sound large, but<br>
>> remember, the reads succeeded because of the ECC data, so there is no<br>
>> data loss. I tend to agree with you that as magnetism fades for a<br>
>> sector, checksum failures increase and ECC recovery is needed.<br>
>> Spinrite used as you describe may keep that value lower.<br>
><br>
> It may sound large, but what does it really mean? Is it literally the<br>
> number of ECC errors? How large is a single ECC block? How many ECC<br>
> blocks are involved in the read of a single sector? Could every bad<br>
> ECC in a sector result in the count going up? 5000 per hour sounds<br>
> like a lot of recovered reads to me, assuming it means sectors.<br>
<br>
</div>Pat,<br>
<br>
A disk drive physical sector is the equivalent of a network packet.<br>
<br>
It has a header, payload, footer.<br>
<br>
And it has exactly one CRC / ECC value as I understand it.<br>
<br>
The new "Advanced Format" drives from WD have 4KB physical sectors.<br>
The benefit being less waste to overhead. ie. Only one header/footer<br>
per 4KB instead of every 512 bytes. The ECC is bigger, but not 8x<br>
bigger.<br>
<br>
>> But I don't think spinrite tries to detect sectors that have been ECC<br>
<div class="im">>> recovered. So it doesn't really know the details.<br>
><br>
> I would agree. The drives in my laptop don't report ECC errors via<br>
> smart.<br>
><br>
>> A smart long self test has the ability to know that a ECC recovery is<br>
>> needed for a sector. What it does with the knowledge, I don't know.<br>
>> But it certainly has more knowledge to work with than spinrite.<br>
><br>
> How thorough do you think a long smart test is? I've had drives die<br>
> within a day or three of passing a long smart test. They also don't<br>
> take all that long, and they sure don't cause the drive to make any<br>
> noise :)<br>
<br>
</div>I think / believe the long test to primarily be a surface test. Total<br>
disk drive failure is not caused by platter surface errors I would<br>
guess, so I see little reason for correlation. ie. I'm not surprised<br>
at a controller failure a few hours after the platter surface test<br>
showed it good.<br>
<div class="im"><br>
>> fyi: hdparm has a long read capability that allows a full physical<br>
>> sector to be read with no error correction! So spinrite could in<br>
>> theory read all of the sectors with CRC verification disabled and<br>
>> check the CRC itself. The trouble is the the drive manufactures<br>
>> implement proprietary CRC / ECC solutions, so spinrite has no way to<br>
>> actually delve into the details of the sectors data accuracy.<br>
><br>
> I doubt that spinrite does this.<br>
<br>
</div>So do I.<br>
<div><div></div><div class="h5"><br>
>> fyi: hdparm has a way to force a write to Pending Sector and put new<br>
>> good data on it. Thus spinrite could do this if it wanted to as well.<br>
>> I certainly hope it is not doing so.<br>
><br>
> My understanding is that spinrite attempts to read every sector and<br>
> (eventually) write them back to the disk. If it fails to read<br>
> correctly it will start reading similarly to dd_rescue.<br>
><br>
>> > It also doesn't mean that the sector has been reallocated.<br>
>><br>
>> You imply a sector can be moved without it being reallocated. I think<br>
>> that is wrong. The only way to move the sector is to allocate a spare<br>
>> and use it instead of the original.<br>
><br>
> I think he's implying that the data in the sector can be moved by<br>
> software. That can't be done without Spinrite understanding the file<br>
> system and making the appropriate changes. It definitely doesn't do<br>
> this.<br>
><br>
>> > This forces the drive's firmware to evaluate the performance at<br>
>> > that point, and forces the surface to absorb both a 1 and 0 in turn<br>
>> > at that point. Also, I believe that the magnetic fields<br>
>> > deteriorate over time. I could probably corroborate that with some<br>
>> > extensive research.<br>
>><br>
>> Agreed, but I often store hard drives offline for extended periods.<br>
>> We rarely see read failures for drives we put back on line. So the<br>
>> deteriation is very slow and not likely to be an issue.<br>
><br>
> How do you know? Sun published a lot of numbers related to silent data<br>
> corruption. ECC is pretty fallible. Especially when it has to be used<br>
> to correct data 150 million times.<br>
<br>
</div></div>We MD5 hash our major data files before we put the drives off-line.<br>
<br>
When we bring them back we do a MD5 hash verify.<br>
<br>
Very few issues seem to crop up due to offline storage. Even if its<br>
been a year or two.<br>
<br>
We also keep tape backups when we do this and I can rarely think of us<br>
having to restore the tape.<br>
<div class="im"><br>
>> fyi: The DOD uses thermite in the drive platter area to heat the media<br>
>> to several hundred degrees. When this happens the magnetism is<br>
>> released and the data is gone.<br>
><br>
> The magic smoke gets out!<br>
><br>
>> Especially with laptop drives, you get physical damage as the flying<br>
>> head hits the platters from time to time. To protect the platters,<br>
>> they are often actually coated with a fine coat of diamond dust.<br>
>> That's one reason laptop drives cost more.<br>
><br>
> Laptop drives are rated for higher g forces than desktop drives.<br>
> Taking both apart I wouldn't guess that, it must have something to do<br>
> with the inertia of lighter parts.<br>
<br>
</div>desktop drives are not designed to have the head hit the platter. ie.<br>
The head is meant to always fly, so a small bump makes a gauge in the<br>
platter.<br>
<br>
Laptop drives are designed for occasional contact with no damage, so<br>
more G's. (Thus the diamond dust coating.)<br>
<div class="im"><br>
>> > The read invert write read invert write cycle, if nothing else,<br>
>> > will ensure that all the magnetic bits are good and strong since<br>
>> > they are all ultimately rewritten.<br>
>><br>
>> True, but I think normal degradation is much slower than you imply.<br>
><br>
> I agree.<br>
><br>
>> For a drive you've treated with spinrite, what's your ECC_Recovered /<br>
>> POH ratio.<br>
>><br>
>> ie. Mine is 5000 recoveries per power on hour. And I don't do<br>
>> anything to "maintain" it. This is just my desktop machine.<br>
><br>
> I wish we had old smart numbers for your drive. I wonder if that ratio<br>
> has been increasing over time and if so, by how much.<br>
<br>
</div>Sorry, no history available.<br>
<div class="im"><br>
>> I believe a smart long self test will read all of the sectors and<br>
>> identify those that are not ECC Recoverable. I don't think it will<br>
>> actually reallocate them.<br>
><br>
> I don't believe a long smart self test touches every sector. A long<br>
> test runs much too fast for that, at least on the drives I've paid<br>
> attention to.<br>
<br>
</div>Do you have a rough GB / min rate for the long test?<br>
<br>
With modern drives, I can dd if=/dev/zero of=/dev/sda bs=4k at about<br>
6GB / min. I can't say I've done a lot of the long tests, but that<br>
seems about the same performance.<br>
<br>
My 250GB drive says 92 minutes to run the long test. That's less than<br>
3GB/min, so plenty of time to do a full surface scan.<br>
<div class="im"><br>
>> What spinrite likely does is read the sector in various ways. ie many<br>
>> data recovery tools can read the sectors in reverse order. This<br>
>> causes the drive to align the head slightly differently I believe.<br>
>> Due to that slight change, some bad sectors can be read. So I<br>
>> actually do think spinrite could have some logic to do this that<br>
>> normal read logic would not have.<br>
><br>
> BACKUPS, BACKUPS, BACKUPS. And then more backups. Data recovery is<br>
> for people who don't have backups :).<br>
<br>
</div>I tend to work a lot with other peoples drives, so I'm the one making<br>
the backup! (And I never see spinrite recommended by people in my<br>
industry - computer forensics.)<br>
<br>
For files I control, I tend to keep two copies of important files on a<br>
minimum of 2 media, often 3 or more. But I've had 2 drives fail<br>
within hours of each other! (both young drives during the height of<br>
Seagate's problems. Fortunately, replacing the controller card on one<br>
of the drives brought it back to life.)<br>
<div><div></div><div class="h5"><br>
>> > Again, this may or<br>
>> > may not trigger sector reallocation.<br>
>><br>
>> I surely hope writing to a sector previously had read failures not<br>
>> handle-able via ECC recovery triggers a reallocate.<br>
><br>
> If it doesn't then you're out of spare sectors and the drive is ready<br>
> for the scrap heap. This is also one of the reasons why you want to<br>
> image a bad drive onto a good drive. Once you start writing you can<br>
> really screw things up even more.<br>
><br>
>> > Spinrite will report these data<br>
>> > areas as recovered or unrecovered as appropriate. The drive itself<br>
>> > may still be fully usable, if, for example, the data error was<br>
>> > caused by a power failure, but the drive was not damaged. If<br>
>> > sectors start getting reallocated, I would agree that it's time to<br>
>> > consider changing the drive out, as I did with one of mine last<br>
>> > night.<br>
>><br>
>> I'm not so sure I agree. A lot of reallocates are just physical<br>
>> platter issues. It used to be that drives shipped new with lots<br>
>> reallocated sectors.<br>
>><br>
>> Admittedly, new ones tend to have zero anymore.<br>
><br>
> Drives are cheap. RMAing a drive is cheap. If a drive starts acting<br>
> up and doesn't want to stay in one of my RAIDs it is time to replace<br>
> it. I saw a 5900 rpm seagate 2 TB drive on sale for $100 shipped<br>
> today.<br>
><br>
> I could probably also argue that I don't completely trust a drive fresh<br>
> out of the box, either :)<br>
<br>
</div></div>I actually like the idea of putting 20 or 30 or more operational hours<br>
on a drive before putting real data on it. We write a single pass of<br>
zeros to new drives before putting them in service, but a couple years<br>
ago with Seagate, that was not enough of a burn in. Maybe 3 or 4<br>
passes would have done it.<br>
<br>
> Pat<br>
<font color="#888888">Greg<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br>