Hardeschijffabrikanten misleiden consumenten graag in hun voordeel; op vele gebieden. Ik geloof dat dit ook van toepassing is op de zogenaamde '24/7 ready' schijven. Elke schijf draait in mijn optiek het beste 24/7 in een stabiele omgeving. Het is juist andersom: enterprise schijven kun je niet in een consumentensituatie gebruiken. Dit is omdat enterprise schijven niet gebouwd zijn voor het vele op en downspinnen. Consumenten schijven zijn dat wel, maar ik zie geen enkele reden waarom dat 24/7 operatie in de weg zou staan.
Je vergeet de garantie.
En volgens mij hebben WD Red headparking helemaal uitgeschakeld.
Het lijstje zou dus kunnen zijn:
- WD Green ondersteunt geen TLER; WD Red doet dat wel en heeft het standaard ingeschakeld. Dit maakt WD Red minder geschikt als losse schijf zonder redundantie, omdat de recovery min of meer is uitgeschakeld.
- WD Red heeft headparking uitgeschakeld, WD Greens hebben dit ingeschakeld. Oudere Greens hadden dit zeer agressief afgesteld; maar tegenwoordig is dit allang geen groot probleem meer.
- WD Red heeft 3 jaar fabrieksgarantie; WD Green slechts 2 jaar in de EU en 1 jaar buiten de EU.
Een Green disk in een NAS zal zich na een jaar kapot geparkeerd hebben omdat het filesystem (ext3/4) dat in de meeste NAS systemen gebruikt wordt een commit interval heeft die 1s langer is dan de idletimeout van een WD Green, waardoor een Green drive constant parkeert en weer opspint.
Dat geldt alleen voor de oudere Greens, zoals WD20EARS. Mijn WD40EZRX (WD Green 4TB) heeft een veel mildere headparking. Die kun je rustig laten zoals het is. De oudere Greens konden al na enkele maanden over hun 300.000 load cycles heen zitten; maar dat is echt niet meer het geval bij nieuwere Greens.
TLER is aan te raden in RAID systemen, een normale disk zal bij een bad sector proberen om de sector koste wat kost te lezen, in de tussentijd hangt je hele systeem. Bij RAID heeft dat geen zin, die sector kan ook gewoon vanaf de 2e disk gelezen worden, dus gebruik je TLER om recovery na ~7s af te breken en het RAID systeem zijn werk te laten doen.
Dit is niet helemaal correct. Een RAID engine heeft geen TLER nodig; het kan zelf bepalen om de I/O command te resetten en dus te zorgen dat de schijf er na x seconden mee op houdt. Wat hoort te gebeuren is dat de RAID engine redundante informatie leest en deze weer schrijft naar de kapotte sector.
Goede RAID engines hebben daarom helemaal geen TLER nodig; dit geldt alleen voor simpele, naïeve en slecht geschreven RAID engines. Windows en Hardware RAID valt hieronder; software RAID onder Linux/BSD en ZFS juist weer niet.
Overigens, wat TLER betreft, op dit moment zijn Hitachi en Toshiba de enige fabrikanten die het nog toestaan om TLER in te schakelen op desktopdisks die niet specifiek op NAS of serversystemen zijn gericht. Bij Seagate en WD is dit uitgeschakeld in de firmware en duwen ze je naar NAS of enterprise disks.
Samsung, Hitachi en Toshiba ondersteunen helemaal geen TLER, maar CCTL. Seagate ondersteunt ERC, wat vergelijkbaar is met CCTL. Het grote verschil tussen CCTL/ERC en TLER, is dat TLER een persistent instelling is die onthouden blijft nadat de schijf een power cycle heeft gehad. CCTL/ERC moet bij elke boot/power cycle opnieuw worden gestuurd naar de hardeschijf.
Dit betekent dat een RAID controller actief CCTL/ERC moet ondersteunen, anders werkt het niet. Bij TLER is dat niet zo: die zullen altijd hun recovery beperken ongeacht aan welke controller je de schijf hangt. Ik heb geen enkele informatie over welke RAID controllers CCTL/ERC ondersteunen; het is daarom veel veiliger om voor TLER te gaan. De reden dat Seagate/Hitachi enzo geen persistent TLER-equivalent mogen gebruiken, ligt hem volgens mij in het feit dat WD dit gepatenteerd heeft.