On Wed, Apr 21, 2010 at 6:20 AM, Bill Davidsen <davidsen@xxxxxxx> wrote: > Phillip Susi wrote: >> >> On 4/14/2010 3:53 PM, Bill Davidsen wrote: >> >>> >>> Stefan *St0fF* Huebner wrote: >>> >>>> >>>> Am 25.03.2010 18:45, schrieb Asdo: >>>> >>>>> >>>>> David Lethe wrote: >>>>> >>>>>> >>>>>> On Mar 25, 2010, at 11:20 AM, Andrew Dunn wrote: >>>>>> >>>>>>> >>>>>>> Recently Dell is selling their WD20EARS (2TB) for 90$ >>>>>>> >>>>>>> This being one of the best PPG (Price Per Gigabyte) snatches I have >>>>>>> seen, I was considering buying 8 of them for an mdadm array. >>>>>>> >>>>>>> Has anyone had experience with these drives? >>>>>>> >> >> I believe that these disks only come in the "green" variety. I recently >> picked up a 1.5 tb version for testing and cheap bulk storage, and I >> would not suggest using them in a raid array because the green drives >> firmware automatically parks the head after 8 seconds of inactivity and >> reduces the rpm of the disk. The constant parking can quickly wear out >> the head under high use and there is no way to disable this "feature". >> > > I hear this said, but I don't have any data to back it up. Drive vendors > aren't stupid, so if the parking feature is likely to cause premature > failures under warranty, I would expect that the feature would not be there, > or that the drive would be made more robust. Maybe I have too much faith in > greed as a design goal, but I have to wonder if load cycles are as > destructive as seems to be the assumption. > > I'd love to find some real data, anecdotal stories about older drives are > not overly helpful. Clearly there is a trade-off between energy saving, > response, and durability, I just don't have any data from a large population > of new (green) drives. It's not hard data, but there was discussion of a similar issue fours years ago related to load/unload cycles on laptops under Ubuntu: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 Simon -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
