Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Slow write speeds on a WD 500GB drive
84 views
Skip to first unread message
bbbl67
Apr 22, 2012, 6:20:08 PM4/22/12
to
A friend of mine had an WD My Book external case, which contained a
500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
the way the My Book's interface failed, it's warranty was expired, and
so we took its hard drive out and installed it directly inside his PC
case. This was back in mid- to late-2011, that it was transferred from
external to internal. It seemed to be fine for the most part in
performance, but recently we did some benchmarking and we were shocked
to find that although its reading speeds seem normal (around 50-60 MB/
s), its write speeds were shockingly low (around 10 MB/s, if even
that). What could cause such a weird asymmetry in read vs. write
speeds? It didn't seem that slow while it was inside the My Book case.
This is one of those WD Caviar Green drives, so I'm wondering if there
is some kind of power savings setting affecting it?
Yousuf Khan
500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
the way the My Book's interface failed, it's warranty was expired, and
so we took its hard drive out and installed it directly inside his PC
case. This was back in mid- to late-2011, that it was transferred from
external to internal. It seemed to be fine for the most part in
performance, but recently we did some benchmarking and we were shocked
to find that although its reading speeds seem normal (around 50-60 MB/
s), its write speeds were shockingly low (around 10 MB/s, if even
that). What could cause such a weird asymmetry in read vs. write
speeds? It didn't seem that slow while it was inside the My Book case.
This is one of those WD Caviar Green drives, so I'm wondering if there
is some kind of power savings setting affecting it?
Yousuf Khan
Rod Speed
Apr 22, 2012, 10:16:58 PM4/22/12
to
bbbl67 <yjk...@gmail.com> wrote
Cant see why any of those would produce that effect only with writes.
They are mostly just 5400 RPM drives to get the 'green' result.
You sure its hasn't got verify after write turned on ?
Why have you changed your nick but kept the email address unmunged ?
They are mostly just 5400 RPM drives to get the 'green' result.
You sure its hasn't got verify after write turned on ?
Why have you changed your nick but kept the email address unmunged ?
bbbl67
Apr 22, 2012, 11:45:34 PM4/22/12
to
On Apr 22, 10:16 pm, "Rod Speed" <rod.speed....@gmail.com> wrote:
> Cant see why any of those would produce that effect only with writes.
>
> They are mostly just 5400 RPM drives to get the 'green' result.
The specs seem to just try to hide the speed behind some marketing
> Cant see why any of those would produce that effect only with writes.
>
> They are mostly just 5400 RPM drives to get the 'green' result.
term called IntelliSpeed or something.
> You sure its hasn't got verify after write turned on ?
> Why have you changed your nick but kept the email address unmunged ?
Arno
Apr 23, 2012, 3:44:15 AM4/23/12
to
bbbl67 <yjk...@gmail.com> wrote:
> A friend of mine had an WD My Book external case, which contained a
> 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
> the way the My Book's interface failed, it's warranty was expired, and
> so we took its hard drive out and installed it directly inside his PC
> case. This was back in mid- to late-2011, that it was transferred from
> external to internal. It seemed to be fine for the most part in
> performance, but recently we did some benchmarking and we were shocked
> to find that although its reading speeds seem normal (around 50-60 MB/
> s), its write speeds were shockingly low (around 10 MB/s, if even
> that). What could cause such a weird asymmetry in read vs. write
> speeds? It didn't seem that slow while it was inside the My Book case.
From my experience, this sounds like the drive has problems
> A friend of mine had an WD My Book external case, which contained a
> 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
> the way the My Book's interface failed, it's warranty was expired, and
> so we took its hard drive out and installed it directly inside his PC
> case. This was back in mid- to late-2011, that it was transferred from
> external to internal. It seemed to be fine for the most part in
> performance, but recently we did some benchmarking and we were shocked
> to find that although its reading speeds seem normal (around 50-60 MB/
> s), its write speeds were shockingly low (around 10 MB/s, if even
> that). What could cause such a weird asymmetry in read vs. write
> speeds? It didn't seem that slow while it was inside the My Book case.
positioning or finding sectors. If it was finding sectrors, then
the read-speed should also be affected. My guess would be weak
power or vibration that makes the more precise head positioning on
writes difficult.
> This is one of those WD Caviar Green drives, so I'm wondering if there
> is some kind of power savings setting affecting it?
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: ar...@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
Arno
Apr 23, 2012, 10:49:32 AM4/23/12
to
bbbl67 <yjk...@gmail.com> wrote:
as the lower speed allows for higher data density.
>> You sure its hasn't got verify after write turned on ?
> What is that? It sounds like something you do in software.
It used to be a software setting for floppy disks in the DOS age
and it is just as irrrelevant today. It would also only about halve t
he speed, not bring it down as much as you see.
Just Rod's usual atrocious lack of insight at work.
Arno
>> Why have you changed your nick but kept the email address unmunged ?
> I'm posting from Google groups, that's all.
> On Apr 22, 10:16?pm, "Rod Speed" <rod.speed....@gmail.com> wrote:
>> Cant see why any of those would produce that effect only with writes.
>>
>> They are mostly just 5400 RPM drives to get the 'green' result.
> The specs seem to just try to hide the speed behind some marketing
> term called IntelliSpeed or something.
5400 rpm is only 25% less. Thoughput is usualy comparable
>> Cant see why any of those would produce that effect only with writes.
>>
>> They are mostly just 5400 RPM drives to get the 'green' result.
> The specs seem to just try to hide the speed behind some marketing
> term called IntelliSpeed or something.
as the lower speed allows for higher data density.
>> You sure its hasn't got verify after write turned on ?
> What is that? It sounds like something you do in software.
and it is just as irrrelevant today. It would also only about halve t
he speed, not bring it down as much as you see.
Just Rod's usual atrocious lack of insight at work.
Arno
>> Why have you changed your nick but kept the email address unmunged ?
> I'm posting from Google groups, that's all.
bbbl67
Apr 23, 2012, 12:19:46 PM4/23/12
to
On Apr 23, 3:44 am, Arno <m...@privacy.net> wrote:
> bbbl67<yjk...@gmail.com> wrote:
> > A friend of mine had an WD My Book external case, which contained a
> > 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
> > the way the My Book's interface failed, it's warranty was expired, and
> > so we took its hard drive out and installed it directly inside his PC
> > case. This was back in mid- to late-2011, that it was transferred from
> > external to internal. It seemed to be fine for the most part in
> > performance, but recently we did some benchmarking and we were shocked
> > to find that although its reading speeds seem normal (around 50-60 MB/
> > s), its write speeds were shockingly low (around 10 MB/s, if even
> > that). What could cause such a weird asymmetry in read vs. write
> > speeds? It didn't seem that slow while it was inside the My Book case.
>
> From my experience, this sounds like the drive has problems
> positioning or finding sectors. If it was finding sectrors, then
> the read-speed should also be affected. My guess would be weak
> power or vibration that makes the more precise head positioning on
> writes difficult.
>
> > This is one of those WD Caviar Green drives, so I'm wondering if there
> > is some kind of power savings setting affecting it?
>
> Not that bad.
I'm gonna switch it to the IDE driver to see if it fixes it somehow
> bbbl67<yjk...@gmail.com> wrote:
> > A friend of mine had an WD My Book external case, which contained a
> > 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
> > the way the My Book's interface failed, it's warranty was expired, and
> > so we took its hard drive out and installed it directly inside his PC
> > case. This was back in mid- to late-2011, that it was transferred from
> > external to internal. It seemed to be fine for the most part in
> > performance, but recently we did some benchmarking and we were shocked
> > to find that although its reading speeds seem normal (around 50-60 MB/
> > s), its write speeds were shockingly low (around 10 MB/s, if even
> > that). What could cause such a weird asymmetry in read vs. write
> > speeds? It didn't seem that slow while it was inside the My Book case.
>
> From my experience, this sounds like the drive has problems
> positioning or finding sectors. If it was finding sectrors, then
> the read-speed should also be affected. My guess would be weak
> power or vibration that makes the more precise head positioning on
> writes difficult.
>
> > This is one of those WD Caviar Green drives, so I'm wondering if there
> > is some kind of power savings setting affecting it?
>
> Not that bad.
today.
Yousuf Khan
Message has been deleted
bbbl67
Apr 23, 2012, 2:03:48 PM4/23/12
to
On Apr 23, 12:19 pm, bbbl67 <yjk...@gmail.com> wrote:
> I'm gonna switch it to the IDE driver to see if it fixes it somehow
> today.
>
> Yousuf Khan
Well, it looks like that didn't work. It's still horribly slow in
> I'm gonna switch it to the IDE driver to see if it fixes it somehow
> today.
>
> Yousuf Khan
writes, here's a screen cap for ATTO benchmark on it:
http://imageshack.us/photo/my-images/24/captureattowdc500gbbenc.jpg/
Arno
Apr 23, 2012, 5:13:55 PM4/23/12
to
bbbl67 <yjk...@gmail.com> wrote:
> Well, it looks like that didn't work. It's still horribly slow in
> writes, here's a screen cap for ATTO benchmark on it:
> http://imageshack.us/photo/my-images/24/captureattowdc500gbbenc.jpg/
Hmm. The write speed is pretty consistent and on the level of
512B writes. Maybe multi-sector transfer is off?
> On Apr 23, 12:19?pm, bbbl67 <yjk...@gmail.com> wrote:
>> I'm gonna switch it to the IDE driver to see if it fixes it somehow
>> today.
>>
>> ? Yousuf Khan
>> I'm gonna switch it to the IDE driver to see if it fixes it somehow
>> today.
>>
> Well, it looks like that didn't work. It's still horribly slow in
> writes, here's a screen cap for ATTO benchmark on it:
> http://imageshack.us/photo/my-images/24/captureattowdc500gbbenc.jpg/
512B writes. Maybe multi-sector transfer is off?
Yousuf Khan
Apr 23, 2012, 5:23:55 PM4/23/12
to
On 23/04/2012 5:13 PM, Arno wrote:
> Hmm. The write speed is pretty consistent and on the level of
> 512B writes. Maybe multi-sector transfer is off?
The drive also has one bad sector on it (actually uncorrectable sector),
> Hmm. The write speed is pretty consistent and on the level of
> 512B writes. Maybe multi-sector transfer is off?
but I can't see that causing the entire drive to become nearly unwritable.
Yousuf Khan
Rod Speed
Apr 24, 2012, 1:08:50 AM4/24/12
to
bbbl67 <yjk...@gmail.com> wrote
>> You sure its hasn't got verify after write turned on ?
> What is that?
Basically the drive reads what has just been
ritten and checks that it can read it fine.
> It sounds like something you do in software.
Most drives can have it enabled.
In fact one family of drives, Maxtors from memory,
used to have it on by default with new drives and
turned it off auto when they drive had done X
power on hours or # or writes, forget which.
Basically it was someone's idea for how to wring the
maximum capacity out of a drive, be conservative
about the initial factory bad block scan and let the
drive remap new bads with that verify after write
ensuring that the users data was safe.
Dunno how many others followed that approach or if any still do.
>> Why have you changed your nick but kept the email address unmunged ?
> I'm posting from Google groups, that's all.
But why cant you use your normal name with that too ?
I can when posting from groups.google.
> Rod Speed <rod.speed....@gmail.com> wrote
>> Cant see why any of those would produce that effect only with writes.
>> They are mostly just 5400 RPM drives to get the 'green' result.
> The specs seem to just try to hide the speed behind
> some marketing term called IntelliSpeed or something.
Yeah, tho the datasheets do spell that out with all the ones I have checked.
>> Cant see why any of those would produce that effect only with writes.
>> They are mostly just 5400 RPM drives to get the 'green' result.
> The specs seem to just try to hide the speed behind
> some marketing term called IntelliSpeed or something.
>> You sure its hasn't got verify after write turned on ?
> What is that?
ritten and checks that it can read it fine.
> It sounds like something you do in software.
In fact one family of drives, Maxtors from memory,
used to have it on by default with new drives and
turned it off auto when they drive had done X
power on hours or # or writes, forget which.
Basically it was someone's idea for how to wring the
maximum capacity out of a drive, be conservative
about the initial factory bad block scan and let the
drive remap new bads with that verify after write
ensuring that the users data was safe.
Dunno how many others followed that approach or if any still do.
>> Why have you changed your nick but kept the email address unmunged ?
> I'm posting from Google groups, that's all.
I can when posting from groups.google.
Brown Joe
Apr 24, 2012, 1:22:08 AM4/24/12
to
>> Rod Speed <rod.speed....@gmail.com> wrote
>>> Cant see why any of those would produce that effect only with writes.
>>> They are mostly just 5400 RPM drives to get the 'green' result.
>> The specs seem to just try to hide the speed behind some
>> marketing term called IntelliSpeed or something.
> 5400 rpm is only 25% less.
I clearly said that that isnt the reason for just the writes being affected.
>>> Cant see why any of those would produce that effect only with writes.
>>> They are mostly just 5400 RPM drives to get the 'green' result.
>> The specs seem to just try to hide the speed behind some
>> marketing term called IntelliSpeed or something.
> 5400 rpm is only 25% less.
> Thoughput is usualy comparable as the
> lower speed allows for higher data density.
If it was that simple they wouldn’t sell the non green drives too.
>>> You sure its hasn't got verify after write turned on ?
>> What is that? It sounds like something you do in software.
> It used to be a software setting for floppy disks in the DOS age
> and it is just as irrrelevant today.
> It would also only about halve the speed,
> not bring it down as much as you see.
Only if it isnt have a problem with the writes.
> Just Rod's usual atrocious lack of insight at work.
just got egg all over its stupid little face, as always ?
--
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP --
Rod Speed
Apr 24, 2012, 1:39:53 AM4/24/12
to
Yousuf <yjk...@gmail.com> wrote
> Yousuf wrote
>> I'm gonna switch it to the IDE driver to see if it fixes it somehow
>> today.
> Looks like the driver change didn't help. It's still pretty bad when it
> comes to writes:
> http://imageshack.us/photo/my-images/24/captureattowdc500gbbenc.jpg/
I'd try another benchmark to see if that one is getting royally confused
somehow.
> Yousuf wrote
>> I'm gonna switch it to the IDE driver to see if it fixes it somehow
>> today.
> comes to writes:
> http://imageshack.us/photo/my-images/24/captureattowdc500gbbenc.jpg/
I'd try another benchmark to see if that one is getting royally confused
somehow.
Yousuf Khan
Apr 24, 2012, 1:50:21 AM4/24/12
to
On 24/04/2012 1:08 AM, Rod Speed wrote:
> bbbl67 <yjk...@gmail.com> wrote
even five years later. Other drives had several sectors remapped, or
even unrecoverable, after only a few months, but these Maxtors stayed
error-free after half-a-decade. Ironically I just finally got rid of
those Maxtors this week too.
>>> Why have you changed your nick but kept the email address unmunged ?
>
>> I'm posting from Google groups, that's all.
>
> But why cant you use your normal name with that too ?
>
> I can when posting from groups.google.
I only use it when I'm posting from someone else's computer. It simply
was setup that way from before.
Yousuf Khan
> bbbl67 <yjk...@gmail.com> wrote
>> It sounds like something you do in software.
>
> Most drives can have it enabled.
>
> In fact one family of drives, Maxtors from memory,
> used to have it on by default with new drives and
> turned it off auto when they drive had done X
> power on hours or # or writes, forget which.
>
> Basically it was someone's idea for how to wring the
> maximum capacity out of a drive, be conservative
> about the initial factory bad block scan and let the
> drive remap new bads with that verify after write
> ensuring that the users data was safe.
That would actually explain why my old IDE Maxtors were so bullet proof,
>
> Most drives can have it enabled.
>
> In fact one family of drives, Maxtors from memory,
> used to have it on by default with new drives and
> turned it off auto when they drive had done X
> power on hours or # or writes, forget which.
>
> Basically it was someone's idea for how to wring the
> maximum capacity out of a drive, be conservative
> about the initial factory bad block scan and let the
> drive remap new bads with that verify after write
> ensuring that the users data was safe.
even five years later. Other drives had several sectors remapped, or
even unrecoverable, after only a few months, but these Maxtors stayed
error-free after half-a-decade. Ironically I just finally got rid of
those Maxtors this week too.
>>> Why have you changed your nick but kept the email address unmunged ?
>
>> I'm posting from Google groups, that's all.
>
> But why cant you use your normal name with that too ?
>
> I can when posting from groups.google.
was setup that way from before.
Yousuf Khan
Yousuf Khan
Apr 24, 2012, 1:52:52 AM4/24/12
to
forever just to write a test file to it. Even a "quick" format of the
drive was dog-slow.
Yousuf Khan
Rod Speed
Apr 24, 2012, 2:11:27 AM4/24/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
>> about the initial factory bad block scan and let the
>> drive remap new bads with that verify after write
>> ensuring that the users data was safe.
> That would actually explain why my old IDE
> Maxtors were so bullet proof, even five years later.
It doesn't, actually.
> Other drives had several sectors remapped, or
> even unrecoverable, after only a few months,
Mine never did.
> but these Maxtors stayed error-free after half-a-decade.
But that approach should have seen the Maxtors
produce more remapped sectors early on than
otherwise. Sorry I rarely bother to proof read.
> Ironically I just finally got rid of those Maxtors this week too.
They were actually notorious for dying
easier than most of not adequately cooled.
>>>> Why have you changed your nick but kept the email address unmunged ?
>>> I'm posting from Google groups, that's all.
>> But why cant you use your normal name with that too ?
>> I can when posting from groups.google.
> I only use it when I'm posting from someone else's computer.
OK.
> It simply was setup that way from before.
Yeah, I can see why too given that its your yahoo.com email address.
> Rod Speed wrote
>> bbbl67 <yjk...@gmail.com> wrote
>>> It sounds like something you do in software.
>> Most drives can have it enabled.
>> In fact one family of drives, Maxtors from memory,
>> used to have it on by default with new drives and
>> turned it off auto when they drive had done X
>> power on hours or # or writes, forget which.
>> Basically it was someone's idea for how to wring the
>> maximum capacity out of a drive, be conservative
That should have read, be LESS CONSERVATIVE
>> bbbl67 <yjk...@gmail.com> wrote
>>> It sounds like something you do in software.
>> Most drives can have it enabled.
>> In fact one family of drives, Maxtors from memory,
>> used to have it on by default with new drives and
>> turned it off auto when they drive had done X
>> power on hours or # or writes, forget which.
>> Basically it was someone's idea for how to wring the
>> maximum capacity out of a drive, be conservative
>> about the initial factory bad block scan and let the
>> drive remap new bads with that verify after write
>> ensuring that the users data was safe.
> That would actually explain why my old IDE
> Maxtors were so bullet proof, even five years later.
> Other drives had several sectors remapped, or
> even unrecoverable, after only a few months,
> but these Maxtors stayed error-free after half-a-decade.
produce more remapped sectors early on than
otherwise. Sorry I rarely bother to proof read.
> Ironically I just finally got rid of those Maxtors this week too.
easier than most of not adequately cooled.
>>>> Why have you changed your nick but kept the email address unmunged ?
>>> I'm posting from Google groups, that's all.
>> But why cant you use your normal name with that too ?
>> I can when posting from groups.google.
> I only use it when I'm posting from someone else's computer.
> It simply was setup that way from before.
Rod Speed
Apr 24, 2012, 2:16:18 AM4/24/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
That does support the claim that the drive really is very slow
to write when its not just a benchmark that claims that.
I'd try the drive in another system myself in case its actually
a problem with the machine or the controller, not the drive.
to write when its not just a benchmark that claims that.
I'd try the drive in another system myself in case its actually
a problem with the machine or the controller, not the drive.
Arno
Apr 24, 2012, 3:18:53 AM4/24/12
to
that is far more constant than a hardware problem. Unless the
disk has decided to limit its write rate due to such a problem.
Would be news to me, but sich a behaviour can certainly be
implemented.
Well, frankly I don't know. I would not trust this drive though.
Franc Zabkar
Apr 24, 2012, 11:54:12 PM4/24/12
to
On Mon, 23 Apr 2012 17:23:55 -0400, Yousuf Khan
<bbb...@spammenot.yahoo.com> put finger to keyboard and composed:
>The drive also has one bad sector on it (actually uncorrectable sector),
>but I can't see that causing the entire drive to become nearly unwritable.
Perhaps bad sectors are like cockroaches. When you see one, there may
be a lot more that you don't see.
In any case, AFAICS, bad sectors, or heads with weak read elements,
would show up during reads more so than writes.
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
<bbb...@spammenot.yahoo.com> put finger to keyboard and composed:
>The drive also has one bad sector on it (actually uncorrectable sector),
>but I can't see that causing the entire drive to become nearly unwritable.
be a lot more that you don't see.
In any case, AFAICS, bad sectors, or heads with weak read elements,
would show up during reads more so than writes.
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
Yousuf Khan
Apr 25, 2012, 1:27:17 AM4/25/12
to
On 24/04/2012 3:18 AM, Arno wrote:
> I think the consistnt write rate points to some limiting factor
> that is far more constant than a hardware problem. Unless the
> disk has decided to limit its write rate due to such a problem.
> Would be news to me, but sich a behaviour can certainly be
> implemented.
>
> Well, frankly I don't know. I would not trust this drive though.
Well, either would I, so I exchanged it with a different WD 500GB drive
> I think the consistnt write rate points to some limiting factor
> that is far more constant than a hardware problem. Unless the
> disk has decided to limit its write rate due to such a problem.
> Would be news to me, but sich a behaviour can certainly be
> implemented.
>
> Well, frankly I don't know. I would not trust this drive though.
for him. I took his old 500GB drive and put it into an eSATA case and I
am now testing it on my own system. I'll run a full SMART test on it.
Yousuf Khan
Yousuf Khan
Apr 25, 2012, 1:30:16 AM4/25/12
to
On 24/04/2012 2:16 AM, Rod Speed wrote:
> That does support the claim that the drive really is very slow
> to write when its not just a benchmark that claims that.
>
> I'd try the drive in another system myself in case its actually
> a problem with the machine or the controller, not the drive.
Doing exactly that right now. I exchanged his old 500GB for a different
> That does support the claim that the drive really is very slow
> to write when its not just a benchmark that claims that.
>
> I'd try the drive in another system myself in case its actually
> a problem with the machine or the controller, not the drive.
one. I took the old one and am now testing it on my own system in an
external eSATA case. I'm going to run a full SMART test on it, but I
don't know if it'll find anything, I think those SMART tests are just
read tests, aren't they?
Yousuf Khan
Rod Speed
Apr 25, 2012, 3:33:46 AM4/25/12
to
Franc Zabkar <fza...@internode.on.net> wrote
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
>> The drive also has one bad sector on it (actually uncorrectable sector),
>> but I can't see that causing the entire drive to become nearly
>> unwritable.
> Perhaps bad sectors are like cockroaches. When you see one, there may
> be a lot more that you don't see.
Nope, not with the SMART data.
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
>> The drive also has one bad sector on it (actually uncorrectable sector),
>> but I can't see that causing the entire drive to become nearly
>> unwritable.
> Perhaps bad sectors are like cockroaches. When you see one, there may
> be a lot more that you don't see.
Rod Speed
Apr 25, 2012, 3:35:50 AM4/25/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
Nar, they are proper tests, but don't test the write speed.
Arno
Apr 25, 2012, 7:36:27 AM4/25/12
to
Franc Zabkar <fza...@iinternode.on.net> wrote:
> On Mon, 23 Apr 2012 17:23:55 -0400, Yousuf Khan
> <bbb...@spammenot.yahoo.com> put finger to keyboard and composed:
>>The drive also has one bad sector on it (actually uncorrectable sector),
>>but I can't see that causing the entire drive to become nearly unwritable.
> Perhaps bad sectors are like cockroaches. When you see one, there may
> be a lot more that you don't see.
Depends on the cause, but yes, that can happen.
> On Mon, 23 Apr 2012 17:23:55 -0400, Yousuf Khan
> <bbb...@spammenot.yahoo.com> put finger to keyboard and composed:
>>The drive also has one bad sector on it (actually uncorrectable sector),
>>but I can't see that causing the entire drive to become nearly unwritable.
> Perhaps bad sectors are like cockroaches. When you see one, there may
> be a lot more that you don't see.
> In any case, AFAICS, bad sectors, or heads with weak read elements,
> would show up during reads more so than writes.
positioning for writes needs to be done more carefully.
Yousuf Khan
Apr 25, 2012, 3:52:32 PM4/25/12
to
On 24/04/2012 11:54 PM, Franc Zabkar wrote:
> On Mon, 23 Apr 2012 17:23:55 -0400, Yousuf Khan
> <bbb...@spammenot.yahoo.com> put finger to keyboard and composed:
>
>> The drive also has one bad sector on it (actually uncorrectable sector),
>> but I can't see that causing the entire drive to become nearly unwritable.
>
> Perhaps bad sectors are like cockroaches. When you see one, there may
> be a lot more that you don't see.
>
> In any case, AFAICS, bad sectors, or heads with weak read elements,
> would show up during reads more so than writes.
>
> - Franc Zabkar
Well, we'll see now, I've initiated HD Sentinel's surface write test. It
> On Mon, 23 Apr 2012 17:23:55 -0400, Yousuf Khan
> <bbb...@spammenot.yahoo.com> put finger to keyboard and composed:
>
>> The drive also has one bad sector on it (actually uncorrectable sector),
>> but I can't see that causing the entire drive to become nearly unwritable.
>
> Perhaps bad sectors are like cockroaches. When you see one, there may
> be a lot more that you don't see.
>
> In any case, AFAICS, bad sectors, or heads with weak read elements,
> would show up during reads more so than writes.
>
> - Franc Zabkar
intially estimated that it would take 80 hours to complete. Now it's
finished exactly 1%, and it is now re-estimating 50 hours left. Can't
say I'm overwhelmed at the sudden burst of speed. :)
Windows performance counters are estimating it is writing at 3500 kB/s,
which is only 3X the speed of a DVD disk. One advantage would be that
unlike other disks which drop off in performance as they reach the end
of the disk, this one may maintain a steady speed from beginning to end,
so the disk time estimate may not change much from here on in.
Yousuf Khan
Yousuf Khan
Apr 26, 2012, 5:45:29 PM4/26/12
to
a full overwrite test on it, using HD Sentinel's surface tester utility.
The surface test found no additional bad sectors on it, but its
performance over the various sections of the drive were fascinating and
may have revealed their own truth. This is a graph of the performance
over various regions of the disk:
http://img403.imageshack.us/img403/8501/20120426wwdcwd5000aavs0.jpg
As you can see from the graph above, there were three regions on this
disk with completely different write characteristics. I'll call them
Slow, Medium, and Fast. It's probably more accurate to call the Medium
and Fast regions as "fast" and "super-fast" instead, because they are
both much faster than the slow region. Once the test entered each of the
regions, it looked like as if it had selected a higher gear. It took the
test 20 hours to write to the first half of the disk, and it only took 4
hours to complete the last half!
In the Slow region, the write speeds were very steady, but slow. The
average was between 3.5-4.5 MB/s (let's say 4.0 MB/s). This region
covers almost exactly the first half of the disk. This is the region
that took the first 20 hours of the write test to complete.
In the Medium region, I was surprised to find that the speeds just
climbed up like a rocket. However, you can't see it very well in the
overall graph here, but I was watching the instantaneous performance
graphs during this time, and I noticed a very distinctive and regular
saw-tooth pattern to the writes, it would go upto full speed (of 50-60
MB/s) for a few seconds, and then immediately drop back down to the same
4.0 MB/s of the Slow region. It would then rise back upto full speed
again, and it would repeat this pattern every 30 seconds or so. The full
speed sections would last for about 3 of the 30 seconds, while the slow
speed sections would last for the rest. So it was more like a
shark-tooth pattern really, rather than a saw-tooth pattern. This region
occupied the disk from the 50% mark to approximately the 70% mark of the
disk.
In the Fast region, watching the instantaneous performance graph, you
would see that it switched from the saw-tooth to a very steady
high-speed. Between the Medium and Fast regions, the remainder of the
write test only took 4 hours!
So, then I set up three partitions to coincide with these three regions,
and I ran the ATTO disk benchmarks in each of the partitions.
Slow: http://imageshack.us/photo/my-images/840/captureattowd500gbaavsp.jpg/
Medium:
http://imageshack.us/photo/my-images/850/captureattowd500gbaavsp.jpg/
Fast: http://imageshack.us/photo/my-images/851/captureattowd500gbaavsp.jpg/
They basically confirm what I saw during the write testing, but you
don't get a sense of the saw-tooth pattern in the medium test.
So what do you think this is a symptom of? I'm thinking that perhaps
there is a problem with the write-head of one of the platters, but not
on the others?
Yousuf Khan
Rod Speed
Apr 26, 2012, 11:52:47 PM4/26/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
> bbbl67 wrote [which was just you too
>> A friend of mine had an WD My Book external case, which contained a
>> 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along the
>> way the My Book's interface failed, it's warranty was expired, and so we
>> took its hard drive out and installed it directly inside his PC
>> case. This was back in mid- to late-2011, that it was transferred from
>> external to internal. It seemed to be fine for the most part in
>> performance, but recently we did some benchmarking and we were shocked to
>> find that although its reading speeds seem normal (around 50-60 MB/s),
>> its write speeds were shockingly low (around 10 MB/s, if even that). What
>> could cause such a weird asymmetry in read vs. write
>> speeds? It didn't seem that slow while it was inside the My Book case.
>> This is one of those WD Caviar Green drives, so I'm wondering if there is
>> some kind of power savings setting affecting it?
> I'm thinking that perhaps there is a problem with the write-head of one of
> the platters, but not on the others?
all the heads, particularly with a drive of that size which was
before things got exotic with larger than 512 byte sectors used.
And while WD doesn't say how many platters it is, its almost
certainly just one given the size of it, and its likely just using
one surface and one head too given that its the second
smallest drive in the series. Presumably the other one is so
bad that it doesn't get used at all. Although the problem
with that theory is that it would be surprising if they get
enough drives with just one surface usable from the factory.
And it doesn't explain why only a quarter of the drive is viable.
I guess the most likely explanation is that it got dropped and
that's what fucked it but I spose it might be fucked by design
in an early attempt at a green design and that's the problem.
Odd that no one else has seen it if its that last tho.
How likely is it that its always had a completely fucked write performance ?
Is he that unlikely to have noticed ?
Rod Speed
Apr 26, 2012, 11:58:39 PM4/26/12
to
Rod Speed <rod.sp...@gmail.com> wrote
I guess one possibility is that whatever fucked the interface,
presumably a power supply failure, fucked the drive electronics
too. But that doesn't explain that weird 1st graph. You wouldn't
expect that fucked electronics would produce that result, that
has to be a mechanical problem of some kind.
That as the era when a mate of mine had 20 WD drives in a row all die.
Dunno what the death symptom was tho.
presumably a power supply failure, fucked the drive electronics
too. But that doesn't explain that weird 1st graph. You wouldn't
expect that fucked electronics would produce that result, that
has to be a mechanical problem of some kind.
That as the era when a mate of mine had 20 WD drives in a row all die.
Dunno what the death symptom was tho.
Yousuf Khan
Apr 27, 2012, 1:25:27 AM4/27/12
to
On 26/04/2012 11:52 PM, Rod Speed wrote:
>> I'm thinking that perhaps there is a problem with the write-head of
>> one of the platters, but not on the others?
>
> Dunno, I would have expected all the partitions to involve
> all the heads, particularly with a drive of that size which was
> before things got exotic with larger than 512 byte sectors used.
>
> And while WD doesn't say how many platters it is, its almost
> certainly just one given the size of it, and its likely just using
> one surface and one head too given that its the second
> smallest drive in the series. Presumably the other one is so
> bad that it doesn't get used at all. Although the problem
> with that theory is that it would be surprising if they get
> enough drives with just one surface usable from the factory.
>
> And it doesn't explain why only a quarter of the drive is viable.
Hard to say without WD telling us that information in its specs.
>> I'm thinking that perhaps there is a problem with the write-head of
>> one of the platters, but not on the others?
>
> Dunno, I would have expected all the partitions to involve
> all the heads, particularly with a drive of that size which was
> before things got exotic with larger than 512 byte sectors used.
>
> And while WD doesn't say how many platters it is, its almost
> certainly just one given the size of it, and its likely just using
> one surface and one head too given that its the second
> smallest drive in the series. Presumably the other one is so
> bad that it doesn't get used at all. Although the problem
> with that theory is that it would be surprising if they get
> enough drives with just one surface usable from the factory.
>
> And it doesn't explain why only a quarter of the drive is viable.
> I guess the most likely explanation is that it got dropped and
> that's what fucked it but I spose it might be fucked by design
> in an early attempt at a green design and that's the problem.
case that would have similar problems, since this thing was an internal
drive for the last little bit.
> Odd that no one else has seen it if its that last tho.
>
> How likely is it that its always had a completely fucked write
> performance ?
>
> Is he that unlikely to have noticed ?
drive for a PVR. So it wasn't even holding PC data at the time, and it
was formatted to a proprietary file system. It was only put into a PC
for the first time when it was put into this case. Since that time it
was reformatted to NTFS, and it was holding several hundred GB's of
data: so it had to have been filled with data in a reasonable amount of
time. As far as I recall, everything about the drive was normal during
the time it was put into the PC. It was running fine for months, but the
current problem was only noticed when I went to help my friend
reorganize his data, and we were going to make this drive part of a
Windows Disk Management spanned volume. We had moved data off of it,
which had operated normally; but when we tried to move data back onto
it, and we noticed this.
Yousuf Khan
Rod Speed
Apr 27, 2012, 3:47:26 AM4/27/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
that it doesn't do anything unusual as far as heads is concerned,
we do see the usual progression across the drive and no evidence
that it switches heads say half way.
>> I guess the most likely explanation is that it got dropped and
>> that's what fucked it but I spose it might be fucked by design
>> in an early attempt at a green design and that's the problem.
> If it got dropped, then there would be other drives in the same system
> case that would have similar problems, since this thing was an internal
> drive for the last little bit.
But not initially. Maybe it got dropped in the external
case and he didn't notice the lousy write performance
or the lousy write performance showed up later etc well
after the drop happened but was still due to the drop.
>> Odd that no one else has seen it if its that last tho.
>> How likely is it that its always had a completely fucked write
>> performance ?
>> Is he that unlikely to have noticed ?
> When it was in the external enclosure, it was being used as an extension
> drive for a PVR. So it wasn't even holding PC data at the time, and it was
> formatted to a proprietary file system. It was only put into a PC for the
> first time when it was put into this case. Since that time it was
> reformatted to NTFS, and it was holding several hundred GB's of data: so
> it had to have been filled with data in a reasonable amount of time.
Guess he might have started that off and then gone to bed etc.
> Rod Speed wrote
>>> I'm thinking that perhaps there is a problem with the write-head of one
>>> of the platters, but not on the others?
>> Dunno, I would have expected all the partitions to involve
>> all the heads, particularly with a drive of that size which was
>> before things got exotic with larger than 512 byte sectors used.
>> And while WD doesn't say how many platters it is, its almost
>> certainly just one given the size of it, and its likely just using
>> one surface and one head too given that its the second
>> smallest drive in the series. Presumably the other one is so
>> bad that it doesn't get used at all. Although the problem
>> with that theory is that it would be surprising if they get
>> enough drives with just one surface usable from the factory.
>> And it doesn't explain why only a quarter of the drive is viable.
> Hard to say without WD telling us that information in its specs.
The read data for the full drive, your first chart, does indicate
>>> I'm thinking that perhaps there is a problem with the write-head of one
>>> of the platters, but not on the others?
>> Dunno, I would have expected all the partitions to involve
>> all the heads, particularly with a drive of that size which was
>> before things got exotic with larger than 512 byte sectors used.
>> And while WD doesn't say how many platters it is, its almost
>> certainly just one given the size of it, and its likely just using
>> one surface and one head too given that its the second
>> smallest drive in the series. Presumably the other one is so
>> bad that it doesn't get used at all. Although the problem
>> with that theory is that it would be surprising if they get
>> enough drives with just one surface usable from the factory.
>> And it doesn't explain why only a quarter of the drive is viable.
> Hard to say without WD telling us that information in its specs.
that it doesn't do anything unusual as far as heads is concerned,
we do see the usual progression across the drive and no evidence
that it switches heads say half way.
>> I guess the most likely explanation is that it got dropped and
>> that's what fucked it but I spose it might be fucked by design
>> in an early attempt at a green design and that's the problem.
> If it got dropped, then there would be other drives in the same system
> case that would have similar problems, since this thing was an internal
> drive for the last little bit.
case and he didn't notice the lousy write performance
or the lousy write performance showed up later etc well
after the drop happened but was still due to the drop.
>> Odd that no one else has seen it if its that last tho.
>> How likely is it that its always had a completely fucked write
>> performance ?
>> Is he that unlikely to have noticed ?
> When it was in the external enclosure, it was being used as an extension
> drive for a PVR. So it wasn't even holding PC data at the time, and it was
> formatted to a proprietary file system. It was only put into a PC for the
> first time when it was put into this case. Since that time it was
> reformatted to NTFS, and it was holding several hundred GB's of data: so
> it had to have been filled with data in a reasonable amount of time.
Yousuf Khan
Apr 27, 2012, 9:25:08 AM4/27/12
to
On 26/04/2012 11:58 PM, Rod Speed wrote:
> I guess one possibility is that whatever fucked the interface,
> presumably a power supply failure, fucked the drive electronics
> too. But that doesn't explain that weird 1st graph. You wouldn't
> expect that fucked electronics would produce that result, that
> has to be a mechanical problem of some kind.
I don't know what fucked up the original external enclosure electronics.
> I guess one possibility is that whatever fucked the interface,
> presumably a power supply failure, fucked the drive electronics
> too. But that doesn't explain that weird 1st graph. You wouldn't
> expect that fucked electronics would produce that result, that
> has to be a mechanical problem of some kind.
It just stopped sending data at some point, and therefore became useless
as a PVR storage device. I doubt that what happened to the internal
drive and the external interface are related as they happened almost a
year apart.
This particular enclosure had all three major interfaces: USB, Firewire,
and eSATA. It was mainly being used through USB on the PVR, and when
that stopped working, we tried testing it on eSATA on the PC, and that
one was also not working (they were all previously working). Didn't
bother with Firewire, since two out of three interfaces were dead,
chances are slim that the 3rd was still working.
I talked to HD Sentinel support about this, and he suggested that the
problem might lie in the total Load/Unload Cycle Count, which is over
600,000. I think this drive is only rated for 300,000. He suggested I
disable spin-down of these drives.
Yousuf Khan
Here's the SMART data:
1,Raw Read Error Rate,51,200,200,OK,0,0,Enabled
3,Spin Up Time,21,201,52,OK,2950,0,Enabled
4,Start/Stop Count,0,96,96,OK (Always passing),4738,0,Enabled
5,Reallocated Sectors Count,140,200,200,OK,0,0,Enabled
7,Seek Error Rate,51,200,200,OK,0,0,Enabled
9,Power On Time Count,0,62,62,OK (Always passing),28244,0,Enabled
10,Spin Retry Count,51,100,100,OK,0,0,Enabled
11,Drive Calibration Retry Count,51,100,100,OK,0,0,Enabled
12,Drive Power Cycle Count,0,97,97,OK (Always passing),3702,0,Enabled
192,Power off Retract Cycle Count,0,196,196,OK (Always
passing),3590,0,Enabled
193,Load/Unload Cycle Count,0,1,1,OK (Always passing),620508,0,Enabled
194,Disk Temperature,0,123,79,OK (Always passing),24,0,Enabled
196,Reallocation Event Count,0,200,200,OK (Always passing),0,0,Enabled
197,Current Pending Sector Count,0,200,200,OK (Always passing),0,0,Enabled
198,Off-Line Uncorrectable Sector Count,0,200,200,OK (Always
passing),1,0,Enabled
199,Ultra ATA CRC Error Count,0,200,200,OK (Always passing),1,0,Enabled
200,Write Error Rate,51,200,199,OK,0,0,Enabled
Yousuf Khan
Apr 27, 2012, 9:45:22 AM4/27/12
to
On 27/04/2012 3:47 AM, Rod Speed wrote:
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
>> Rod Speed wrote
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
>> Rod Speed wrote
>>> How likely is it that its always had a completely fucked write
>>> performance ?
>
>>> Is he that unlikely to have noticed ?
>
>> When it was in the external enclosure, it was being used as an
>> extension drive for a PVR. So it wasn't even holding PC data at the
>> time, and it was formatted to a proprietary file system. It was only
>> put into a PC for the first time when it was put into this case. Since
>> that time it was reformatted to NTFS, and it was holding several
>> hundred GB's of data: so it had to have been filled with data in a
>> reasonable amount of time.
>
> Guess he might have started that off and then gone to bed etc.
Well, as I said, it took 20 hours just to write to the first half of
>>> performance ?
>
>>> Is he that unlikely to have noticed ?
>
>> When it was in the external enclosure, it was being used as an
>> extension drive for a PVR. So it wasn't even holding PC data at the
>> time, and it was formatted to a proprietary file system. It was only
>> put into a PC for the first time when it was put into this case. Since
>> that time it was reformatted to NTFS, and it was holding several
>> hundred GB's of data: so it had to have been filled with data in a
>> reasonable amount of time.
>
> Guess he might have started that off and then gone to bed etc.
this disk during the write test! No matter if you set it to start
copying and then go off to bed, you'll definitely notice this amount of
slow performance. So it is likely this problem didn't exist, when he
originally copied data into this drive.
Also since we see that the problem doesn't exist on the last third of
the disk, if this drive was more than 70% full, then it's likely he
won't have even noticed a problem at all, nor when it originally
started. Everything would appear normal on that section of the disk.
Also since read performance was completely normal, so earlier data that
doesn't get changed very much would also appear safe.
Yousuf Khan
Arno
Apr 27, 2012, 1:35:39 PM4/27/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote:
> On 22/04/2012 6:20 PM, bbbl67 wrote:
>> A friend of mine had an WD My Book external case, which contained a
>> 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
>> the way the My Book's interface failed, it's warranty was expired, and
>> so we took its hard drive out and installed it directly inside his PC
>> case. This was back in mid- to late-2011, that it was transferred from
>> external to internal. It seemed to be fine for the most part in
>> performance, but recently we did some benchmarking and we were shocked
>> to find that although its reading speeds seem normal (around 50-60 MB/
>> s), its write speeds were shockingly low (around 10 MB/s, if even
>> that). What could cause such a weird asymmetry in read vs. write
>> speeds? It didn't seem that slow while it was inside the My Book case.
>>
>> This is one of those WD Caviar Green drives, so I'm wondering if there
>> is some kind of power savings setting affecting it?
>>
>> Yousuf Khan
> Okay, some fascinating results have occurred on this drive, after I did
> a full overwrite test on it, using HD Sentinel's surface tester utility.
> The surface test found no additional bad sectors on it, but its
> performance over the various sections of the drive were fascinating and
> may have revealed their own truth. This is a graph of the performance
> over various regions of the disk:
> http://img403.imageshack.us/img403/8501/20120426wwdcwd5000aavs0.jpg
Very nice. If you take into acount that disks seek from outer
> On 22/04/2012 6:20 PM, bbbl67 wrote:
>> A friend of mine had an WD My Book external case, which contained a
>> 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point along
>> the way the My Book's interface failed, it's warranty was expired, and
>> so we took its hard drive out and installed it directly inside his PC
>> case. This was back in mid- to late-2011, that it was transferred from
>> external to internal. It seemed to be fine for the most part in
>> performance, but recently we did some benchmarking and we were shocked
>> to find that although its reading speeds seem normal (around 50-60 MB/
>> s), its write speeds were shockingly low (around 10 MB/s, if even
>> that). What could cause such a weird asymmetry in read vs. write
>> speeds? It didn't seem that slow while it was inside the My Book case.
>>
>> This is one of those WD Caviar Green drives, so I'm wondering if there
>> is some kind of power savings setting affecting it?
>>
>> Yousuf Khan
> Okay, some fascinating results have occurred on this drive, after I did
> a full overwrite test on it, using HD Sentinel's surface tester utility.
> The surface test found no additional bad sectors on it, but its
> performance over the various sections of the drive were fascinating and
> may have revealed their own truth. This is a graph of the performance
> over various regions of the disk:
> http://img403.imageshack.us/img403/8501/20120426wwdcwd5000aavs0.jpg
edhe to center, and that virbration/positioning is more problematic
on the outside, I think my suspicion of seek-errors for
the more sensitive write-seeks is right on.
Arno
Apr 27, 2012, 1:40:58 PM4/27/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote:
> On 26/04/2012 11:58 PM, Rod Speed wrote:
>> I guess one possibility is that whatever fucked the interface,
>> presumably a power supply failure, fucked the drive electronics
>> too. But that doesn't explain that weird 1st graph. You wouldn't
>> expect that fucked electronics would produce that result, that
>> has to be a mechanical problem of some kind.
> I don't know what fucked up the original external enclosure electronics.
> It just stopped sending data at some point, and therefore became useless
> as a PVR storage device. I doubt that what happened to the internal
> drive and the external interface are related as they happened almost a
> year apart.
> This particular enclosure had all three major interfaces: USB, Firewire,
> and eSATA. It was mainly being used through USB on the PVR, and when
> that stopped working, we tried testing it on eSATA on the PC, and that
> one was also not working (they were all previously working). Didn't
> bother with Firewire, since two out of three interfaces were dead,
> chances are slim that the 3rd was still working.
> I talked to HD Sentinel support about this, and he suggested that the
> problem might lie in the total Load/Unload Cycle Count, which is over
> 600,000. I think this drive is only rated for 300,000. He suggested I
> disable spin-down of these drives.
I agree there. Might even be as low as 50'000 for a 3.5" drive.
> On 26/04/2012 11:58 PM, Rod Speed wrote:
>> I guess one possibility is that whatever fucked the interface,
>> presumably a power supply failure, fucked the drive electronics
>> too. But that doesn't explain that weird 1st graph. You wouldn't
>> expect that fucked electronics would produce that result, that
>> has to be a mechanical problem of some kind.
> I don't know what fucked up the original external enclosure electronics.
> It just stopped sending data at some point, and therefore became useless
> as a PVR storage device. I doubt that what happened to the internal
> drive and the external interface are related as they happened almost a
> year apart.
> This particular enclosure had all three major interfaces: USB, Firewire,
> and eSATA. It was mainly being used through USB on the PVR, and when
> that stopped working, we tried testing it on eSATA on the PC, and that
> one was also not working (they were all previously working). Didn't
> bother with Firewire, since two out of three interfaces were dead,
> chances are slim that the 3rd was still working.
> I talked to HD Sentinel support about this, and he suggested that the
> problem might lie in the total Load/Unload Cycle Count, which is over
> 600,000. I think this drive is only rated for 300,000. He suggested I
> disable spin-down of these drives.
I had some disks trying to do the same to themselves and
caught them in time. One was up yo 800'000 load cycles,
but these are 2.5" drives that can (roughly) withstand
10 times as many load cycles.
Well, seems this is another suicide via power-management.
Searching for "wdidle3" should bring up the last few
threads dealing with this, although I think you posted in
some of them.
As to the drive, while it does not seem dead, it seems
basically unuasable.
Yousuf Khan
Apr 27, 2012, 6:06:09 PM4/27/12
to
On 27/04/2012 1:40 PM, Arno wrote:
> I agree there. Might even be as low as 50'000 for a 3.5" drive.
> I had some disks trying to do the same to themselves and
> caught them in time. One was up yo 800'000 load cycles,
> but these are 2.5" drives that can (roughly) withstand
> 10 times as many load cycles.
After learning about this, I looked at one my own drives and found that
> I agree there. Might even be as low as 50'000 for a 3.5" drive.
> I had some disks trying to do the same to themselves and
> caught them in time. One was up yo 800'000 load cycles,
> but these are 2.5" drives that can (roughly) withstand
> 10 times as many load cycles.
it was already upto 200,000 cycles out of the 300,000 recommendation!
I've now enabled the anti-power management option to stop the
deterioration right there in its tracks.
I have no idea how this drive got upto to so many unload cycles in such
a short amount of time, except that this drive used to be inside an
external USB enclosure too before I bought a bigger system case and was
able to bring it inside. I'm thinking that the USB API might enable some
power management by default, without even asking you.
Some drive manufacturers don't even monitor the load/unload cycles in
SMART. Either they think their drives are immune to it, or there is a
false sense of security.
> Well, seems this is another suicide via power-management.
> Searching for "wdidle3" should bring up the last few
> threads dealing with this, although I think you posted in
> some of them.
> As to the drive, while it does not seem dead, it seems
> basically unuasable.
hardware that we all dream about happening to us but rarely ever
happens: the hardware failure where the drive is telling you that it's
about to die, and still gives you the chance to recover your old data
before it goes. Overall, I'd love to have had a warning like this before
I drive goes.
Yousuf Khan
Rod Speed
Apr 27, 2012, 10:23:09 PM4/27/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote in message
that suffer two completely different very serious faults.
> I doubt that what happened to the internal drive and the external
> interface are related as they happened almost a year apart.
You can get delayed results like that, particularly when the power
supply seriously over voltages the system for a short time.
Harder to explain the weird symptom that the write speed
obviously varys with where the head is on the platter that
way tho and that only affecting writes, not reads.
If we ever do work out what the fault is due to, bet we
will kick ourselves for not thinking of that earlier tho.
> This particular enclosure had all three major interfaces: USB, Firewire,
> and eSATA. It was mainly being used through USB on the PVR, and when that
> stopped working, we tried testing it on eSATA on the PC, and that one was
> also not working (they were all previously working). Didn't bother with
> Firewire, since two out of three interfaces were dead, chances are slim
> that the 3rd was still working.
> I talked to HD Sentinel support about this, and he suggested that the
> problem might lie in the total Load/Unload Cycle Count, which is over
> 600,000. I think this drive is only rated for 300,000.
Cant see how that would produce that very unusual symptom
of the write speed so dramatically affected by the location of
the head on the platter, and not the read speed.
> He suggested I disable spin-down of these drives.
They certainly are notorious for unloading much too frequently.
Havent see anyone report that weird write speed result with them tho.
> Here's the SMART data:
Whats that from, HD Sentinel presumably ?
> 1,Raw Read Error Rate,51,200,200,OK,0,0,Enabled
> 3,Spin Up Time,21,201,52,OK,2950,0,Enabled
> 4,Start/Stop Count,0,96,96,OK (Always passing),4738,0,Enabled
> 5,Reallocated Sectors Count,140,200,200,OK,0,0,Enabled
> 7,Seek Error Rate,51,200,200,OK,0,0,Enabled
> 9,Power On Time Count,0,62,62,OK (Always passing),28244,0,Enabled
> 10,Spin Retry Count,51,100,100,OK,0,0,Enabled
> 11,Drive Calibration Retry Count,51,100,100,OK,0,0,Enabled
> 12,Drive Power Cycle Count,0,97,97,OK (Always passing),3702,0,Enabled
> 192,Power off Retract Cycle Count,0,196,196,OK (Always
> passing),3590,0,Enabled
> 193,Load/Unload Cycle Count,0,1,1,OK (Always passing),620508,0,Enabled
> 194,Disk Temperature,0,123,79,OK (Always passing),24,0,Enabled
> 196,Reallocation Event Count,0,200,200,OK (Always passing),0,0,Enabled
> 197,Current Pending Sector Count,0,200,200,OK (Always passing),0,0,Enabled
> 198,Off-Line Uncorrectable Sector Count,0,200,200,OK (Always
> passing),1,0,Enabled
> 199,Ultra ATA CRC Error Count,0,200,200,OK (Always passing),1,0,Enabled
> 200,Write Error Rate,51,200,199,OK,0,0,Enabled
Looks fine except for the load/unload count.
> Rod Speed wrote
>> I guess one possibility is that whatever fucked the interface,
>> presumably a power supply failure, fucked the drive electronics
>> too. But that doesn't explain that weird 1st graph. You wouldn't
>> expect that fucked electronics would produce that result, that
>> has to be a mechanical problem of some kind.
> I don't know what fucked up the original external enclosure electronics.
> It just stopped sending data at some point, and therefore became useless
> as a PVR storage device.
But you don't see too many relatively simple devices like
>> I guess one possibility is that whatever fucked the interface,
>> presumably a power supply failure, fucked the drive electronics
>> too. But that doesn't explain that weird 1st graph. You wouldn't
>> expect that fucked electronics would produce that result, that
>> has to be a mechanical problem of some kind.
> I don't know what fucked up the original external enclosure electronics.
> It just stopped sending data at some point, and therefore became useless
> as a PVR storage device.
that suffer two completely different very serious faults.
> I doubt that what happened to the internal drive and the external
> interface are related as they happened almost a year apart.
supply seriously over voltages the system for a short time.
Harder to explain the weird symptom that the write speed
obviously varys with where the head is on the platter that
way tho and that only affecting writes, not reads.
If we ever do work out what the fault is due to, bet we
will kick ourselves for not thinking of that earlier tho.
> This particular enclosure had all three major interfaces: USB, Firewire,
> and eSATA. It was mainly being used through USB on the PVR, and when that
> stopped working, we tried testing it on eSATA on the PC, and that one was
> also not working (they were all previously working). Didn't bother with
> Firewire, since two out of three interfaces were dead, chances are slim
> that the 3rd was still working.
> I talked to HD Sentinel support about this, and he suggested that the
> problem might lie in the total Load/Unload Cycle Count, which is over
> 600,000. I think this drive is only rated for 300,000.
of the write speed so dramatically affected by the location of
the head on the platter, and not the read speed.
> He suggested I disable spin-down of these drives.
Havent see anyone report that weird write speed result with them tho.
> Here's the SMART data:
> 1,Raw Read Error Rate,51,200,200,OK,0,0,Enabled
> 3,Spin Up Time,21,201,52,OK,2950,0,Enabled
> 4,Start/Stop Count,0,96,96,OK (Always passing),4738,0,Enabled
> 5,Reallocated Sectors Count,140,200,200,OK,0,0,Enabled
> 7,Seek Error Rate,51,200,200,OK,0,0,Enabled
> 9,Power On Time Count,0,62,62,OK (Always passing),28244,0,Enabled
> 10,Spin Retry Count,51,100,100,OK,0,0,Enabled
> 11,Drive Calibration Retry Count,51,100,100,OK,0,0,Enabled
> 12,Drive Power Cycle Count,0,97,97,OK (Always passing),3702,0,Enabled
> 192,Power off Retract Cycle Count,0,196,196,OK (Always
> passing),3590,0,Enabled
> 193,Load/Unload Cycle Count,0,1,1,OK (Always passing),620508,0,Enabled
> 194,Disk Temperature,0,123,79,OK (Always passing),24,0,Enabled
> 196,Reallocation Event Count,0,200,200,OK (Always passing),0,0,Enabled
> 197,Current Pending Sector Count,0,200,200,OK (Always passing),0,0,Enabled
> 198,Off-Line Uncorrectable Sector Count,0,200,200,OK (Always
> passing),1,0,Enabled
> 199,Ultra ATA CRC Error Count,0,200,200,OK (Always passing),1,0,Enabled
> 200,Write Error Rate,51,200,199,OK,0,0,Enabled
Rod Speed
Apr 27, 2012, 10:28:28 PM4/27/12
to
Arno <m...@privacy.net> wrote
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
And why it doesn’t affect the reads either.
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
>> bbbl67 wrote
>>> A friend of mine had an WD My Book external case, which contained a
>>> 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point
>>> along the way the My Book's interface failed, it's warranty was expired,
>>> and so we took its hard drive out and installed it directly inside his
>>> PC
>>> case. This was back in mid- to late-2011, that it was transferred from
>>> external to internal. It seemed to be fine for the most part in
>>> performance,
>>> but recently we did some benchmarking and we were shocked
>>> to find that although its reading speeds seem normal (around 50-60 MB/
>>> s), its write speeds were shockingly low (around 10 MB/s, if even
>>> that). What could cause such a weird asymmetry in read vs. write
>>> speeds? It didn't seem that slow while it was inside the My Book case.
>>> This is one of those WD Caviar Green drives, so I'm wondering
>>> if there is some kind of power savings setting affecting it?
>>> A friend of mine had an WD My Book external case, which contained a
>>> 500GB WDC WD5000AAVS-00ZTB0 hard drive inside it. At some point
>>> along the way the My Book's interface failed, it's warranty was expired,
>>> and so we took its hard drive out and installed it directly inside his
>>> PC
>>> case. This was back in mid- to late-2011, that it was transferred from
>>> external to internal. It seemed to be fine for the most part in
>>> performance,
>>> but recently we did some benchmarking and we were shocked
>>> to find that although its reading speeds seem normal (around 50-60 MB/
>>> s), its write speeds were shockingly low (around 10 MB/s, if even
>>> that). What could cause such a weird asymmetry in read vs. write
>>> speeds? It didn't seem that slow while it was inside the My Book case.
>>> This is one of those WD Caviar Green drives, so I'm wondering
>>> if there is some kind of power savings setting affecting it?
>> Okay, some fascinating results have occurred on this drive, after I did
>> a full overwrite test on it, using HD Sentinel's surface tester utility.
>> The surface test found no additional bad sectors on it, but its
>> performance over the various sections of the drive were fascinating and
>> may have revealed their own truth. This is a graph of the performance
>> over various regions of the disk:
>> http://img403.imageshack.us/img403/8501/20120426wwdcwd5000aavs0.jpg
> Very nice. If you take into acount that disks seek from outer
> edhe to center, and that virbration/positioning is more
> problematic on the outside, I think my suspicion of seek-
> errors for the more sensitive write-seeks is right on.
Doesn’t explain the sudden transition from ultra slow to normal tho.
>> a full overwrite test on it, using HD Sentinel's surface tester utility.
>> The surface test found no additional bad sectors on it, but its
>> performance over the various sections of the drive were fascinating and
>> may have revealed their own truth. This is a graph of the performance
>> over various regions of the disk:
>> http://img403.imageshack.us/img403/8501/20120426wwdcwd5000aavs0.jpg
> Very nice. If you take into acount that disks seek from outer
> edhe to center, and that virbration/positioning is more
> problematic on the outside, I think my suspicion of seek-
> errors for the more sensitive write-seeks is right on.
And why it doesn’t affect the reads either.
Rod Speed
Apr 27, 2012, 10:37:02 PM4/27/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
> except that this drive used to be inside an external USB enclosure too
> before I bought a bigger system case and was able to bring it inside. I'm
> thinking that the USB API might enable some power management by default,
> without even asking you.
Or it might be another WD drive.
> Some drive manufacturers don't even monitor the load/unload cycles in
> SMART. Either they think their drives are immune to it,
More likely they just don't distinguish all the similar
events and lump some of them together more.
> or there is a false sense of security.
Unlikely.
>> Well, seems this is another suicide via power-management.
>> Searching for "wdidle3" should bring up the last few threads dealing with
>> this, although I think you posted in some of them.
> If I did participate in them, I don't remember them anymore. :)
Don't recall you did, but they did get quite a bit of traffic.
>> As to the drive, while it does not seem dead, it seems basically
>> unuasable.
> Well, I think this is one of those very rare types of failures of hardware
> that we all dream about happening to us but rarely ever happens: the
> hardware failure where the drive is telling you that it's about to die,
> and still gives you the chance to recover your old data before it goes.
> Overall, I'd love to have had a warning like this before I drive goes.
Plenty do. Just had one Toshiba in a Toshiba laptop that did that.
And did it with a very naïve user so that user was sure there was a problem
too.
If even advised him to backup, and he did that, and it
had just 2 weeks to go till the warranty ran out too.
> Arno wrote
>> I agree there. Might even be as low as 50'000 for a 3.5" drive.
>> I had some disks trying to do the same to themselves and
>> caught them in time. One was up yo 800'000 load cycles,
>> but these are 2.5" drives that can (roughly) withstand
>> 10 times as many load cycles.
> After learning about this, I looked at one my own drives and found that it
> was already upto 200,000 cycles out of the 300,000 recommendation! I've
> now enabled the anti-power management option to stop the deterioration
> right there in its tracks.
> I have no idea how this drive got upto to so many unload cycles in such a
> short amount of time,
Those WD drives are utterly notorious for an insane unload timeout.
>> I agree there. Might even be as low as 50'000 for a 3.5" drive.
>> I had some disks trying to do the same to themselves and
>> caught them in time. One was up yo 800'000 load cycles,
>> but these are 2.5" drives that can (roughly) withstand
>> 10 times as many load cycles.
> After learning about this, I looked at one my own drives and found that it
> was already upto 200,000 cycles out of the 300,000 recommendation! I've
> now enabled the anti-power management option to stop the deterioration
> right there in its tracks.
> I have no idea how this drive got upto to so many unload cycles in such a
> short amount of time,
> except that this drive used to be inside an external USB enclosure too
> before I bought a bigger system case and was able to bring it inside. I'm
> thinking that the USB API might enable some power management by default,
> without even asking you.
> Some drive manufacturers don't even monitor the load/unload cycles in
> SMART. Either they think their drives are immune to it,
events and lump some of them together more.
> or there is a false sense of security.
>> Well, seems this is another suicide via power-management.
>> Searching for "wdidle3" should bring up the last few threads dealing with
>> this, although I think you posted in some of them.
> If I did participate in them, I don't remember them anymore. :)
>> As to the drive, while it does not seem dead, it seems basically
>> unuasable.
> Well, I think this is one of those very rare types of failures of hardware
> that we all dream about happening to us but rarely ever happens: the
> hardware failure where the drive is telling you that it's about to die,
> and still gives you the chance to recover your old data before it goes.
> Overall, I'd love to have had a warning like this before I drive goes.
And did it with a very naïve user so that user was sure there was a problem
too.
If even advised him to backup, and he did that, and it
had just 2 weeks to go till the warranty ran out too.
Rod Speed
Apr 28, 2012, 2:13:57 AM4/28/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
http://www.google.com.au/search?q=wd+very+slow+writes
produces some very interesting hits.
Looks like WD might well have a problem.
http://www.google.com.au/search?q=wd+very+slow+writes
produces some very interesting hits.
Looks like WD might well have a problem.
Yousuf Khan
Apr 28, 2012, 2:36:12 AM4/28/12
to
On 27/04/2012 10:37 PM, Rod Speed wrote:
>> Some drive manufacturers don't even monitor the load/unload cycles in
>> SMART. Either they think their drives are immune to it,
>
> More likely they just don't distinguish all the similar
> events and lump some of them together more.
>
>> or there is a false sense of security.
>
> Unlikely.
>
>>> Well, seems this is another suicide via power-management.
>>> Searching for "wdidle3" should bring up the last few threads dealing
>>> with this, although I think you posted in some of them.
>
>> If I did participate in them, I don't remember them anymore. :)
>
> Don't recall you did, but they did get quite a bit of traffic.
Well, I found some of the old threads here (Google Groups):
>> Some drive manufacturers don't even monitor the load/unload cycles in
>> SMART. Either they think their drives are immune to it,
>
> More likely they just don't distinguish all the similar
> events and lump some of them together more.
>
>> or there is a false sense of security.
>
> Unlikely.
>
>>> Well, seems this is another suicide via power-management.
>>> Searching for "wdidle3" should bring up the last few threads dealing
>>> with this, although I think you posted in some of them.
>
>> If I did participate in them, I don't remember them anymore. :)
>
> Don't recall you did, but they did get quite a bit of traffic.
http://is.gd/CpVL7N
http://is.gd/Qre36O
http://is.gd/a0DUvU
I do recall seeing some of these old threads with passing interest, but
at that time it did not interest me as I wasn't aware that they affected
me too. I can now see that they may have been the very same issues I was
dealing with myself. HD Sentinel actually implemented a resident program
just to keep the hard disks from being put to rest, so it must be a
well-known problem.
Yousuf Khan
Yousuf Khan
Apr 28, 2012, 2:39:23 AM4/28/12
to
but couldn't find anything like this. I suppose it helps if other people
are trying the searches too so there is multiple sources perspectives.
Yousuf Khan
Rod Speed
Apr 28, 2012, 3:41:29 AM4/28/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
> HD Sentinel actually implemented a resident program
> just to keep the hard disks from being put to rest, so it
> must be a well-known problem.
It isnt actually. Its only the WDs that get that carried away.
> Rod Speed wrote
>>> Some drive manufacturers don't even monitor the load/unload
>>> cycles in SMART. Either they think their drives are immune to it,
>> More likely they just don't distinguish all the similar
>> events and lump some of them together more.
>>> or there is a false sense of security.
>> Unlikely.
>>>> Well, seems this is another suicide via power-management.
>>>> Searching for "wdidle3" should bring up the last few threads
>>>> dealing with this, although I think you posted in some of them.
>>> If I did participate in them, I don't remember them anymore. :)
>> Don't recall you did, but they did get quite a bit of traffic.
> Well, I found some of the old threads here (Google Groups):
> http://is.gd/CpVL7N
> http://is.gd/Qre36O
> http://is.gd/a0DUvU
> I do recall seeing some of these old threads with passing interest, but
> at that time it did not interest me as I wasn't aware that they affected
> me too. I can now see that they may have been the very same issues
> I was dealing with myself.
Yes.
>>> Some drive manufacturers don't even monitor the load/unload
>>> cycles in SMART. Either they think their drives are immune to it,
>> More likely they just don't distinguish all the similar
>> events and lump some of them together more.
>>> or there is a false sense of security.
>> Unlikely.
>>>> Well, seems this is another suicide via power-management.
>>>> Searching for "wdidle3" should bring up the last few threads
>>>> dealing with this, although I think you posted in some of them.
>>> If I did participate in them, I don't remember them anymore. :)
>> Don't recall you did, but they did get quite a bit of traffic.
> Well, I found some of the old threads here (Google Groups):
> http://is.gd/CpVL7N
> http://is.gd/Qre36O
> http://is.gd/a0DUvU
> I do recall seeing some of these old threads with passing interest, but
> at that time it did not interest me as I wasn't aware that they affected
> me too. I can now see that they may have been the very same issues
> I was dealing with myself.
> HD Sentinel actually implemented a resident program
> just to keep the hard disks from being put to rest, so it
> must be a well-known problem.
Rod Speed
Apr 28, 2012, 3:43:35 AM4/28/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
Yeah, its still a problem with searches that
don't have any particularly unique word to use.
I quite often find that I cant find something that
I know for sure is in groups.google somewhere.
don't have any particularly unique word to use.
I quite often find that I cant find something that
I know for sure is in groups.google somewhere.
Yousuf Khan
Apr 28, 2012, 4:12:05 AM4/28/12
to
On 27/04/2012 10:23 PM, Rod Speed wrote:
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote in message
>> Rod Speed wrote
>
>>> I guess one possibility is that whatever fucked the interface,
>>> presumably a power supply failure, fucked the drive electronics
>>> too. But that doesn't explain that weird 1st graph. You wouldn't
>>> expect that fucked electronics would produce that result, that
>>> has to be a mechanical problem of some kind.
>
>> I don't know what fucked up the original external enclosure
>> electronics. It just stopped sending data at some point, and therefore
>> became useless as a PVR storage device.
>
> But you don't see too many relatively simple devices like
> that suffer two completely different very serious faults.
Not so unusual when you run the device for 24/7 for months on end. When
> Yousuf Khan <bbb...@spammenot.yahoo.com> wrote in message
>> Rod Speed wrote
>
>>> I guess one possibility is that whatever fucked the interface,
>>> presumably a power supply failure, fucked the drive electronics
>>> too. But that doesn't explain that weird 1st graph. You wouldn't
>>> expect that fucked electronics would produce that result, that
>>> has to be a mechanical problem of some kind.
>
>> I don't know what fucked up the original external enclosure
>> electronics. It just stopped sending data at some point, and therefore
>> became useless as a PVR storage device.
>
> But you don't see too many relatively simple devices like
> that suffer two completely different very serious faults.
it was being run as a PVR drive, it was never shut-off, even if the PVR
itself was off. The drive had to always be ready to record something, as
soon as the PVR woke up, so the drive itself could never sleep.
>> I doubt that what happened to the internal drive and the external
>> interface are related as they happened almost a year apart.
>
> You can get delayed results like that, particularly when the power
> supply seriously over voltages the system for a short time.
the time it was in that enclosure, but I don't agree that there was ever
any single event that was responsible for both failures. The damage to
the internal drive was likely caused by the excessive load/unload cycles
over time while it was inside the enclosure, which is basically a
mechanical failure. What caused the enclosure's interface electronics to
die was something else entirely, details not fully determined yet, but
this one could only be electronic/electrical in nature.
> Harder to explain the weird symptom that the write speed
> obviously varys with where the head is on the platter that
> way tho and that only affecting writes, not reads.
>
> If we ever do work out what the fault is due to, bet we
> will kick ourselves for not thinking of that earlier tho.
failures, necessarily. I'll explain why below.
>> This particular enclosure had all three major interfaces: USB,
>> Firewire, and eSATA. It was mainly being used through USB on the PVR,
>> and when that stopped working, we tried testing it on eSATA on the PC,
>> and that one was also not working (they were all previously working).
>> Didn't bother with Firewire, since two out of three interfaces were
>> dead, chances are slim that the 3rd was still working.
(Google Groups):
http://is.gd/tkqeKJ
Back then, the drive was still inside its My Book enclosure, and I was
having some kind of problem with reading SMART data out of it through
its eSATA interface. It was during this thread that I was first
introduced to HD Sentinel.
The My Book contained a bridging chipset that acted as the interface
from the hard disk to the computer, offering USB, Firewire, and eSATA.
What we didn't know back then was that the chipset was manufactured by a
company called Oxford Semiconductor. This chipset contained its own ARM
processor. So it was an intelligent interface controller. If the ARM
chip failed somehow, then it would mean the interface is dead, but not
necessarily the disk inside.
http://en.wikipedia.org/wiki/Western_Digital_My_Book#Internals
>> I talked to HD Sentinel support about this, and he suggested that the
>> problem might lie in the total Load/Unload Cycle Count, which is over
>> 600,000. I think this drive is only rated for 300,000.
>
> Cant see how that would produce that very unusual symptom
> of the write speed so dramatically affected by the location of
> the head on the platter, and not the read speed.
might have damaged the head parking area of that drive. This might have
resulted in microscopic dust particles covering the platter which made
it harder to re-magnetize the platter near the parking area. Since the
parking area is near the front of the platters, this is the area that
was first affected. He suggested that this dust is just going to keep
creeping towards the back of the drive, until the entire surface is
unusable. The fact that there are some areas which are alternately fast
and slow (i.e. the "Slow", "Medium" and "Fast" sections of the drive) is
an indication that this backward creep is already happening.
It's a theory, don't know if it's the only possible theory.
>> He suggested I disable spin-down of these drives.
>
> They certainly are notorious for unloading much too frequently.
>
> Havent see anyone report that weird write speed result with them tho.
before on this newsgroup, I would like to know how other people
determined that this was a problem? I think Arno was one of the first to
express concern over this load/unload issue, but I don't quite know what
led him to believe that it was a problem? I realize we're getting into
historical issues here.
Yousuf Khan
Rod Speed
Apr 28, 2012, 6:05:15 AM4/28/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
work.
> When it was being run as a PVR drive, it was never shut-off,
My PVR isnt either except for a hardware upgrade.
> even if the PVR itself was off.
I don't ever turn mine off except for a hardware upgrade.
> The drive had to always be ready to record something, as soon as the PVR
> woke up, so the drive itself could never sleep.
I choose to not let it sleep even tho the PVR is
quite capable of starting it up when it needs it.
>>> I doubt that what happened to the internal drive and the external
>>> interface are related as they happened almost a year apart.
>> You can get delayed results like that, particularly when the power
>> supply seriously over voltages the system for a short time.
> I don't disagree that both types of damage might have been done during the
> time it was in that enclosure, but I don't agree that there was ever any
> single event that was responsible for both failures.
You don't know that with the power supply spiking it.
> The damage to the internal drive was likely caused by the excessive
> load/unload cycles over time
Don't believe that. There is no reason that should
produce that effect on JUST writes and not on reads.
> while it was inside the enclosure,
You don't know that it wouldn't have done that when
an internal drive too.
> which is basically a mechanical failure.
Have fun explaining how it can produce that very
unusual symptom you are seeing, extremely slow
writes ONLY when the head is in part of the platter.
> What caused the enclosure's interface electronics to die was something
> else entirely,
You don't know that either.
> details not fully determined yet, but this one could only be
> electronic/electrical in nature.
You don't know that either. A drop can see a failure there
just with a bad joint or a connector coming off internally etc.
>> Harder to explain the weird symptom that the write speed
>> obviously varys with where the head is on the platter that
>> way tho and that only affecting writes, not reads.
>> If we ever do work out what the fault is due to, bet we
>> will kick ourselves for not thinking of that earlier tho.
> I don't think so.
I've never seen one that wasn't.
I have seen some where no one bothered to
work out why the symptom was seen tho.
> I don't think a common explanation is needed for both failures,
> necessarily. I'll explain why below.
Didn't help.
>>> This particular enclosure had all three major interfaces: USB,
>>> Firewire, and eSATA. It was mainly being used through USB on the PVR,
>>> and when that stopped working, we tried testing it on eSATA on the PC,
>>> and that one was also not working (they were all previously working).
>>> Didn't bother with Firewire, since two out of three interfaces were
>>> dead, chances are slim that the 3rd was still working.
> BTW, I had written about this drive's history before on this newsgroup
> (Google Groups):
> http://is.gd/tkqeKJ
> Back then, the drive was still inside its My Book enclosure, and I was
> having some kind of problem with reading SMART data out of it through its
> eSATA interface.
That isnt necessarily related to either fault.
> It was during this thread that I was first introduced to HD Sentinel.
> The My Book contained a bridging chipset that acted as the interface from
> the hard disk to the computer, offering USB, Firewire, and eSATA. What we
> didn't know back then was that the chipset was manufactured by a company
> called Oxford Semiconductor. This chipset contained its own ARM processor.
> So it was an intelligent interface controller. If the ARM chip failed
> somehow, then it would mean the interface is dead, but not necessarily the
> disk inside.
Is there any evidence that the ARM chip has actually failed ?
Even if it had, you don't know that that wasn't because the
power supply had spiked it and that it took some time for
the effect of the spike to show up with the drive itself.
> http://en.wikipedia.org/wiki/Western_Digital_My_Book#Internals
>>> I talked to HD Sentinel support about this, and he suggested that the
>>> problem might lie in the total Load/Unload Cycle Count, which is over
>>> 600,000. I think this drive is only rated for 300,000.
>> Cant see how that would produce that very unusual symptom
>> of the write speed so dramatically affected by the location of
>> the head on the platter, and not the read speed.
> The HD Sentinel tech believes that the excessive load/unload cycles might
> have damaged the head parking area of that drive.
Very unlikely indeed. And doesn't explain why writes
are fine with the heads over half the platter either.
> This might have resulted in microscopic dust particles covering the
> platter
Yes. But that would see head crashes, not extremely
poor write perfomance over just half of the platter,
and have no effect on reads at all.
> which made it harder to re-magnetize the platter near the parking area.
That 'explanation' is completely off with the fucking fairys.
There is no way that that would affect JUST half the platter,
and that boundary never changing, or the very sharp boundary
been extremely slow writes and normal write performance and
have no effect whatever on the read speed.
> Since the parking area is near the front of the platters, this is the area
> that was first affected.
Its never going to affect just half the platter with such
a striking boundary between the good half and the
bad half and not affect the read performance at all.
> He suggested that this dust is just going to keep creeping towards the
> back of the drive, until the entire surface is unusable.
Have fun explaining why no head crashes
have been seen and just ONE bad sector.
Bet the boundary that's so striking on your
first chart doesn't move over time either.
> The fact that there are some areas which are alternately fast and slow
> (i.e. the "Slow", "Medium" and "Fast" sections of the drive)
That isnt actually the case. Your first chart does in fact show
that the last half of the drive is fine. The steps you do see after
that are just the areas where the sectors per track changes.
You'll find that with a brand now drive.
> is an indication that this backward creep is already happening.
Fraid not.
> It's a theory,
Which has holes in it you can drive an full aircraft carrier battle group
thru.
> don't know if it's the only possible theory.
It's a complete dud in fact.
>>> He suggested I disable spin-down of these drives.
>> They certainly are notorious for unloading much too frequently.
>> Havent see anyone report that weird write speed result with them tho.
> Now that I know that this Western Digital load/unload issue has come up
> before on this newsgroup, I would like to know how other people determined
> that this was a problem?
Basically by looking at the load/unload value in the SMART data.
> I think Arno was one of the first to express concern over this load/unload
> issue,
Yes.
> but I don't quite know what led him to believe that it was a problem?
Basically by looking at the load/unload value in the SMART data.
> I realize we're getting into historical issues here.
But the detail is in groups.google
>>> Rod Speed wrote
>>>> I guess one possibility is that whatever fucked the interface,
>>>> presumably a power supply failure, fucked the drive electronics
>>>> too. But that doesn't explain that weird 1st graph. You wouldn't
>>>> expect that fucked electronics would produce that result, that
>>>> has to be a mechanical problem of some kind.
>>> I don't know what fucked up the original external enclosure
>>> electronics. It just stopped sending data at some point, and therefore
>>> became useless as a PVR storage device.
>> But you don't see too many relatively simple devices like
>> that suffer two completely different very serious faults.
> Not so unusual when you run the device for 24/7 for months on end.
Very unusual, actually. I do that with almost everything, at home and at
>>>> I guess one possibility is that whatever fucked the interface,
>>>> presumably a power supply failure, fucked the drive electronics
>>>> too. But that doesn't explain that weird 1st graph. You wouldn't
>>>> expect that fucked electronics would produce that result, that
>>>> has to be a mechanical problem of some kind.
>>> I don't know what fucked up the original external enclosure
>>> electronics. It just stopped sending data at some point, and therefore
>>> became useless as a PVR storage device.
>> But you don't see too many relatively simple devices like
>> that suffer two completely different very serious faults.
> Not so unusual when you run the device for 24/7 for months on end.
work.
> When it was being run as a PVR drive, it was never shut-off,
> even if the PVR itself was off.
> The drive had to always be ready to record something, as soon as the PVR
> woke up, so the drive itself could never sleep.
quite capable of starting it up when it needs it.
>>> I doubt that what happened to the internal drive and the external
>>> interface are related as they happened almost a year apart.
>> You can get delayed results like that, particularly when the power
>> supply seriously over voltages the system for a short time.
> I don't disagree that both types of damage might have been done during the
> time it was in that enclosure, but I don't agree that there was ever any
> single event that was responsible for both failures.
> The damage to the internal drive was likely caused by the excessive
> load/unload cycles over time
produce that effect on JUST writes and not on reads.
> while it was inside the enclosure,
an internal drive too.
> which is basically a mechanical failure.
unusual symptom you are seeing, extremely slow
writes ONLY when the head is in part of the platter.
> What caused the enclosure's interface electronics to die was something
> else entirely,
> details not fully determined yet, but this one could only be
> electronic/electrical in nature.
just with a bad joint or a connector coming off internally etc.
>> Harder to explain the weird symptom that the write speed
>> obviously varys with where the head is on the platter that
>> way tho and that only affecting writes, not reads.
>> If we ever do work out what the fault is due to, bet we
>> will kick ourselves for not thinking of that earlier tho.
> I don't think so.
I have seen some where no one bothered to
work out why the symptom was seen tho.
> I don't think a common explanation is needed for both failures,
> necessarily. I'll explain why below.
>>> This particular enclosure had all three major interfaces: USB,
>>> Firewire, and eSATA. It was mainly being used through USB on the PVR,
>>> and when that stopped working, we tried testing it on eSATA on the PC,
>>> and that one was also not working (they were all previously working).
>>> Didn't bother with Firewire, since two out of three interfaces were
>>> dead, chances are slim that the 3rd was still working.
> BTW, I had written about this drive's history before on this newsgroup
> (Google Groups):
> http://is.gd/tkqeKJ
> Back then, the drive was still inside its My Book enclosure, and I was
> having some kind of problem with reading SMART data out of it through its
> eSATA interface.
> It was during this thread that I was first introduced to HD Sentinel.
> The My Book contained a bridging chipset that acted as the interface from
> the hard disk to the computer, offering USB, Firewire, and eSATA. What we
> didn't know back then was that the chipset was manufactured by a company
> called Oxford Semiconductor. This chipset contained its own ARM processor.
> So it was an intelligent interface controller. If the ARM chip failed
> somehow, then it would mean the interface is dead, but not necessarily the
> disk inside.
Even if it had, you don't know that that wasn't because the
power supply had spiked it and that it took some time for
the effect of the spike to show up with the drive itself.
> http://en.wikipedia.org/wiki/Western_Digital_My_Book#Internals
>>> I talked to HD Sentinel support about this, and he suggested that the
>>> problem might lie in the total Load/Unload Cycle Count, which is over
>>> 600,000. I think this drive is only rated for 300,000.
>> Cant see how that would produce that very unusual symptom
>> of the write speed so dramatically affected by the location of
>> the head on the platter, and not the read speed.
> The HD Sentinel tech believes that the excessive load/unload cycles might
> have damaged the head parking area of that drive.
are fine with the heads over half the platter either.
> This might have resulted in microscopic dust particles covering the
> platter
poor write perfomance over just half of the platter,
and have no effect on reads at all.
> which made it harder to re-magnetize the platter near the parking area.
There is no way that that would affect JUST half the platter,
and that boundary never changing, or the very sharp boundary
been extremely slow writes and normal write performance and
have no effect whatever on the read speed.
> Since the parking area is near the front of the platters, this is the area
> that was first affected.
a striking boundary between the good half and the
bad half and not affect the read performance at all.
> He suggested that this dust is just going to keep creeping towards the
> back of the drive, until the entire surface is unusable.
have been seen and just ONE bad sector.
Bet the boundary that's so striking on your
first chart doesn't move over time either.
> The fact that there are some areas which are alternately fast and slow
> (i.e. the "Slow", "Medium" and "Fast" sections of the drive)
that the last half of the drive is fine. The steps you do see after
that are just the areas where the sectors per track changes.
You'll find that with a brand now drive.
> is an indication that this backward creep is already happening.
> It's a theory,
Which has holes in it you can drive an full aircraft carrier battle group
thru.
> don't know if it's the only possible theory.
>>> He suggested I disable spin-down of these drives.
>> They certainly are notorious for unloading much too frequently.
>> Havent see anyone report that weird write speed result with them tho.
> Now that I know that this Western Digital load/unload issue has come up
> before on this newsgroup, I would like to know how other people determined
> that this was a problem?
> I think Arno was one of the first to express concern over this load/unload
> issue,
> but I don't quite know what led him to believe that it was a problem?
> I realize we're getting into historical issues here.
Yousuf Khan
Apr 28, 2012, 6:38:47 PM4/28/12
to
On 28/04/2012 6:05 AM, Rod Speed wrote:
>> details not fully determined yet, but this one could only be
>> electronic/electrical in nature.
>
> You don't know that either. A drop can see a failure there
> just with a bad joint or a connector coming off internally etc.
I can confirm that it was neither a physical drop, nor an electrical
>> details not fully determined yet, but this one could only be
>> electronic/electrical in nature.
>
> You don't know that either. A drop can see a failure there
> just with a bad joint or a connector coming off internally etc.
spike. Firstly, the drive was sitting in a home theatre cabinet most of
that time, so there was no physical movement done while it was powered
on, so a drop is not possible; and no earthquakes either, in case you're
going to ask that too. Secondly, all of the devices were on an expensive
surge protector.
>>>> This particular enclosure had all three major interfaces: USB,
>>>> Firewire, and eSATA. It was mainly being used through USB on the PVR,
>>>> and when that stopped working, we tried testing it on eSATA on the PC,
>>>> and that one was also not working (they were all previously working).
>>>> Didn't bother with Firewire, since two out of three interfaces were
>>>> dead, chances are slim that the 3rd was still working.
>
>> BTW, I had written about this drive's history before on this newsgroup
>> (Google Groups):
>> http://is.gd/tkqeKJ
>
>> Back then, the drive was still inside its My Book enclosure, and I was
>> having some kind of problem with reading SMART data out of it through
>> its eSATA interface.
>
> That isnt necessarily related to either fault.
everything!
>> It was during this thread that I was first introduced to HD Sentinel.
>
>> The My Book contained a bridging chipset that acted as the interface
>> from the hard disk to the computer, offering USB, Firewire, and eSATA.
>> What we didn't know back then was that the chipset was manufactured by
>> a company called Oxford Semiconductor. This chipset contained its own
>> ARM processor. So it was an intelligent interface controller. If the
>> ARM chip failed somehow, then it would mean the interface is dead, but
>> not necessarily the disk inside.
>
> Is there any evidence that the ARM chip has actually failed ?
chipset, so it failed along with everything else.
> Even if it had, you don't know that that wasn't because the
> power supply had spiked it and that it took some time for
> the effect of the spike to show up with the drive itself.
>> Since the parking area is near the front of the platters, this is the
>> area that was first affected.
>
> Its never going to affect just half the platter with such
> a striking boundary between the good half and the
> bad half and not affect the read performance at all.
dismiss it.
>> He suggested that this dust is just going to keep creeping towards the
>> back of the drive, until the entire surface is unusable.
>
> Have fun explaining why no head crashes
> have been seen and just ONE bad sector.
>
> Bet the boundary that's so striking on your
> first chart doesn't move over time either.
>
>> The fact that there are some areas which are alternately fast and slow
>> (i.e. the "Slow", "Medium" and "Fast" sections of the drive)
>
> That isnt actually the case. Your first chart does in fact show
> that the last half of the drive is fine. The steps you do see after
> that are just the areas where the sectors per track changes.
was universally slow, while the "Fast" section was universally fast.
>> Now that I know that this Western Digital load/unload issue has come
>> up before on this newsgroup, I would like to know how other people
>> determined that this was a problem?
>
> Basically by looking at the load/unload value in the SMART data.
>
>> I think Arno was one of the first to express concern over this
>> load/unload issue,
>
> Yes.
>
>> but I don't quite know what led him to believe that it was a problem?
>
> Basically by looking at the load/unload value in the SMART data.
can get freaked out about, such as ECC Recovered, Seek Error Rate, Total
LBA written and Total LBA read. Nobody actually pays attention to those
numbers until there is an actual problem occurring.
So Arno much've noticed a problem?
Rod Speed
Apr 28, 2012, 9:23:16 PM4/28/12
to
Yousuf Khan <bbb...@spammenot.yahoo.com> wrote
> Firstly, the drive was sitting in a home theatre cabinet most of that
> time,
Most of the time is irrelevant and you don't even know
if it got dropped before it was even put in there etc.
> so there was no physical movement done while it was powered on,
Doesn't need to have been powered on with a dry joint or connector loosened.
> so a drop is not possible;
That's just plain wrong.
> and no earthquakes either, in case you're going to ask that too. Secondly,
> all of the devices were on an expensive surge protector.
Doesn't eliminate the possibility of the power supply with
an intermittent fault that spikes the output rail occasionally.
>>>>> This particular enclosure had all three major interfaces: USB,
>>>>> Firewire, and eSATA. It was mainly being used through USB on the PVR,
>>>>> and when that stopped working, we tried testing it on eSATA on the PC,
>>>>> and that one was also not working (they were all previously working).
>>>>> Didn't bother with Firewire, since two out of three interfaces were
>>>>> dead, chances are slim that the 3rd was still working.
>>> BTW, I had written about this drive's history before on this newsgroup
>>> (Google Groups):
>>> http://is.gd/tkqeKJ
>>> Back then, the drive was still inside its My Book enclosure, and I was
>>> having some kind of problem with reading SMART data out of it through
>>> its eSATA interface.
>> That isnt necessarily related to either fault.
> That's just the background to the thread! You don't have to argue about
> everything!
You hate it when the holes are pointed out in your theorys.
>>> It was during this thread that I was first introduced to HD Sentinel.
>>> The My Book contained a bridging chipset that acted as the interface
>>> from the hard disk to the computer, offering USB, Firewire, and eSATA.
>>> What we didn't know back then was that the chipset was manufactured by a
>>> company called Oxford Semiconductor. This chipset contained its own ARM
>>> processor. So it was an intelligent interface controller. If the
>>> ARM chip failed somehow, then it would mean the interface is dead, but
>>> not necessarily the disk inside.
>> Is there any evidence that the ARM chip has actually failed ?
> Irrelevant, the chipset failed, the embedded ARM was part of the chipset,
> so it failed along with everything else.
>>> Since the parking area is near the front of the platters, this is the
>>> area that was first affected.
>> Its never going to affect just half the platter with such
>> a striking boundary between the good half and the
>> bad half and not affect the read performance at all.
> Yeah, well, I'm not convinced that's the answer either,
> but I don't dismiss it.
I do on that alone, let alone the lack of any head crashes.
Even just smoke from cigarette smokers produces head
crashes with modern hard drives, there is no way that any
physical wear in the landing zone could produce anything
that's not going to produce a head crash if its floating around.
He's completely off with the fucking fairys on that claim.
>>> He suggested that this dust is just going to keep creeping towards the
>>> back of the drive, until the entire surface is unusable.
>> Have fun explaining why no head crashes
>> have been seen and just ONE bad sector.
>> Bet the boundary that's so striking on your
>> first chart doesn't move over time either.
>>> The fact that there are some areas which are alternately fast and slow
>>> (i.e. the "Slow", "Medium" and "Fast" sections of the drive)
>> That isnt actually the case. Your first chart does in fact show
>> that the last half of the drive is fine. The steps you do see after
>> that are just the areas where the sectors per track changes.
> The "Medium" section was alternately fast and slow.
No evidence of that with that first chart of yours.
> The "Slow" section was universally slow,
Yes, the first chart does show that.
> while the "Fast" section was universally fast.
No evidence of that either with that first
chart of yours that for the entire drive.
>>> Now that I know that this Western Digital load/unload issue has come up
>>> before on this newsgroup, I would like to know how other people
>>> determined that this was a problem?
>> Basically by looking at the load/unload value in the SMART data.
>>> I think Arno was one of the first to express concern over this
>>> load/unload issue,
>> Yes.
>>> but I don't quite know what led him to believe that it was a problem?
>> Basically by looking at the load/unload value in the SMART data.
> But there's a lot of huge numbers that can occur in SMART data that you
> can get freaked out about, such as ECC Recovered, Seek Error Rate, Total
> LBA written and Total LBA read.
Not with someone like Arno who knows what the numbers mean.
> Nobody actually pays attention to those numbers until there is an actual
> problem occurring.
That's just plain wrong with people like Arno, Frank and me.
> So Arno much've noticed a problem?
Fraid not. He just noticed the very high load/unload count
before it had even got anywhere near the design limit for
the drive and stopped it doing that obscene level of unloads.
Its all there in groups.google.
> Rod Speed wrote
>>> details not fully determined yet, but this one could only be
>>> electronic/electrical in nature.
>> You don't know that either. A drop can see a failure there
>> just with a bad joint or a connector coming off internally etc.
> I can confirm that it was neither a physical drop, nor an electrical
> spike.
No you cant.
>>> details not fully determined yet, but this one could only be
>>> electronic/electrical in nature.
>> You don't know that either. A drop can see a failure there
>> just with a bad joint or a connector coming off internally etc.
> I can confirm that it was neither a physical drop, nor an electrical
> spike.
> Firstly, the drive was sitting in a home theatre cabinet most of that
> time,
if it got dropped before it was even put in there etc.
> so there was no physical movement done while it was powered on,
> so a drop is not possible;
> and no earthquakes either, in case you're going to ask that too. Secondly,
> all of the devices were on an expensive surge protector.
an intermittent fault that spikes the output rail occasionally.
>>>>> This particular enclosure had all three major interfaces: USB,
>>>>> Firewire, and eSATA. It was mainly being used through USB on the PVR,
>>>>> and when that stopped working, we tried testing it on eSATA on the PC,
>>>>> and that one was also not working (they were all previously working).
>>>>> Didn't bother with Firewire, since two out of three interfaces were
>>>>> dead, chances are slim that the 3rd was still working.
>>> BTW, I had written about this drive's history before on this newsgroup
>>> (Google Groups):
>>> http://is.gd/tkqeKJ
>>> Back then, the drive was still inside its My Book enclosure, and I was
>>> having some kind of problem with reading SMART data out of it through
>>> its eSATA interface.
>> That isnt necessarily related to either fault.
> That's just the background to the thread! You don't have to argue about
> everything!
>>> It was during this thread that I was first introduced to HD Sentinel.
>>> The My Book contained a bridging chipset that acted as the interface
>>> from the hard disk to the computer, offering USB, Firewire, and eSATA.
>>> What we didn't know back then was that the chipset was manufactured by a
>>> company called Oxford Semiconductor. This chipset contained its own ARM
>>> processor. So it was an intelligent interface controller. If the
>>> ARM chip failed somehow, then it would mean the interface is dead, but
>>> not necessarily the disk inside.
>> Is there any evidence that the ARM chip has actually failed ?
> Irrelevant, the chipset failed, the embedded ARM was part of the chipset,
> so it failed along with everything else.
You don't know that either.
>> Even if it had, you don't know that that wasn't because the
>> power supply had spiked it and that it took some time for
>> the effect of the spike to show up with the drive itself.
> See above, surge protected.
Doesn't mean anything, see above.
>> power supply had spiked it and that it took some time for
>> the effect of the spike to show up with the drive itself.
> See above, surge protected.
>>> Since the parking area is near the front of the platters, this is the
>>> area that was first affected.
>> Its never going to affect just half the platter with such
>> a striking boundary between the good half and the
>> bad half and not affect the read performance at all.
> Yeah, well, I'm not convinced that's the answer either,
> but I don't dismiss it.
Even just smoke from cigarette smokers produces head
crashes with modern hard drives, there is no way that any
physical wear in the landing zone could produce anything
that's not going to produce a head crash if its floating around.
He's completely off with the fucking fairys on that claim.
>>> He suggested that this dust is just going to keep creeping towards the
>>> back of the drive, until the entire surface is unusable.
>> Have fun explaining why no head crashes
>> have been seen and just ONE bad sector.
>> Bet the boundary that's so striking on your
>> first chart doesn't move over time either.
>>> The fact that there are some areas which are alternately fast and slow
>>> (i.e. the "Slow", "Medium" and "Fast" sections of the drive)
>> That isnt actually the case. Your first chart does in fact show
>> that the last half of the drive is fine. The steps you do see after
>> that are just the areas where the sectors per track changes.
> The "Medium" section was alternately fast and slow.
> The "Slow" section was universally slow,
> while the "Fast" section was universally fast.
chart of yours that for the entire drive.
>>> Now that I know that this Western Digital load/unload issue has come up
>>> before on this newsgroup, I would like to know how other people
>>> determined that this was a problem?
>> Basically by looking at the load/unload value in the SMART data.
>>> I think Arno was one of the first to express concern over this
>>> load/unload issue,
>> Yes.
>>> but I don't quite know what led him to believe that it was a problem?
>> Basically by looking at the load/unload value in the SMART data.
> But there's a lot of huge numbers that can occur in SMART data that you
> can get freaked out about, such as ECC Recovered, Seek Error Rate, Total
> LBA written and Total LBA read.
> Nobody actually pays attention to those numbers until there is an actual
> problem occurring.
> So Arno much've noticed a problem?
before it had even got anywhere near the design limit for
the drive and stopped it doing that obscene level of unloads.
Its all there in groups.google.
0 new messages