WD1200JB Smart monitoring

MJO

I have recently installed Active SMART.
A SMART monitoring program for harddrives.

Every once in a while it reports the same error.
It has to do with seek error rate.
When I study the smart values in the program it is always the same (100).
Threshold is 51 worst is 253.

I have read in a german newsgroup that it is normal for a WD1200JB.
The company he is working for has 40 WD1200JB and they are all reporting the same exact phenomenon.
It pops up at a regular interval.

Has anyone else experienced this?
I guess I shouldn't be worried, but my 60GXP is still haunting me.

BTW: It is the same with Spin up time, but according to the guy in the german newsgroup that is normal as well.
Here is a link to a forum message regarding WD600BB, the value is identical to mine.
http://www.broadbandreports.com/forum/remark,8974833~mode=flat
Another thread displaying identical values.
http://www.techspot.com/vb/showthread/t-8474.html
And another:
Google groups

gtghm

Well I have not experienced this exacly, but I will say that I have a 3ware card that monitors simular to the SMART thing, I had 2 100gb WD JB drives in raid 0 and I would get these errors simular to yours, not exactly but simular, I contacted 3ware and WD about them, 3wares responce was that their program was so good that it was seeing errors that most monitoring software wouldn't pick up. WD wanted exact drive and system information, which I provided to their engineers but they conculded that they could not confirm a problem with the drive because of the raid. They did say that any failure would be covered under warranty. So I started a stricked regiment of backing stuff up..., good thing too because one of the drives failed, the one that my 3ware software was showing errors on 8 months before... So long story short... It took 8 months but my WD drive did fail after I started seeing the errors...
At the very least I would start backing things up regularly from that drive...

"g"

MJO

Doesn't sound good.
It is my newest drive.
Sure hoping it isn't failing.
I will research some more.
Could be a difference in Smart calibration, couldn't it?

Straight_Man

Um, SMART WDs can adn do spin down and power down after short non-use times than some other brands. They were made more energy effective, and this has the side advantage of not overheating drive as fast-- spindle bearings are metal, platters metal, and metal conducts heat but does not degrade dimensionally with friction as fast as plastic or nylon(nylon is self-lubricating becasue it surface degrades). What I do, in PM, is set PM to STR and also user define to not power down drive. I do not get those results then, and my boxes run only WDs (and have for over a decade) and they last for years and even decades of 24\6.5 run-time in some cases.

John.

gtghm

BTW, my drives never have spun down. I doin't think that the 3ware cards support drive spin down. I know that when I got the errors and the drive finaly failed it wasn't spinning down.
And the drive that failed was just over a year old. I think that age has nothing to do with it. Sometimes you get a bad drive, it just so happends that wd makes some of the best most reliable drives in the world so there is a lot of them that are still in good working order. Of the 5 that I have, I ended up with one that has gone bad... Who's to say exactly why it went bad... I did the advance RMA replacement which worked out great for me and all is good again...

As I said I would just be sure to bak things up regulary and wait to see if it craps out... It is possible that its just an anomally but hey if you take the steps now if it does fail its not a big deal...

"g"

MJO

Hmm now the Seek error rate value changed back to 200
it jumps between 100 and 200.
I have added more links to discussions about this.
They are in the top post.

gtghm

If you are really conserned I would email WD support about this and see what they say, they are pretty good at answering you back. Prolly take a few days but I have always found they will get back to you. Maybe they can be more specific about what the values mean and if they are with in spec.

GL,
"g"

gtghm

I installed that HDD health monitor and after looking at it I'm not sure how good of a progy it really is. It sees my 250gb JB drive as a 134.217gb drive...
I'm not sure how much I would rely upon this for good information....

I would email WD tech support if I was conserned...

MJO

I think I will try another program first.
A lot of the reports have been from the same program.
It wouldn't be a bad idea to get a second opinion.

EDIT: I have submitted a question to WD support now.
It should take 2-3 business days.

Straight_Man

