Western Digital GreenPower drives and Linux
Tvrtko A. Ursulin
Hi all,
The subject may be a bit misleading since I haven't investigated the whole
issue under other OS-es (nor do I plan to), but this is how the story goes..
Those fancy new WD GreenPower drives seem to be heavily suffering from the
rapidly increasing head load/unload problem. And the bad thing is they don't
respond to 'hdparm -B', which would mean (I think) their power management
behaviour is solely up to their firmware.
I got one of them (WD5000AACS) recently and to my horror after less than three
days of being power on this is what I saw:
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 66
193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 10233
At this rate the disk would reach it's design limit for load/unload cycles in
around 80 days. Not good - so I implemented a lame workaround of keeping disk
busy every couple of seconds - hopefully that won't kill it sooner that
unloads would..
I am also currently talking with first line of WD's tech support trying to get
some data on how exactly those drives manage head unloading, but that may not
lead anywhere useful.
So in parallel I decided to ask here to see if someone knows something about
this?
If it matters, I am running vanilla 2.6.24 on that box and sata_sil is driving
that disk. Otherwise it is a pretty basic Ubuntu 7.10, a mix of ext3 and jfs
filesystems, all mounted with noatime. More detailed information available on
request.
Tvrtko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tvrtko A. Ursulin
> I got one of them (WD5000AACS) recently and to my horror after less than
> three days of being power on this is what I saw:
>
> 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 66
> 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 10233
>
> At this rate the disk would reach it's design limit for load/unload cycles
> in around 80 days. Not good - so I implemented a lame workaround of keeping
> disk busy every couple of seconds - hopefully that won't kill it sooner
> that unloads would..
>
> I am also currently talking with first line of WD's tech support trying to
> get some data on how exactly those drives manage head unloading, but that
> may not lead anywhere useful.
I got back from WD's tech support and received a DOS utility which can control
this drive feature, apparently using vendor specific commands. With it head
unload timer can be disabled or set to a period between 100ms and 25.5s.
Of course I asked for more than a DOS utility, but the question really is how
was this feature intended to work with Windows for example, is there
something there which would prevent such rapid load/unload cycle growth, and
why isn't it documented somewhere?
I am kind off hoping that someone from WD is reading this list and will notice
this in case my effort with tech support fails.
Kasper Sandberg
> On Wednesday 09 April 2008 21:18:35 Tvrtko A. Ursulin wrote:
> > I got one of them (WD5000AACS) recently and to my horror after less than
> > three days of being power on this is what I saw:
> >
> > 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 66
> > 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 10233
> >
> > At this rate the disk would reach it's design limit for load/unload cycles
> > in around 80 days. Not good - so I implemented a lame workaround of keeping
> > disk busy every couple of seconds - hopefully that won't kill it sooner
> > that unloads would..
> >
> > I am also currently talking with first line of WD's tech support trying to
> > get some data on how exactly those drives manage head unloading, but that
> > may not lead anywhere useful.
>
> I got back from WD's tech support and received a DOS utility which can control
> this drive feature, apparently using vendor specific commands. With it head
> unload timer can be disabled or set to a period between 100ms and 25.5s.
>
> Of course I asked for more than a DOS utility, but the question really is how
> was this feature intended to work with Windows for example, is there
> something there which would prevent such rapid load/unload cycle growth, and
time, perhaps this is why they never had this trouble when testing..
(which is kindof weird, as one would think lots of people would be
especially interrested in getting energy saving disks in their servers)
Christian Pernegger
> Those fancy new WD GreenPower drives seem to be heavily suffering from the
> rapidly increasing head load/unload problem. [...] I got one of them
> (WD5000AACS) recently and to my horror [...]
I have the same disks, only with more warranty and supposedly
"enterprise" firmware (WD1000FYPS). The bug is the same, though, on
all four of them (~ 9 cycles /hour):
9 Power_On_Hours 0x0032 099 099 000 Old_age
Always - 917
193 Load_Cycle_Count 0x0032 198 198 000 Old_age
Always - 8025
9 Power_On_Hours 0x0032 099 099 000 Old_age
Always - 906
193 Load_Cycle_Count 0x0032 198 198 000 Old_age
Always - 7908
9 Power_On_Hours 0x0032 099 099 000 Old_age
Always - 907
193 Load_Cycle_Count 0x0032 198 198 000 Old_age
Always - 8051
9 Power_On_Hours 0x0032 099 099 000 Old_age
Always - 918
193 Load_Cycle_Count 0x0032 198 198 000 Old_age
Always - 7869
> I got the _DOS_ utility from WD which issues vendor specific commands to
> control that feature.
Have they confirmed it's a bug? I have no idea how often the disks
should do that.
> [...] With it the unload feature can be either disabled or timer set from
> 100ms to 25.5 seconds. But obviously I can't try it...
Why? Using a DOS boot disk once would not be that bad as a workaround,
would it? Or is the setting not persistent? Either way I'd prefer to
be able to leave the feature on (in usable form), eventually.
The bigger question is - why the rapid loads / unloads? In my case the
disks are idle hours at a time. No system files on there, just bulk
data. Does / could the controller (sata_sil24 in my case) have any
influence on this kind of power management?
Thanks,
C.
dev...@web.de
if we trust the spec, the disk would be dead after ~1year.
it seems that "intellipark" is not that intelligent as it should be and a little bit too agressive.
from what i have found, the time for parking the heads is much below the linux kernel flush interval (which seems to be at 30secs), so i think the best thing to do is tuning either dirty_expire_centisecs and dirty_writeback_centisecs (defaults to 3000/500 on my system) or tune the disk parking interval , so that the disks own interval is greater than the linux flush interval.
i also openend an SR at WD - will see if they will recommend that dos utility, too.
>I got back from WD's tech support and received a DOS utility which can control
>this drive feature, apparently using vendor specific commands. With it head
>unload timer can be disabled or set to a period between 100ms and 25.5s.
doh - so that disk always is faster with parking it`s heads than linux default flush interval !?
btw - is that dos utility available for download somewhere?
regards
roland
List: linux-kernel
Subject: Re: Western Digital GreenPower drives and Linux
From: "Tvrtko A. Ursulin" <tvrtko () ursulin ! net>
Date: 2008-04-10 7:48:08
Message-ID: 200804100848.08442.tvrtko () ursulin ! net
[Download message RAW]
On Wednesday 09 April 2008 21:18:35 Tvrtko A. Ursulin wrote:
> I got one of them (WD5000AACS) recently and to my horror after less than
> three days of being power on this is what I saw:
>
> 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 66
> 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 10233
>
> At this rate the disk would reach it's design limit for load/unload cycles
> in around 80 days. Not good - so I implemented a lame workaround of keeping
> disk busy every couple of seconds - hopefully that won't kill it sooner
> that unloads would..
>
> I am also currently talking with first line of WD's tech support trying to
> get some data on how exactly those drives manage head unloading, but that
> may not lead anywhere useful.
I got back from WD's tech support and received a DOS utility which can control
this drive feature, apparently using vendor specific commands. With it head
unload timer can be disabled or set to a period between 100ms and 25.5s.
Of course I asked for more than a DOS utility, but the question really is how
was this feature intended to work with Windows for example, is there
something there which would prevent such rapid load/unload cycle growth, and
why isn't it documented somewhere?
I am kind off hoping that someone from WD is reading this list and will notice
this in case my effort with tech support fails.
Tvrtko
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
Tvrtko A. Ursulin
> >I got back from WD's tech support and received a DOS utility which can
> > control this drive feature, apparently using vendor specific commands.
> > With it head unload timer can be disabled or set to a period between
> > 100ms and 25.5s.
Followup with some good news.
Head unload timer settings seems to be persistent across powering off. Having
set it to a maximum value of 25.5 seconds my disk is now behaving much more
reasonable.
To actually do it I used FreeDOS floppy image burnt on a CD-RW as a bootable
image plus wdidle3.exe in the filesystem itself.
BTW, WD's tech support has gone silent so chances for an easier solution are
not so great.
Tvrtko
Mike Snitzer
>
> > >I got back from WD's tech support and received a DOS utility which can
> > > control this drive feature, apparently using vendor specific commands.
> > > With it head unload timer can be disabled or set to a period between
> > > 100ms and 25.5s.
>
> Followup with some good news.
>
> Head unload timer settings seems to be persistent across powering off. Having
> set it to a maximum value of 25.5 seconds my disk is now behaving much more
> reasonable.
>
> To actually do it I used FreeDOS floppy image burnt on a CD-RW as a bootable
> image plus wdidle3.exe in the filesystem itself.
>
> BTW, WD's tech support has gone silent so chances for an easier solution are
> not so great.
Any chance you could make your iso available for the freedos w/
wdidle3.exe bootable cd?
I can't track down wdidle3.exe on wdc.com; they have "Data Lifeguard"
and such but I have no idea if the wdidle3.exe is buried in those
downloads.
thanks,
Mike
Tvrtko A. Ursulin
> Any chance you could make your iso available for the freedos w/
> wdidle3.exe bootable cd?
>
> I can't track down wdidle3.exe on wdc.com; they have "Data Lifeguard"
> and such but I have no idea if the wdidle3.exe is buried in those
> downloads.
According to the licence which comes with that thing distribution is not
allowed. Also it wouldn't be bad if more people contacted WD about it so that
they figure out they at least need to make it available as a download, if not
something better.
Tvrtko
Mike Snitzer
> On Saturday 12 April 2008 04:19:33 Mike Snitzer wrote:
> > Any chance you could make your iso available for the freedos w/
> > wdidle3.exe bootable cd?
> >
> > I can't track down wdidle3.exe on wdc.com; they have "Data Lifeguard"
> > and such but I have no idea if the wdidle3.exe is buried in those
> > downloads.
>
> According to the licence which comes with that thing distribution is not
> allowed. Also it wouldn't be bad if more people contacted WD about it so that
> they figure out they at least need to make it available as a download, if not
> something better.
Just an FYI, I had a look at my counters for a 1TB GP I've had in
always-on service (expansion drive for my tivo; which runs Linux) for
6 months. I'm not seeing any issues, Load_Cycle_Count is quite low.
Device Model: WDC WD10EACS-32ZJB0
Firmware Version: 01.01B01
9 Power_On_Hours 0x0032 094 094 000 Old_age
Always - 4763
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 7
193 Load_Cycle_Count 0x0032 200 200 000 Old_age
Always - 9
Given the Tivo is constantly doing IO it must've prevented the disk
from ever spinning down.
Mike Snitzer
Turns out 'wdidle3 /R' on my drive reported:
"Idle3 Timer is disabled"
I took no explicit action to disable it 6 months ago. It strikes me as
odd that WD would disable the Idle3 timer in firmware given the whole
"GreenPower" campaign but I was pleasantly surprised; others may be
too...
Jan Engelhardt
On Thursday 2008-04-10 17:01, Christian Pernegger wrote:
>
>> Those fancy new WD GreenPower drives seem to be heavily suffering from the
>> rapidly increasing head load/unload problem. [...] I got one of them
>> (WD5000AACS) recently and to my horror [...]
>
>> 100ms to 25.5 seconds. But obviously I can't try it...
>
>Why? Using a DOS boot disk once would not be that bad as a workaround,
>would it?
This DOS nonsense does not work anywhere outside x86.
I see people put *lots* of afterthought in their utilities, hardware even.
WD is not the first to do this unload nonsense, I've noticed it with
Toshiba before: http://lkml.org/lkml/2006/11/15/413 Since then, I am
dependent on the thkd[1] module and no hdparm is going to fix it; the
module does a dumb read every now and then on one device, causing
streaming performance to kink periodically, but it works at least at
keeping the disk alive. (Reason it's in kernel: better to have even when
userspace is not running.) Improvements welcome.
[1] ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/rawkernel/
somewhere in there since recently.
Niels
[snip]
>
> Turns out 'wdidle3 /R' on my drive reported:
> "Idle3 Timer is disabled"
>
> I took no explicit action to disable it 6 months ago. It strikes me as
> odd that WD would disable the Idle3 timer in firmware given the whole
> "GreenPower" campaign but I was pleasantly surprised; others may be
> too...
A data point from me. I have two of these, sda is 400GB and has root, boot,
swap and home partitions, sdb is 1TB and has one big partition. They're in
my desktop machine, which is usually powered on in the morning and off in
the evening. It's two months old.
sda:
9 Power_On_Hours 0x0032 099 099 000 Old_age
Always - 785
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 141
193 Load_Cycle_Count 0x0032 200 200 000 Old_age
Always - 144
sdb:
9 Power_On_Hours 0x0032 099 099 000 Old_age
Always - 749
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 122
193 Load_Cycle_Count 0x0032 195 195 000 Old_age
Always - 17276
The last of these numbers seems fairly high, compared to what others in this
thread have reported, especially considering that the disk is quite new.
//Niels
Mark Lord
>
> WD is not the first to do this unload nonsense,
Indeed. Seagate beat them to it by a decade or so.
Hence the hdparm -Z flag for old Seagate drives. :)
Helge Hafting
> Hi all,
>
> The subject may be a bit misleading since I haven't investigated the whole
> issue under other OS-es (nor do I plan to), but this is how the story goes..
>
> Those fancy new WD GreenPower drives seem to be heavily suffering from the
> rapidly increasing head load/unload problem. And the bad thing is they don't
> respond to 'hdparm -B', which would mean (I think) their power management
> behaviour is solely up to their firmware.
>
> I got one of them (WD5000AACS) recently and to my horror after less than three
> days of being power on this is what I saw:
>
> 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 66
> 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 10233
>
> At this rate the disk would reach it's design limit for load/unload cycles in
> around 80 days. Not good - so I implemented a lame workaround of keeping disk
> busy every couple of seconds - hopefully that won't kill it sooner that
> unloads would..
>
But the solution is simple. Make sure to get a warranty of much more
than 80 days. Use RAID-1 (or backup often).
Just let those disks destroy themselves (they _are_ faulty) and
get new ones all the time. As long as they make them this stupid, you won't
have to buy new disks again. Free warranty replacements forever.
To be a bit more constructive, tell them about this strategy. Perhaps
they get
busy fixing the firmware?
Helge Hafting
Christian Pernegger
> in around 80 days.
Design *minimum* for load/unload cycles is reportedly 600K cycles,
that would give me over 7.5 years of 24/7 operation, which I can live
with in cheap high capacity drives that have only 5 years of warranty
anyway.
Support wouldn't say if the behavior is considered normal, though ...
Will set the timeout to 25sec using the DOS kludge and see what
happens ... doubt it will help much, though. I'd much rather like to
know what causes the drives to load heads again so soon after the
unload. With the usage pattern of these drives they should stay
unloaded most of the time here.
Being able to set the timeout online via hdparm would be nice, too :)
C.
Mark Lord
>
> Will set the timeout to 25sec using the DOS kludge and see what
> happens ... doubt it will help much, though. I'd much rather like to
> know what causes the drives to load heads again so soon after the
> unload. With the usage pattern of these drives they should stay
> unloaded most of the time here.
>
> Being able to set the timeout online via hdparm would be nice, too :)
That can be arranged. I just need a copy of the DOS utility that does it now.
Cheers
Tvrtko A. Ursulin
> Tvrtko A. Ursulin wrote:
> > 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 66
> > 193 Load_Cycle_Count 0x0032 197 197 000 Old_age Always - 10233
> >
> > At this rate the disk would reach it's design limit for load/unload
> > cycles in around 80 days. Not good - so I implemented a lame workaround
> > of keeping disk busy every couple of seconds - hopefully that won't kill
> > it sooner that unloads would..
>
> Yuck, how stupid!
> But the solution is simple. Make sure to get a warranty of much more
> than 80 days. Use RAID-1 (or backup often).
> Just let those disks destroy themselves (they _are_ faulty) and
> get new ones all the time. As long as they make them this stupid, you
> won't have to buy new disks again. Free warranty replacements forever.
:) I am not so enthusiastic about fiddling with my NAS box every couple of
months.
> To be a bit more constructive, tell them about this strategy. Perhaps
> they get
> busy fixing the firmware?
I have suggested exactly what you say - unfortunately the conversation has
gone cold since. Maybe they are busy already. :)
Tvrtko
Tvrtko A. Ursulin
> > > At this rate the disk would reach it's design limit for load/unload
> > > cycles
> >
> > in around 80 days.
>
> Design *minimum* for load/unload cycles is reportedly 600K cycles,
> that would give me over 7.5 years of 24/7 operation, which I can live
> with in cheap high capacity drives that have only 5 years of warranty
> anyway.
That is what they said to me as well. But their datasheet says it is 300k for
desktop and 600k cycles for RAID edition drives. It also doesn't mention
minimum but "Controlled unloads at ambient condition". But that's probably
fine.. you are just in luck that you don't use them as system drives. As I
said before, with timer set to 25.5s they are fine for me now - I am seeing
just two unload cycles per hour on average, that is by factor of 100 less
than before.
Tvrtko