Nouja, zonder inderdaad die flamewar te willen starten, is dat wel een belangrijk punt.
Ik ben van mening dat alle traditionele storage (FAT, NTFS, Ext2/3/4, XFS, JFS, UFS) inclusief traditionele RAID inherent onveilig is. Niet dat het om de haverklap corrupt raakt; dat echt niet. Het grootste bezwaar is 'silent corruption'; je weet simpelweg niet wanneer er corruptie optreedt. Als je in ZFS een paar na maanden/jaren van gebruik opeens een paar checksum errors krijgt, haal je je schouders op en ga je verder. Bij de andere oplossingen is dit iets wat onopgemerkt blijft en dus ook naar je backup kan doorvloeien. Je kunt de situatie krijgen dat je dénkt goed beschermd te zijn, maar in de praktijk toch gebeten worden met dataverlies of -corruptie.
Ook denk ik dat zodra alle grote platformen overgegaan zijn tot redundante filesystems (Windows -> ReFS, Linux -> Btrfs, UNIX -> ZFS) de publieke opinie snel zal gaan veranderen en we op de 'ouderwetse' filesystems al snel neerkijken en inzien dat dit tot een ander - vorig - tijdperk behoorde.
Aangezien ZFS op dit moment de enige écht volwassen 'next-gen' filesystem-hybride is, is dat waar nu alle aandacht naartoe gaat. Dat kan de indruk wekken dat het ZFS 'fanboy'-ish betreft. Maar zodra Btrfs en ReFS gemeengoed worden zal ook de rest van mening veranderen, zo denk ik.
Dus laat ik hierbij mijn case gemaakt hebben dat ik ZFS toch wel als superieur zie aan MD+Ext4 of een dergelijke combinatie. Dat betekent niet dat ik het ook gelijk afraad. Dat hangt erg af van de persoonlijke wensen en het kan prima zijn dat de voorkeur voor Windows of Linux zwaarder weegt dan de hogere bescherming die ZFS kan bieden. Dit is één van de vele afwegingen die een NAS zelfbouwer zal moeten ondergaan. Er is geen één beste oplossing voor iedereen.
Parity is hedendaags geen issue meer als je logische dingen doet. Een 100 disk Raid6 op een VIA epia kan wel eens spannend worden, maar of dat logisch is ... .
Parity was ook nooit een issue geweest. XOR is de makkelijkste instructie die een CPU haast kan krijgen. Je bent in feite RAM-bandbreedte bottlenecked. Dit kun je ook zien met Linux+MD waarbij tijdens de boot een korte benchmark wordt getoond waarbij gezocht wordt naar de snelste 'parity path' voor jouw CPU. 7GB/s is daarbij vrij normaal voor een modern systeem, en zelfs ver daarboven tegenwoordig vermoed ik.
Het punt bij RAID5 is dat er een write-back engine met combine engine bij moet. Doe je dat niet, zijn je writes traag omdat je de disks continu laat seeken. Parity RAID in combinatie met mechanische hardeschijven werkt dus alleen goed voor sequential write indien je een 'slimme' RAID5 engine hebt. Intel met volume write-back caching ingeschakeld valt hieronder, die doet de I/O combining in RAM-geheugen. Hardware RAID doet het in eigen geheugen mits write-back is ingeschakeld.
RAID-performance heeft - voor zover ik weet - nooit iets met CPU performance te maken gehad. Wat wel zo is, is dat 1000MB/s vervoeren natuurlijk wel CPU-belasting en vooral geheugen bandbreedte veroorzaakt. Dus dat je met een RAID-array hogere CPU-belasting krijgt is logisch omdat je ook hogere performance haalt. Maar ga je normaliseren per 100MB/s dan denk ik dat je niet tot grote verschillen komt.
Dit is wel het zwakke punt van ZFS; dit werkt dus niet helemaal zoals je wilt.
Het kan wel, je kunt gewoon een schijf toevoegen. Maakt niet uit hoe groot, hoe snel, je pleurt hem er gewoon in:
zpool add tank /dev/<nieuwe schijf>
Maar, dan voeg je hem toe als RAID0 / single disk. Zou die ene schijf falen, dan is je hele pool kapoet.
Anders gezegd: je kunt in ZFS geen bestaande array uitbreiden, maar wel een array toevoegen. Array is dan de naam die ik gebruik voor 'vdev'. Je kunt dus een 3-disk RAID-Z hebben en er later weer een 3-disk RAID-Z aan toevoegen. Of een 4-disk RAID-Z2 je bent niet gebonden aan een bepaalde configuratie.
In de praktijk betekent dit dus dat je uitbreid door in één keer een stoot schijven toe te voegen. Echter, als je goede bescherming wilt zoals RAID-Z2 dan kun je beter in groepjes van 6 of 10 schijven toevoegen. En dat is denk ik niet wat jij in gedachte had. Ik hoor je denken: meh
Bedenk wel, de voordelen die normaal RAID niet heeft:
- Je kunt in de toekomst schijven van andere grootte zoals 3TB, 4TB of 5TB toevoegen terwijl je nu nog 2TB schijven gebruikt. De extra ruimte kun je daadwerkelijk benutten, en niet zoals normaal RAID dat hij als 2TB disk behandeld wordt.
- Je benut de extra snelheid van de snellere 'nieuwere' schijven. Het ligt voor de hand dat als je uitbreid met nieuwere schijven deze sneller zijn. ZFS kan die extra snelheid benutten; normaal RAID beperkt.
- Je kunt de redundantie aanpassen (mixen van RAID-Z1/2/3, mirror, single disk)
- Bij het uitbreiden hoef je niet noodzakelijk de redundantie te verlagen, zoals je wel doet als je van een 3-disk RAID5 een 8-disk RAID5 maakt. Je voegt een nieuwe array toe ook weer met redundantie. Zo blijft je niveau van bescherming op peil naarmate je uitbreidt.
Wil je toch in kleine groepjes uitbreiden, dan kun je mirroring overwegen. Dat werkt wel gaaf bij ZFS, want:
- Je kunt beginnen met single disk, en deze daarna uitbreiden naar mirror
- Je kunt uitbreiden met een single disk, dus even 'onveilig' draaien, en later die mirror compleet maken
- Je kunt als je een disk nodig hebt tijdelijk een mirror een single disk maken, en later weer toevoegen
- Je behoudt de voordelen zoals hierboven genoemd, dat je snellere/grotere schijven kunt toevoegen
Nadeel is wel: een mirror biedt maar een enkelvoudig (gegarandeerde) bescherming. Dus 10 disks in een RAID10 (5 mirrors van elk 2 disks) is stuk zodra twee schijven in één mirror het begeven. Je kunt wel 3-way mirrors maken, maar ook dat wil je wellicht niet omdat je een 'economische' oplossing wilt.
Dus wat jij wilt is net niet de sweet spot van ZFS. Als je een poweruser was geweest die vele tientallen terabytes aan opslag wilde, dan was het een minder groot probleem omdat je dan juist wilt uitbreiden in groepjes van 6 of 10. In jouw geval moet je even kijken hoe ernstig dit zwakke punt is voor jouw concrete situatie.
. ZFS fans laten dat wel eens graag doorschijnen (zonder een flamewar te willen starten)
) en voor mdadm is erlegio informatie in dit topic.
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
/u/231803/ramdisk2.png?f=community)
/u/24671/crop55d1ea05b175b.png?f=community)
:strip_exif()/u/8077/jerney.gif?f=community)
/u/34550/crop5fb18601699ca_cropped.png?f=community)
:strip_icc():strip_exif()/u/254090/download.jpg?f=community)
:strip_exif()/u/24321/motor1.gif?f=community)
/u/102334/avatar_mini.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/27112/bierflesje_avatar.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/2985/compaqtux.jpg?f=community)
