Sorry voor de vertraging in mijn reacties. Enorm druk afgelopen dagen, en nog meer net op het nippertje een stukje voor Stefan kunnen schrijven. Toch niet ontevreden.
Ik heb daar in de review-comments wat over geschreven:
Anoniem: 15758 in 'reviews: Desktop Best Buy Guide: maart 2013'
Kort gezegd: ZFS kan bij een sporadische RAM bitflip dit met redundancy vaak nog corrigeren, sowieso heb je errordetectie, je verliest hooguit end-to-end data protection dat is het meest ernstige. Maar mijn argument was vooral dat de client die de data aanlevert eigenlijk als eerste ECC zou moeten hebben, aangezien die helemaal geen mechanisme heeft om corruptie te corrigeren of zelfs te detecteren. Als het bij de client misgaat dan kan je je ZFS server zo veilig maken als je wilt; dan heeft het geen zin. Je kunt met ZFS zien dat je RAM errors hebt aan het feit dat je allemaal CHECKSUM correcties hebt op je disk, wat duidt op diskcorruptie maar dan egaal verdeeld over alle disks. Dus volkomen random. Dat suggereert dat je memtest moet draaien. Dit is mijn ervaring met echt rotte ram-reepjes. Wat zal die ene bitflip per maand aanrichten aan je ZFS server? Ik denk dat ECC niet strict nodig is. Tenzij je een mission-critical bedrijfsserver bouwt natuurlijk, duh. Maar dat is hier de insteek niet.
Dat gezegd, ben ik wel een zeer groot voorstander van ECC. Het is onbegrijpelijk dat ECC niet standaard onderdeel is. Eén extra chipje en wijzigingen aan de IMC (72-bit ipv 64-bit) en je geheugen is ECC-beschermt. Aangezien er bijna overal errordetectie danwel -correctie wordt gebruikt is het vreemd dat iets cruciaals als RAM-geheugen onbeschermd is.
Zodra filesystems en RAM dus betrouwbaarder worden, kun je stellen dat computersystemen eindelijk een stabiele basis krijgen. Dat dit wordt tegengehouden, komt waarschijnlijk omdat er veel geld wordt verdient door zakelijke gebruikers flink meer te laten betalen voor oplossingen die dan wel betrouwbaar zijn. Niet voor niets moeten we nu voor TLER betalen terwijl dat eerst gratis was. Het wordt onderdeel van de marketingstrategie van een bedrjif.
Kan prima hoor. Een aparte ZIL op de SSD (ik noem dat SLOG; iets correctere benaming) hoeft niet veel wear voor de SSD te betekenen. Dankzij de kleine partitie is de write amplification heel laag. Het is een beperkte LBA space waarin steeds data wordt overschreven. Zolang je overprovisioning toepast - en dat moet je zeker doen - gaat SLOG en L2ARC combineren geen problemen opleveren.
Dat SSDs langzamer worden wanneer ze voor zowel lees als schrijfacties gebruikt worden, kan wel kloppen. Echter met AHCI heb je NCQ en dus kan de SSD met zijn 16-way interleaving in feite 16 dingen tegelijk doen. In de praktijk is de winst minder, maar dit zorgt er wel voor dat verschillende I/O vrij parallel kan gebeuren en elkaar dus niet of nauwelijks zal vertragen.
In veel situaties is de hoeveelheid writes naar je SLOG/ZIL heel beperkt. Uitzonderingen zijn de ESXi NFS datapartitie die alles async doet. En iSCSI images waar een client filesystem op draait. Maar je SSD gebruik je om te gebruiken. Dan maak ik me meer zorgen om de USB stick of Transcend module die na maanden van gebruik er een keer mee op kan houden, door de aanhoudende stroom kleine writes en hoge write amplification. Dan spreek je over slijtage. Moderne SSDs zijn zo cool omdat ze kleine writes kunnen redirecten. Dat houdt hun write amplification laag en daarmee ook hun slijtage bij veel en aanhoudende kleine writes zoals veel voorkomt op een systeemdisk.
Het kan een overweging zijn voor diegenen die met XBMC willen stoeien. Maar in de meeste gevallen kiezen mensen toch OpenELEC. Toch kan het altijd een overweging zijn als men ook videodingen op een multi-functionele server wilt uitvoeren.
Ik snap dat jij daar heel anders over denkt en veel strenger bent met wat je zoal op een belangrijke server draait. Maar bedenk dat ook veel amateurs met minder grote belangen ook maar wat proberen met de beperkte hardware die men heeft. Een ZFS server en HTPC in één zou technisch kunnen.
FireDrunk schreef op maandag 11 februari 2013 @ 12:09:
En wth... betrouwbaarder? Sinds wanneer is een el-cheapo SSD perse betrouwbaarder dan een USB stick?
Een goede SLC USB stick gat net zo lang, zo niet langer mee... En hoeft helemaal niet duur te zijn.
En als je een kwalitatief goede USB3.0 stick neemt, issie nog veel sneller ook...
Ik heb juist geleerd dat ook heel goedkope USB-sticks veel sneller kunnen zijn dan dure USB3 sticks. De reden hierachter is dat de 4K random write performance van USB sticks met ongeveer een factor 1000 uiteenloopt. Dat is natuurlijk enorm belangrijk als je een USB-stick als systeemdisk wilt gebruiken. Dan wil je een stick met hoge 4K random write performance niet alleen voor de prestaties, maar ook omdat dit de write amplification drukt en je stick dus langer mee zal doen gaan. Sticks die heel traag zijn, zijn namelijk traag omdat hun WA-factor omhoog schiet. Voor een 512B write moet er dan meerdere megabytes worden gewist en geschreven. Grotere sticks hebben vaak grotere blocksizes. De simpele
pricewatch: Verbatim Store'n'Go Micro-USB 4GB Zwart doet het voor de 4 euro die ik ervoor betaald hebt veel beter dan veel dure sticks. De beste zou kunnen zijn:
pricewatch: Sandisk Extreme USB 3.0 Flash Drive 32GB Zwart die ook heel goede 4K prestaties heeft vergeleken met andere sticks.
I hate to say it, maar die Transcend DOM (Disk-On-Module) 'SSD's zijn behoorlijk prut. Die ik gebruikte zat gewoon een JMicron controller in. Dan kun je beter een normale USB stick gebruiken; goedkoper en waarschijnlijk sneller want de 4K prestaties van de DOMs die ik heb gebruikt zijn dramatisch slecht.
Ik geloof persoonlijk die specs niet zo. Ik wijs daarbij op een voorval in het verleden waarbij de WD Black van 10^-15 naar 10^-14 werd gedowngrade stilletjes. WTF betekent dat? Was het al die tijd -14 of alleen nieuwe productiemodellen? In elk geval denk ik dat de fabrikanten best wat te verbergen hebben aangezien onleesbare sectoren toch een soort design flaw van huidige generatie schijven zijn. In zo'n klimaat loont het om iets minder eerlijk te zijn met de opgegeven specs. Vandaar dat ik die uBER specs met een korrel zout zou nemen. Misschien is het toch lager dan -14. Het is niet alsof je een testrapport krijgt met exacte uitslagen, zoals een 80-plus voedingtest. Dat zou eigenlijk best mogen vind ik.
Hij draait al een tijdje op mijn ASrock B75 Pro3-M. Tot nu toe geen problemen ermee. Enige is dat hij minder powersaving ondersteunt dan de Intel controller in DIPM mode. 0,3 watt. Boeie!
jwpmzijl schreef op zaterdag 09 februari 2013 @ 12:16:
@Cipher (de specialist naar mijn mening)
Zou ZFS als je 16 Gb. plaatst dat extra geheugen bij 4 terabyte opslag op echt gaan gebruiken? Als dat niet het geval is kan in het advies aangegeven worden dat bij plaatsen van extra schijven extra geheugen gewenst is.
Dat geheugen gebruikt ZFS ook op een 16GiB USB stick als je een 16GiB groot bestand inleest. Dat doen trouwens
alle filesystems en virtual memory subsystems, sinds Windows NT geloof ik. Win98 mogelijk niet. Alles wat je inleest blijft in principe in RAM staan, omdat het altijd nuttig kan zijn mocht die data opnieuw worden opgevraagd door een applicatie. RAM filecache is dus iets universeels. In Windows kun je in Task Manager -> Performance tab je Cached RAM-gebruik vinden. Cached+Free = Available RAM, ongeveer.
ZFS kan RAM echter nog veel intelligenter gebruiken omdat het niet alleen last-accessed filecache implementeert, maar ook frequently-accessed. Zo kan bij ZFS het inlezen van een heel groot bestand niet zomaar alle caches wat je daarvoor hebt opgebouwd, wegblazen. In plaats daarvan houdt ZFS deze twee werelden gescheiden.
Wat mij betreft is meer RAM-geheugen voor ZFS de beste performanceupgrade voor ZFS. ZFS is extreem geheugenintensief, dus sneller geheugen en met name lagere latencies kan ook nog iets helpen. Zo zijn er ook CAS9 setjes voor grofweg dezelfde prijs, sommigen die ook op 1600MHz lopen (Crucial Ballistix). Maar kwantiteit is het belangrijkst. Het liefst zou ik iets van 128GiB RAM willen kunnen draaien. Dan heb je eigenlijk geen L2ARC meer nodig.
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
/u/102334/avatar_mini.png?f=community){kind=avatar}
