4 ms·

Interesting. Can you please point me to a more authoritative source for this? I also had a "green" drive fail surprisingly soon. How did you confirm that they

Interesting. Can you please point me to a more authoritative source for this? I also had a "green" drive fail surprisingly soon. How did you confirm that they spin up and down "several times a minute" by themselves. Are you sure it wasn't your misconfigured OS telling them to do that? Since green drives are also slower, I just assumed they traded off energy for data transfer speed.

swdunlop 14y ago
You can look for yourself using smartctl -- they still respond after the mechanical failure. Aside from pasting internal emails (not happening :)), you'll have to google for yourself on this one. We didn't do anything novel with these drives at a hardware level to make them fail, and we've got dozens of Constellations in an identical configuration that have had no failures after months of load. It's not transfer speed that they seem to trade off for, it's access times. That may have been part of the problem -- our reads are extremely random over a very broad range of sectors. This isn't exactly a log or video server usage model. :)
wesbrown18 14y ago
http://www.xlr8yourmac.com/tips/Disable_WDGreen_HeadParking.htm http://www.xlr8yourmac.com/tips/Disable_WDGreen_HeadParking.... The default head parking is 10s. In a ZFS configuration, the other drives time out while waiting for the drive to wake up from a parked configuration. This causes a cascade of IO waves back and forth as the drives in a large array park and then unpark to respond, causing IO to plumment. Works fine with 1 drive, or even 2 drives. Past that, the probability of a collision and retry on head parking escalates exponentially.