SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error

Karl Denninger karl at
Sat Dec 23 12:29:26 UTC 2017

On 12/23/2017 05:25, O. Hartmann wrote:
> Am Thu, 14 Dec 2017 12:05:20 +0100
> Willem Jan Withagen <wjw at> schrieb:
>> On 13/12/2017 17:47, Rodney W. Grimes wrote:
>>>> On Tue, 12 Dec 2017 14:58:28 -0800
>>>> Cy Schubert <Cy.Schubert at> wrote:
>>>> I think people responding to my thread made it clear that the WD Green
>>>> isn't the first-choice-solution for a 20/6 (not 24/7) duty drive and
>>>> the fact, that they have serviced now more than 25000 hours, it would
>>>> be wise to replace them with alternatives.  
>>> I think someone had an apm command that turns off the head park,
>>> that would do wonders for drive life.   On the other hand, I think
>>> if it was my data and I saw that the drive had 2M head load cycles
>>> I would be looking to get out of that driv with any data I could
>>> not easily replace.  If it was well backed up or easily replaced
>>> my worries would be less.  
>> WD made their first series of Green disks green by aggressively turning 
>> them into sleep state. Like when few secs there was nog activity they 
>> would park the head, spin it down, and sleep the disk...
>> Access would need to undo the whole series of command.
>> This could be reset by writing in one of the disks registers. I remember 
>> doing that for my 1,5G WDs (WD15EADS from 2009). That saved a lot of 
>> startups. I still have 'm around, but only use them for things that are 
>> not valuable at all. Some have died over time, but about half of them 
>> still seem to work without much trouble.
>> WD used to have a .exe program to actually do this. But that did not
>> work on later disks. And turning things of on those disks was 
>> impossible/a lot more complex.
>> This type of disk worked quite a long time in my ZFS setup. Like a few 
>> years, but I turned parking of as soon as there was a lot of turmoil 
>> about this in the community.
>> Now I using WD reds for small ZFS systems, and WD red Pro for large 
>> private storage servers. Professional server get HGST He disks, a bit 
>> more expensive, but very little fallout.
>> --WjW
> Hello fellows.
> First of all, I managed it over the past week+ to replace all(!) drives with new ones. I
> decided to use this time HGST 4TB Deskstar NAS (HGST HDN726040ALE614) instead of WD RED
> 4TB (WDC WD40EFRX-68N32N0). The one WD RED is about to be replaced in the next days.
> Apart from the very long resilvering time (the first drive, the Western Digital WD RED
> 4TB with 64MB cache and 5400 rpm) took 11 h, all HGST drives, although considered faster
> (7200 rpm, 128 MB cache) took 15 - 16 h), everything ran smoothly - except, as mentioned,
> the exorbitant times of recovery.
> A very interesting point in this story is: as you could see, the WD Caviar Green 3TB
> drives suffered from a high "193 Load_Cycle_Count" - almost 85 per hour. When replacing
> the drives, I figured out, that one of the four drives was already a Western Digital RED
> 3TB NAS drive, but investigating its  "193 Load_Cycle_Count" revealed, that this drive
> also had a unusual high reload count - see "smartctl -x" output attached. It seems, as
> you already stated, that the APM feature responsible for this isn't available. The drive
> has been purchased Q4/2013.
> The HGST drives are very(!) noisy, th ehead movement induces a notable ringing, while the
> WD drive(s) are/were really silent. The power consumption of the HGST drives is higher.
> But apart from that, I'm disappointed about the fact that WD has also implemented this
> "timebomb" Load_Cycle_Count issue.
> Thanks a lot for your help and considerations!
> Kind regards,
> Oliver
I have a fairly large number of HGST "NAS" drives in service across
multiple locations (several dozens units total.)  I don't like their 5Tb
models much (they're slow comparatively for an unknown reason) but the
4Tb and 6Tb models I have in the field, while noisy and somewhat more
power-hungry (the latter comes from the 7200 rpm speed) have yet to
suffer a failure.

Karl Denninger
karl at <mailto:karl at>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the freebsd-current mailing list