Um, EIDE WDs do not need external controller(like mobo or PCI card controller) commands to spin down, they do it internally. MOSt of them park read\write heads when doing so, the 60GB BBs also latch with a spring-loaded latch mech into park-- the click is drive stepper motor putting enough motion force against latch that latch releases. That is one reason an inactive WD can take a greater than 40 G hit while out of box and work afterwards-- read\write arms are latched about 1\4" from drive platter on X axis. But, benchers do not allow for unlock and spinup time, they measure time from signal to HD controller to read response. SMART is mostly used to bad-map bad places on drive internal to drive due to tiny and minor media failures or defects, that is why it was first developed. Most media on HDs is about 95-99% good, from real good mfrs. SMART can bad-map weak or bad places for up to 4-5% of smaller drives, using range tables. That is why WD uses the SMART-capable utils to validate drives, some errors are mapped out internal to drive.

When you zero-pack a drive, only marginally bad areas of drive can be reset in smart drive table if they can be zero-packed right, which is one reason I do a decent amount of zero-packing in fixing drives with apparently bad areas per CHKDSK or FDISK. The decade+ old WD actually has been zero-packed 15 times over the years, and half of those were due to viruses that were best killed by zero-packing. Some of the stealths, auto replicators on attack, and boot sector viruses respond well to this process...

--> MJO, I doubt very much that you have a bad drive, it is what your bencher is not allowing for that gives you the dips, and this is in hardware and firmware tunings for other reasons causing spinups or longer seeks that influence net rate benching. The drives can tolerate this, most of the ones from Wd, and were literally designed to do this. Ad drive thta has just started to auto-spin down will have a response lag that shows up as low data flow due to how the throughput is analyzed. Most WDs also have a 8.9 ms average seek, and that is measured from mid platter to edge move and read from time HD gets a seek. So most benchers use that as measurement if that area of drive is free for a test file write. If not, you get seek time varying and dependent on where on platter HD is reading and writing from, physically. Because of the way things are benched, with net rate, seek time increase means slower rate shown outward.

This is why I can get one bench rate on a drive that is fragged and a rad better one on a defragged drive under NTFS systems, especially, with any drive with a platter and motor mech set originally designed for EIDE implementations regardless of the controller card type embedded on drive mech. NTFS chunks empty space better when defragged, and the benchers typically use files smaller than the open chunks of media space. Thus reach distance and seek time are reduced, takes less long to start writing, and time from copmmand to end of write is less, as benchers can use first open chunk on a drive that is defragged and has NTFS on it.

John.

MJO

I doubt that the drive is defective too.
Mostly because there is a system in the fluctuations.
It fluctuates at a set interval it seems.

I have asked WD support though, it will be interesting to hear their oppinion.

Straight_Man

Yeah, if you gave them serial number of drive they can batch trace to SMART subversion, platter and motor used, etc. Then they can tell you why for their drive, if they have enough folks to reseacrch that in detail in very timely way. The 1200JBs were large batch and limited time produced, depending on batch of platters made and coated for that drive. They are not in continuous production. Seek time is same for them as your 60GB BB series, to less than the tenth of a ms. 60's through 120's can have same platters and stepper motors as the BB series, and that is why I use mostly BB series except where I have a client with a lot of large files, where the larger buffer helps. Benchmark utils use smaller files, typically, than the larger buffer would give an appreciable (large) advantage for. A large DB file (2-5 GB), written and timed to a JB and a BB series, would show the effects of the buffer size advantage for large files, and WDs in large sizes are larger file optimized for the most part.

Windows actually uses my JBs better than Linux, Linux uses smaller delay buffer sizes and can thus write smaller chunks more often. Linux benches and tunes modes based on a seek command to time complete bench, and uses fairly small files to do so.

It was regularity of cycle that led me to discuss spin down and spin up and park and seek times....

John.

MJO

I gave them all the info I could.
Model, S/N, controller manufacturer and everything else they might need.

BTW: I do not own a 600BB, I referred to one of my links at the top.
A guy had exactly the same issue with his 600BB.
I have a WD800JB, a WD1200JB and a crappy IBM 10 GB

MJO

WD Support answered me today.
I do not think that I became much wiser though.
I will run the Diagnositc Utilities, just to be on the safe side.

There are no known issues such as those which you describe. It is unlikley to be a defective unit, be to be sure please test the drive with our Diagnostic Utilities (DLGDiag.zip) from the link below (please download to a hard drive, unzip, and then extract to a floppy (by simply clicking on the diskette creator) and reboot to the floppy to run the extended test.
There will certainly be a 'bottleneck' converting SATA (ATA 150) to PATA (ATA 100/ 133) that may be causing this.

Maybe I should try putting it on the PATA controller and see if it stops?