Het grote ZFS topic

Het grote ZFS topic

ZFS; wat is dat?

ZFS ofwel Zettabyte FileSystem is een nieuw soort filesystem om bestanden mee op te slaan. ZFS verschilt enorm van andere filesystems, omdat het naast filesystem ook de functies van LVM en RAID engine verzorgt. We noemen ZFS daarom een hybride filesystem. Vrijwel alle bestaande filesystems werken op één storage device zoals een hardeschijf. Ze zijn niet gemaakt om meerdere hardeschijven aan te spreken. Daarvoor is een aparte RAID layer nodig die van meerdere schijven één schijf maakt en er vervolgens een filesystem op wordt geplaatst. Het filesystem is zich hierbij niet bewust van het feit dat zijn data op meerdere disks staat; die twee werelden zijn strict gescheiden. ZFS werkt heel anders; het spreekt direct meerdere schijven aan en integreert de functionaliteit van RAID, LVM en filesystem in één pakket. Dat heeft veel voordelen, voornamelijk op het gebied van betrouwbaarheid, maar zeker ook prestaties.

Zo zo... en wat zijn die 'voordelen' van ZFS dan?

ZFS is een 'next-gen' filesystem en heeft alleen Btrfs en ReFS als concurrenten. Btrfs is nog sterk in ontwikkeling en door de GPL licentie beperkt tot de Linux kernel. ReFS is het antwoord van Microsoft op de tekortkomingen van inmiddels behoorlijk gedateerde filesystems die we gebruiken, we noemen ze daarom legacy filesystems omdat deze eigenlijk gemaakt zijn voor een ander tijdperk. Alle platforms (Windows, Linux en UNIX) hebben dus hun eigen next-gen filesystem in de koker, maar ZFS is op dit moment het meest stabiel en volwassen en volledig production ready op meerdere besturingssystemen. Een overzicht van enkele voordelen van ZFS versus legacy filesystems: Checksums waken over de integriteit van je bestanden, en in het geval dat er toch corruptie plaatsvindt zie je precies welke bestanden dit treft. Nooit meer 'silent corruption' dus! Intelligente afhandeling van onleesbare sectoren (bad sectors) - deze worden automatisch gecorrigeerd door deze te overschrijven met redundante data indien beschikbaar. Met ZFS ben je vrijwel immuun voor het probleem van bad sectors wat steeds groter wordt met de stijgende datadichtheid. Self Healing; het on-the-fly automatisch repareren van corruptie en bad sectors, mits er voldoende redundancy beschikbaar is zoals in een mirror of RAID-Z configuratie. Dynamische stripesizes betekent dat ZFS niet kwetsbaar is voor de zogenaamde 'write hole'; ZFS kent geen read-modify-write. Dit is een technisch belangrijk voordeel van RAID-Z boven RAID5 wat grote voordelen heeft op gebied van betrouwbaarheid én random write prestaties. ZFS bewaakt de consistency van zijn filesystem en application data door transaction groups en ZFS Intent Log (ZIL); onverwachte stroomstoringen zouden nooit ZFS mogen beschadigen. ZFS kan één of meerdere SSDs inzetten als intelligente caching (L2ARC) wat vergeleken kan worden met de Smart Response Technology (SRT) van Intel, wat je ook in staat stelt om een HDD te cachen met een SSD. Het verschil is dat ZFS dit kan doen zonder de betrouwbaarheid aan te tasten; als je SSD corrupt raakt wordt dit opgemerkt en wordt er van de HDD RAID array gelezen, Intel SRT en andere oplossingen kunnen dit niet en dus is deze feature niet helemaal veilig, in tegenstelling tot ZFS waar L2ARC geen risico toevoegt. Snapshots zijn een verademing voor backups. Maak een snapshot en je kunt vrij rommelen, niet goed dan doe je een rollback. Het concept van een snapshot is al heel oud, maar de manier hoe het werkt bij ZFS maakt dat het gebruik ervan zeer flexibel werkt en heel economisch is met opslagruimte; alleen wijzigingen - de 'delta' - kosten opslagruimte. Zelf zou ik een aantal andere meer praktische argumenten aanvoeren: ZFS geeft je een betrouwbare RAID layer en zorgt dus dat je de foutgevoelige ouderwetse RAID layers volledig uitschakelt. Het filesystem zit 'direct' aan de disks en samen met checksums geeft dit je veel meer bescherming voor je bestanden. ZFS bespaart je kosten omdat je geen dure TLER-schijven hoeft te kopen, geen hardware RAID en UPS/BBU. Gewone desktopschijven werken prima met ZFS op een gewone non-RAID controller. ZFS kun je uitstekend als backup combineren. De snapshots zijn heel krachtig om incremental backups te maken. Het idee is dat je terug in de tijd kunt bladeren en zien hoe je bestanden toen waren. Dat is een krachtige feature om perongeluk deleted files of een virus die aan je bestanden knaagt af te dekken. ZFS laat je lekker flexibel met data omgaan en data erop pleuren en 'vergeten'; je hoeft er niet meer naar om te kijken. ZFS is heel onderhoudsarm dankzij de self-healing. Op een moment dat ZFS filesystemschade tegenkomt, repareert het dit vanzelf. Zijn er ook nadelen? ZFS draait niet onder Windows en niet in volle glorie onder Linux. Alleen onder Solaris/IllumOS en FreeBSD kun je spreken van eerste klasse implementaties die bewezen stabiel zijn en goed ondersteund worden met actieve ontwikkelaars. Wel is ZFS makkelijk toegankelijk middels speciale 'NAS' operating systems - waarover later meer. ZFS is erg hongerig naar geheugen, je kunt het vanaf 512MB RAM gebruiken, maar dan knijp je ZFS wel enorm. Pas boven de 4 gigabyte dus praktisch 8GiB wordt ZFS in alle glorie ondersteund met standaard prefetching enabled. Dit is overigens specifiek voor FreeBSD. Bij Solaris geldt dat ZFS hier beter werkt op systemen met weinig geheugen zoals 2GB. Deze bron meldt als Rule of Thumb 1GB per schijf plus wat je nodig hebt voor applicaties voor het Solaris platform. Je kan bij ZFS een bestaande RAID-Z (1/2/3) vdev niet uitbreiden met één of meer disks. Simpel gezegd: heb je een 4-disk RAID-Z dan kun je niet zomaar een disk bijpleuren en het een 5-disk RAID-Z maken - iets wat met traditioneel RAID wél kan: Online Capacity Expansion (OCE). Bij ZFS is het wel mogelijk om nieuwe vdev's toe te voegen. Nadeel is dus wel, dat je (vaak) in een keer een flink aantal disks moet kopen als je RAID-Z gebruikt. Bij mirrorring heb je dat probleem niet omdat je hier wel van een enkele disk een mirror kunt maken en andersom.

Maar ondersteunt ZFS nou RAID?

ZFS ondersteunt diverse opslagmethoden die erg vergelijkbaar zijn met RAID. Echter, geen enkele traditionele RAID engine kan nadoen wat ZFS doet, dus in die zin is het geen echt 'RAID'. De volgende schema's zijn beschikbaar: • RAID0 - striping: maximale performance, geen (extra) bescherming • RAID1 - mirroring: twee schijven met identieke data • RAID10 - striping+mirroring: een combinatie van hierboven (min. 4 schijven) • RAIDZ - enkelvoudige parity: vergelijkbaar met RAID5 • RAIDZ2 - tweevoudige parity: vergelijkbaar met RAID6 • RAIDZ3 - drievoudige parity: dit bestaat bij traditioneel RAID niet of nauwelijks

En wat is dat RAID-Z dan?

RAID-Z is een verbeterde vorm van RAID5 die alleen mogelijk is als RAID en filesystem niet gescheiden zijn, zoals normaliter het geval is. Omdat ZFS die twee combineert, kan een aantal belangrijke tekortkomingen van RAID5 worden voorkomen. Hierbij gaat het bijvoorbeeld om de RAID5 'write hole', en die komt weer door non-atomic read-modify-write cycles die nodig zijn als je naar RAID5 schrijft met een grootte anders dan de optimale full block size; veelal random writes dus. RAID-Z kent echter geen read-modify-write cycles omdat alle disks in elke write I/O worden betrokken. Dit kan alleen maar met een dynamische stripesize, en dat is dus een van de slimme voordelen van RAID-Z boven RAID5. RAID-Z is dus anders dan RAID5, maar het deelt wel de basis eigenschappen: • één disk mag uitvallen zonder gegevensverlies, twee disks betekent alles kwijt • de beschikbare opslagruimte is gelijk aan het aantal schijven minus parity schijven maal de grootte van de kleinste disk. Dus 4 schijven van 2TB in RAID-Z = 6TB bruikbare ruimte. RAID-Z2 is dan hetzelfde maar met twee parity disks, dus vergelijkbaar met RAID6. RAID-Z3 gebruikt zelfs drie parity disks voor extra veiligheid, wat in thuisomgevingen zeldzaam is. Het is vaak handiger om meerdere RAID-Z2's in een enkele pool te draaien dan één grote RAID-Z3.

Dus ZFS is software RAID? Is Hardware RAID niet beter?

ZFS is inderdaad softwarematige RAID, en dat heeft diverse voordelen. Veel mensen denken dat het veel aanslag pleegt op je CPU, maar zelfs een Atom CPU kan meer dan een gigabyte aan XOR instructies verwerken. XOR geldt als een makkelijke instructie en wordt in de praktijk beperkt door geheugenbandbreedte wat op moderne systemen tussen de 4 en 20 gigabyte per seconde ligt. Mensen die denken dat een XOR-engine nodig is voor goede performance, hebben teveel geluisterd naar de doctrine van de controllerfabrikanten. De voordelen van software RAID: Geen dure Hardware RAID controller nodig Geen Battery Backup Unit nodig (mits je filesystem een afdoende natuurlijke bescherming heeft zoals een journal of soft updates) Geen dure TLER-schijven nodig, zoals de WD RE series, die stukken duurder zijn alleen voor meer garantie en firmware die TLER mogelijk maakt. Door goedkope schijven te gebruiken kun je er meer van kopen dus meer storage en meer performance. (Wikipedia: Time-Limited Error Recovery) Onafhankelijk van de controller. Gaat je controller stuk met software RAID dan koppel je je disks aan een andere controller en je bent zo weer online. Gebruik van meerdere controllers. Je onboard SATA poorten zijn de best mogelijke poorten die je kan hebben, dus waarom die niet gebruiken? Je hebt er vaak max 6 en dus kun je zowel disks op je onboard controller als op een add-on controller aansluiten, en in dezelfde pool integreren. Zolang je controllers voldoende bandbreedte hebben is hier geen enkel bezwaar tegen qua performance. Hardware RAID weet eigenlijk niet of een block corrupt is, het kan alleen constateren dat een block niet in sync is. Vrijwel alle controllers gaan ervan uit dat de parity fout is en de originele data goed is, en corrigeren de parity in dat geval. Dit kan voor corruptie zorgen die niet gedetecteerd of gecorrigeerd wordt door traditioneel RAID; silent corruption. Software RAID zoals in ZFS kan dus dingen die hardware RAID nooit zou kunnen nabootsen, met cruciale verschillen tot gevolg.

Zo, nou ik ben overtuigd hoor! Waar kan ik dat ZFS krijgen?

Geen Windows, vanzelfsprekend. Er zijn drie platforms waar ZFS op draait: • Solaris (eerst van Sun, nu in de klauwen ehh handen van Oracle) • FreeBSD (opensource UNIX) • Linux (in beperkte mate en enigszins experimenteel) Solaris: Solaris is een heel degelijk UNIX besturingssysteem en ook de thuisbasis van ZFS. Sun was namelijk eigenaar van Solaris en ZFS voordat het werd overgenomen door Oracle. Oracle heeft aangegeven ZFS verder te zullen uitontwikkelen, maar het originele team achter ZFS is verdwenen met de overname. Beschikbare varianten: • Nexenta; een Ubuntu-achtig OS; gratis versie heeft standaard geen web-interface • napp-it; een uitgebreide web-interface voor Nexenta • EON ZFS Storage - embedded distributie • OpenIndiana Enterprise oplossing met ZFS. FreeBSD: FreeBSD is een veelal onbekend maar toch zeer geavanceerd besturingssysteem. FreeBSD heeft dankzij zijn licentie geen enkel probleem met ZFS integratie, en heeft het al vrij vroeg, met FreeBSD 7.0 geïntegreerd. Die versies waren nog expeirmenteel en instabiel. Vandaag de dag zitten we met een goed stabiele ZFS v15 en de nieuwe v28 code is al draaide op FreeBSD 9. Het grote voordeel van FreeBSD is dat je meer zekerheid hebt over de toekomst van ZFS op dit platform. Ook heeft FreeBSD een aantal beperkingen van het Solaris platform niet, en is de hardwaresupport beter, maar nog steeds minder goed dan Linux. Beschikbare varianten: • mfsBSD - een simpele LiveCD voor FreeBSD waarmee je ook direct op ZFS kunt installeren. • FreeNAS - een uitgebreid NAS besturingssysteem. De oude versie 0.7.x heeft wel oudere ZFS support en valt af te raden, maar de nieuwe 0.8.x versie beschikt wel over een stabiele en moderne ZFS versie. • ZFSguru - een nieuwe variant helemaal op ZFS gericht, nog erg in ontwikkeling maar heeft als grote voordeel dat er een volledige FreeBSD installatie achter zit, zonder dingen weggesnoeid zoals bij FreeNAS. Dit maakt het installeren van extra software makkelijker, wat bij FreeNAS toch een stuk lastiger is. Voor de nog ontbrekende features moet je terugvallen op de text shell, iets wat steeds minder nodig zal zijn naarmate ZFSguru zich verder ontwikkelt. CiPHER ontwikkelt sinds november 2011 mee aan dit project. ZFSguru kan beschouwd worden als gemakkelijkste all-in-one ZFS oplossing. • NAS4Free Het open-source broertje van FreeNas die gemaakt is nadat FreeNas in de handen van ixSystems is gekomen. Bijna dezelfde functionaliteit, maar niet meer gebaseerd op nanoBSD, en dat kan in de toekomst nog wel eens voordelen opleveren. Linux: Linux is een uitstekend allround besturingssysteem, maar de GPL-licentie is helaas slecht cq. niet verenigbaar met de licentie van ZFS, de CDDL. Dit heeft tot gevolg dat ZFS alleen via een omweg beschikbaar is op het Linux platform. Deze oplossingen zijn lang niet even stabiel en volwassen genoeg om buiten testdoeleinden te gebruiken. Beschikbaar zijn: • ZFS-on-Fuse • ZFS Linux kernel modules (zelf compileren) • Debian GNU/kFreeBSD - zeg maar linux zonder linux kernel, pervers nietwaar?

Allemaal mooi en aardig, maar ik gebruik Windows!

Het idee is dat je een aparte computer (NAS) bouwt waar ZFS op draait, en dit via Samba, NFS of iSCSI exporteert naar je Windows, Apple of Linux desktop pc. Windows zelf heeft geen idee van ZFS, maar kan bestanden wel opslaan via CIFS (Samba) en/of andere protocollen. Gevolg is wel dat je een aparte dedicated computer bouwt alleen voor ZFS opslag. Je kunt het ingewikkelder doen door met virtualizatie te gaan werken, maar dat zou ik alleen doen als je daar bekend mee bent.

En hoe bouw ik zo'n ZFS NAS dan?

Met je handen. Nee serieus: het is heel makkelijk. Je kunt in Het grote DIY RAID NAS topic deel 3 je eigen build bediscussiëren of een eigen topic aanmaken als je een uitgebreide build wilt bespreken met veel vragen. Om je wel een idee te geven wat er mogelijk is, worden hier twee builds gepresenteerd. Eentje die best te overwegen is - de Instap NAS - en een dure luxe build waar we van dromen - in elk geval de hoeveelheid disks. In de praktijk zal jouw build dus tussen deze twee uitersten liggen. Instap ZFS NAS Processor: onboard AMD C60 dualcore Brazos (passief gekoeld) Moederbord: Asus moederbord met AMD C60 Brazos CPU: pricewatch: Asus C60M1-I Geheugen: 1x8GiB DDR3. Door één reepje te nemen kun je altijd uitbreiden naar 2x8GiB. 8GiB reepjes worden officiëel niet ondersteund, maar die werken wel! Hardeschijven: 3x pricewatch: Seagate Barracuda 7200.14 ST3000DM001, 3TB Krachtige ZFS NAS Processor: Intel 3570 (geen K versie want deze ondersteunt geen vt-d instructies voor PCI passthrough) Moederbord: één van de vele bordjes met 70-series chipset Geheugen: 4x 8GiB DDR3 dus 32GiB minimaal Controller: 2x IBM M1015 betekent 2x 8 = 16 schijven totaal aansturen met de twee controllers + onboard SATA dus meer dan 20 disks. Hardeschijven: 20x pricewatch: Seagate Barracuda 7200.14 ST3000DM001, 3TB verdeeld over 2x 10-disk RAID-Z2 in één pool Solid State Drives: 1x Intel 320 voor Dedicated ZIL en een Crucial M4 / Samsung 830 of reguliere consumenten SSD voor L2ARC caching. Deze dien je te gebruiken op de onboard SATA van de chipset (AHCI). Last but not least: 10 Gigabit networking

Kan ik met ZFS mijn array uitbreiden zoals met RAID5 veelal kan?

Nee, dit is een belangrijke beperking van ZFS die voor thuisgebruikers vaak als hinderlijk wordt aangemerkt. ZFS kun je echter wel uitbreiden, maar dat werkt heel anders. Dit heeft echter ook voordelen die RAID5 weer niet heeft, dus lees dit even goed: Als je een RAID-Z hebt van 5 disks, kun je die niet zomaar met een paar disks uitbreiden naar een 7-disk RAID-Z bijvoorbeeld. Een RAID-Z heeft dus een vast aantal schijven wat je niet kunt veranderen. Wat kan wel? Bij mirroring (RAID1) kun je altijd schijven toevoegen en weer verwijderen uit een mirror vdev. Voeg je een schijf toe aan een 2-disk mirror, dan wordt het een 3-disk mirror waarbij alle drie de disks dezelfde data opslaan. Verwijder je een disk van een 2-disk mirror, dan wordt de resterende 'mirror' disk een normale enkele disk. Die kun je vervolgens weer tot mirror omtoveren door een schijf toe te voegen. Mirrors kunnen dus wat RAID-Z niet kan. De gebruikelijke manier van uitbreiden is dat je een nieuwe vdev ofwel array naast de al bestaande RAID-Z vdev plaatst. Dus bijvoorbeeld weer een 5-disk RAID-Z erbij plaatsen. De beschikbare ruimte van alle vdevs is als één eenheid beschikbaar binnen een ZFS pool. In de praktijk betekent dit dat je schijven in groepjes toevoegt in plaats van elke keer één schijf erbij. Ook betekent dit dat je elke keer een extra schijf aan parity protection kwijt bent, maar dat heeft wel als voordeel dat je bescherming op peil blijft naarmate je uitbreidt en niet steeds minder wordt. ZFS kan weer dingen die traditioneel RAID niet kan. Zoals: je kunt in de nieuwe RAID-Z vdev die je gaat toevoegen, schijven met een andere grootte gebruiken, een ander aantal of ander RAID-level dan de eerste array. Zo kun je nu beginnen met 2TB schijven en later 3TB en weer later 4TB gebruiken en zit je dus niet vast aan een bepaalde grootte. Alle vdevs in een pool worden gestriped, zeg maar RAID0. Maar omdat het geen echt RAID is, kan ZFS leuke trucjes toepassen. Stel je eerste array doet 200MB/s maar je nieuwe array met modernere schijven doet 400MB/s, dan zou je bij traditioneel RAID 2x200 = 400MB/s krijgen. ZFS doet echter aan load balancing en laat elke vdev lopen op de snelheid die hij aankan door simpelweg meer data te schrijven naar die vdev. Veelal geldt hoe groter de opslagruimte des te hoger de performance dus dit gaat ook mooi op met het feit dat ZFS meer data schrijft naar de snellere (en verondersteld grotere) array. Praktisch is: Je begint met een 5-disk 2TB in RAID-Z, je breidt die later uit met nog eens 5 schijven maar dan 3TB ook in RAID-Z. De beschikbare ruimte is 4*2TB=8 + 4*3TB=12 is samen dus 8+12=20 terabyte. Je bent dus 2TB+3TB=5TB kwijt aan parity. Je begint met een 6-disk 3TB RAID-Z2 met goede bescherming, maar wilt later nog wat extra ruimte. Je kunt dan bijvoorbeeld 3 disks 4TB in RAID-Z plaatsen voor 8TB extra opslagruimte. Je kiest voor mirroring en kunt altijd een schijfje bijprikken. In groepjes van twee of zelfs één schijf en later die tot mirror promoveren. Bedenk wel dat je hele pool stuk is als één mirror vdev stuk is. Dus draaien met een enkele schijf is wel een risico. Verder moet je weten dat ZFS niet direct de data herverdeelt wanneer je je pool uitbreidt met een nieuwe RAID-Z array/vdev bijvoorbeeld. De data blijft staan waar hij staat. Alleen nieuwe data die geschreven wordt, wordt over alle vdevs verdeeld dus ook de nieuwe. Je kunt dit voor bestaande data forceren door de directory een andere naam te geven en dan te kopiëren naar de originele naam. Doordat je de data opnieuw schrijft, wordt deze over alle vdevs verdeeld en krijgt het dus extra snelheid van de nieuwe vdev als je dat nodig acht.

Ik heb gehoord dat je ZFS moet optimaliseren voor 4K Advanced Format hardeschijven?

Dat klopt, voor moderne Advanced Format hardeschijven die 4K sectoren hebben, wil je het liefst ook dat ZFS met deze eenheden werkt. Echter, omdat dergelijke hardeschijven doen alsof ze normale 512-byte sector schijven zijn door hun sectorsize te emuleren, ziet ZFS niet dat je dergelijke schijven hebt. Dit zul je dit wel moeten forceren middels de ashift setting. Dit is een vdev property maar geldt pool-wide. Dat betekent dat een bestaande pool nooit meer van ashift instelling kan veranderen. Ashift=9 wil zeggen dat de pool optimaal is voor 2^9= 512 bytes sectoren. Ashift=12 wil zeggen 2^12= 4K sectoren geoptimaliseerd. Optimale configuraties voor 4K sector Advanced Format hardeschijven: RAID-Z: 3, 5 en 9 disks RAID-Z2: 4, 6 en 10 disks RAID-Z3: 5, 7 en 11 disks De gedachte hierachter is dat het aantal 'dataschijven' een macht van 2 is, dus 2, 4, 8, 16. Waarom? Omdat je dan een 'schoon' getal krijgt wanneer de 128KiB recordsize wordt gedeeld door het aantal schijven. Voorbeeld: RAID-Z met 3 schijven betekent dat er twee dataschijven zijn en één parityschijf. Met een 128KiB recordsize krijgen de schijven dan 64KiB te verwerken en dat is optimaal omdat dit een veelvoud is van 4 kilobyte - de sectorsize van moderne Advanced Format hardeschijven. Echter, heb je 4 schijven in RAID-Z dan moet die 128KB verdeeld worden over 3 schijven. Dat wordt 42.7KB per schijf. Dit betekent dat je net wat minder opslagruimte hebt omdat je het verschil tussen 42.7K en 43.0K niet kunt gebruiken (slack) maar nog belangrijker is 43K niet een veelvoud van de 4K sector size die moderne Advanced Format hardeschijven hebben. Laatstgenoemde configuratie is dus niet optimaal wat zorgt voor tragere writes. De performancedegradatie is afhankelijk van platform en hoe goed/snel de firmware van je hardeschijven sectoren kunnen emuleren. Zo zijn nieuwere type WD EARS schijven veel sneller in sector emulatie dan de klassieke 4-platter modellen.

ZFS kan ook mijn SSD gebruiken voor caching en andere versnelling?

Dat klopt, je kunt een SSD gebruiken voor drie dingen: • Een normale pool met SSDs als disk members, leuk voor systeempool en opslag van VM images en andere zaken waar je random I/O performance voor nodig hebt • Een HDD pool waar je een SSD (partitie) als L2ARC cache device toevoegt. De SSD zal dan snippertjes data verzamelen die random worden opgevraagd, wat veel sneller is dan de HDDs laten seeken. • Een HDD pool waar je een SSD (partitie) als SLOG ofwel Dedicated ZIL toevoegt. SSD in een normale pool gebruiken Je kunt SSDs prima in een RAID0 pool of een RAID-Z pool gebruiken. Denk aan opslag van VM images, als systeemdisk en andere zaken waarvoor je IOps performance nodig hebt. SSDs hebben minder last van de performancebeperkende eigenschappen van RAID-Z omdat SSDs vooral transfer-capped zijn. Dit betekent dat SSDs in een RAID-Z pool goed zou moeten presteren. SSDs als L2ARC cache device Door een SSD (partitie) aan een ZFS pool toe te voegen, zal deze gebruikt worden om bepaalde data op te slaan - te cachen. Wordt bepaalde data herhaaldelijk opgevraagd, dan zal deze voortaan vanuit de SSD geleverd worden in plaats van dat je je hardeschijven laat seeken. Dit werkt ongeveer zoals Intel SRT caching toevoegt op het Windows platform. Belangrijke eigenschappen van caching: • ZFS L2ARC caching is veilig in gebruik, in tegenstelling tot alternatieven zoals Intel SRT wat corruptie op de SSD niet kan detecteren. ZFS doet dat wel en leest in dat geval van de HDD pool ipv de SSD. L2ARC is dus altijd veilig in gebruik. • ZFS cached geen grote bestanden die sequentiëel worden opgevraagd; denk aan grote bestanden die van A tot Z worden uitgelezen. Dat kunnen hardeschijven prima en daarvoor zal de cache device niet gebruikt worden! Alleen zogenaamde non-contiguous reads ofwel random reads zullen op de SSD terecht komen. Dit kunnen kleine bestanden zijn, maar ook enorm veel fragmenten in grote bestanden. ZFS cached dus geen bestanden, maar datafragmenten. Dus de cache werkt ook prima op 20GB grote databestanden van je favoriete game, mits dat spel aan random reads doet. Een voorbeeld hiervan is World of Warcraft. • Caching werkt alleen effectief als je een voorspelbaar gebruikspatroon hebt. Als je werkelijk willekeurig I/O zal doen, zal caching geen of nihil voordeel opleveren. Alleen als je herhaaldelijk dezelfde data raadpleegt, zal caching merkbare winst kunnen opleveren. Dit is vaak wel het geval. • Caching geldt niet alleen voor de daadwerkelijke data, maar zeker ook voor metadata. Denk bijvoorbeeld aan random reads bij het openen van een grote directory met een heleboel bestanden. Het cachen van metadata wordt vaak over het hoofd gezien, maar telt zeker mee! • L2ARC cache moet eerst worden opgebouwd; en wordt beperkt door de snelheid waarmee ZFS de SSD 'mag' vullen, dat is namelijk bewust gelimiteerd. Het kan dus een paar weken duren voordat je L2ARC op oorlogssterkte is. SSD als SLOG device ofwel dedicated ZIL Bij ZFS is de ZIL ofwel ZFS Intent Log vergelijkbaar met de journaling log van NTFS en Ext3. De ZIL is standaard ingeschakeld voor alle pools ook met een enkele disk en beschermt voornamelijk tegen het recoveren van recente writes vlak voor een stroomstoring of crash. Je hebt een ZIL niet strict nodig; ook zonder ZIL is ZFS consistent. Je zult alleen wel tot enkele minuten data verliezen evenals application consistency; later daarover meer. Veel mensen zeggen dat ze een 'ZIL' toevoegen aan een pool. Dat is echter technisch incorrect. Je doet juist het tegenovergestelde: je schakelt de ZIL uit die op de pool staat en ook bescherming heeft die de pool zelf heeft, zoals RAID-Z. In plaats daarvan gebruik je een apart apparaat als ZIL, in een mirror configuratie of zonder bescherming. Dat is dus vrijwel altijd een achteruitgang op gebied van bescherming, al stelt dat niet zoveel voor. Maar belangrijk om te beseffen dat elke pool standaard een ZIL heeft inclusief de bescherming die de pool zelf heeft, en dat je met een dedicated ZIL ofwel SLOG (separate LOG device) die bescherming in feite outsourced aan een SSD die daar veel sneller in is. Een ZIL heb je dus normaliter altijd. In tegenstelling tot L2ARC caching is een dedicated ZIL juist wél gevaarlijk, omdat je zoals gezegd dus een bescherming van de pool zelf uitschakelt. Daar zit hem ook de snelheidswinst: je laat je hardeschijven niet meer de ZIL functie uitvoeren met random writes maar laat een SSD (partitie) die functie uitvoeren. Een ZIL wordt alleen beschreven en nooit gelezen tenzij na een stroomstoring/crash; alleen dan zijn de gegevens nodig. Kan ik een of meerdere SSD's voor meerdere taken gebruiken? Jazeker. Je kunt een SSD partitioneren en gebruiken voor alle doeleinden die je wilt: - systeem pool voor booten en wat niet - L2ARC cache voor je grote HDD pool - SLOG voor je grote HDD pool Met meerdere SSDs wil je alle taken spreiden over alle SSDs. Wat je niet wilt is een SSD helemaal voor SLOG gebruiken en de ander helemaal voor L2ARC. Dan worden ze ongelijkmatig belast en haal je geen performancevoordeel wat je anders wel zou hebben. Je wilt dus juist de taken gelijkmatig verdelen over al je SSDs. L2ARC doe je altijd in striping (RAID0) terwijl SLOG je voor mirroring kunt kiezen. Hoe groot moet ik de partities dan maken? Stel je heb twee SSDs van 128GB, dus totaal 256GB. Op je SSD maak je dan partities aan zoals: - partitie 1 voor systeem/boot pool: 28GiB - partitie 2 voor L2ARC cache: 60GiB - partitie 3 voor SLOG: 4GiB - rest van de ruimte onbenut laten als overprovisioning (let op: de SSD mag niet gebruikt zijn anders gaat deze ruimte verloren! secure erase of TRIM erase gebruikte SSDs alvorens overprovisioning toe te passen). Doe dit voor beide SSDs en je hebt: - een systeem/boot pool in mirror configuratie 28GB beschikbare ruimte - L2ARC caching met twee partities in striping = 2x 60 = 120GB - SLOG in mirror met twee partities = 4GB

Verder lezen

• Wikipedia: ZFS

CiPHER wijzigde deze reactie 29-10-2012 22:57 (255%)
Reden: L2ARC en SLOG toevoegd

Hoe werken bad sectors en SMART?


Current Pending Sector = actieve bad sectors = sectoren waarvan de hardeschijf weet dat ze onleesbaar zijn. Deze sectoren zijn zichtbaar voor de host (het operating system) en als deze ze proberen te lezen, zal dat tot lange timeouts leiden en dat kan veel gezeik opleveren; om die reden is soms TLER nodig afhankelijk van wie er aan de disk zit (een hardware RAID controller, windows onboard RAID drivers of véél geavanceerder BSD UNIX met progressive timeouts).

Reallocated Sector Count = passieve bad sectors = sectoren die zijn omgewisseld door de hardeschijf door reserve sectoren. Deze kunnen niet langer problemen veroorzaken. Deze zijn mogelijk in het verleden pending sectoren geweest, ofwel weak sectors die preventief vervangen zijn door de hardeschijf. Dat laatste betekent dat je er nooit last van hebt gehad. Passieve bad sectors kunnen nooit meer problemen veroorzaken omdat de host (operating system) ze niet kan zien. Wat je niet ziet, is er niet.

UDMA CRC Error Count = kabelfouten, of eigenlijk: datacorruptie gedetecteerd door CRC error[u]detectie[u] (níet correctie!).


Toelichting
Bovenstaande drie SMART attributen zijn het meest belangrijk. Helaas zijn de beschikbare utilities die SMART uitlezen heel slecht geschreven en krijg je en milde waarschuwing of een geel bolletje bij een actieve bad sector, terwijl dat een heel ernstig defect is waarbij een enkele onleesbare sector voor veel ellende kan zorgen. Sterker nog, ik ze stelling zou durven geven dat de meeste RAID arrays stukgaan door precies dit probleem, en niet door disk failures waar iedereen aan denkt bij de bescherming die RAID biedt.


Hoe werken bad sectors?

1. Bij een read request van de host (operating system) naar een bepaalde sector (LBA) komt de schijf erachter dat deze sector niet leesbaar is. Niet leesbaar betekent dat de data die de leeskop uit de magnetische lading kan destilleren bitfouten bevat die het corrigerende vermogen van ECC bitcorrectie overstijgt. Volgens de ATA standaard is het verboden voor hardeschijven om data waarvan de schijf wéét dat deze corrupt/onjuist is, terug te sturen naar de host. Oeps! En nu?

2. De hardeschijf zal blijven proberen de sector te lezen en probeert door verschillende seekafstanden en snelheden vanaf de landing zone toch een keer de gegevens uit te lezen. Als dit een keer wel lukt - waarbij de ECC net voldoende is om de data corruptievrij uit te lezen - dan haalt de schijf opgelucht adem. De data gaat retour naar de host die al een tijd zit te wachten, en de schijf kijkt wat er nu verder moet gebeuren. Oude schijven vervangen deze sector door één van de vele reservesectoren. Moderne schijven proberen eerst de sector opnieuw te beschrijven met dezelfde data. Als de sector daarna correct uitgelezen kan worden, wordt hij niet vervangen. Dit gebeurt héél vaak bij moderne hardeschijven. Er is in dat geval helemaal geen fysieke schade, maar simpelweg onvoldoende ECC bitcorrectie. Dit is hoe de schijf is ontworpen(*), namelijk met een uBER-specificatie van 10^-14 wat betekent dat een hardeschijf bij een aantal keer alle sectoren uitgelezen te hebben gemiddeld één sector niet kan lezen.

3. In geval dat de bad sector onleesbaar blijft, blijft ook het probleem bestaan. Dan krijg je Current Pending Sector die met één wordt verhoogd. Het operating system zal - als deze over enige intelligentie beschikt - een ATA RESET commando sturen en een paar keer opnieuw proberen. Dit zal waarschijnlijk telkens mislukken. In Windows ervaar je dit als een hangend systeem waarbij soms ook de cursor blijft staan. Uiteindelijk krijg je een blauw scherm en/of een spontane reboot.

4. Zodra je als gebruiker het zat bent en de schijf formatteert met Windows 7 of hoger, zullen alle sectoren overschreven worden met nullen (XP doet dit NIET!). Alle sectoren, dus ook die ene onleesbare sector. Zodra je een actieve bad sector overschrijft, verdwijnt het probleem. Immers: de schijf zal geen moeite meer doen de oude gegevens te lezen. De schijf zal de bad sector overschrijven en kijken of de gegevens vervolgens gelezen kunnen worden. Is dat niet zo (fysiek beschadigde sector) dan wordt hij omgewisseld en wordt de Reallocated Sector Count verhoogd met één. Als er geen fysieke schade is, verdwijnt de Current Pending Sector uit de SMART-data en is simpelweg ieder bewijs vernietigt dat je ooit problemen had. Dat laatste vind ik erg jammer. Bewijs vernietigen is een doodzonde.


Hoe reageert een slechte controller op bad sectors?
Het grote probleem is hoe het operating system of RAID controller reageert tijdens de periode dat de hardeschijf probeert een sector te lezen die onleesbaar is. Dat kan tot 120 seconden duren. RAID controllers pikken dit vaak niet en schoppen de schijf uit de RAID array als deze langer dan 10-15-20 seconden niet reageert op een I/O request. Dat is enorm dom en slecht design en heeft enorm veel mensen hun data gekost!

Hoe reageert een slechte controller op bad sectors met een TLER-enabled hardeschijf?
TLER houdt in Time-Limited Error Recovery en doet niets anders dan voortijdig opgeven. Geen 120 seconden proberen de sector te lezen maar typisch na 7 seconden opgeven. Dit voorkomt dat de schijf uit de array wordt geknikkerd. Althans, zelfs dat is niet altijd zo. Maar voor de meeste controllers wel. Je RAID controller stuurt meestal domweg een I/O error terug en gebruikt niet zijn redundantie om de gegevens te destilleren, wat theoretisch wel kan. Ik ken geen controllers die dit doen namelijk. Areca hardware RAID met v1.42 firmware doet dit in elk geval niet.

Hoe reageert een goede controller op bad sectors?
In elk geval NOOIT de schijf detachen/onzichtbaar maken. Normale operating systems zonder RAID zouden blijven proberen de sector te lezen. Als deze onleesbaar blijft en de bad sector was nodig voor het operating system, kan het operating system wel crashen (zoals Windows doet als het je C: is). Dat is niet anders.

Een heel goed operating system, zoals BSD UNIX, gebruikt progressive timeouts. De timeout blijft eerst laag zoals 5 seconden. Als een schijf niet binnen die tijd reageert, volgt een ATA RESET commando en daarna wordt de sector weer opnieuw gelezen. Even overnieuw dus. Lukt het nog niet, dan probeert hij het na 10 seconden weer. Die tijd wordt telkens verhoogd totdat het operating system het opgeeft en een I/O error naar de applicatie stuurt.

Hoe reageert ZFS op bad sectors?
Het allerbeste is natuurlijk ZFS. Met dit hybride filesystem-RAID-engine ben je vrijwel immuun voor bad sectors. Hoe werkt dat dan? Nou simpel, zelfs met een enkele schijf zonder redundantie (geen RAID1 of RAID5) heb je redundante metadata. Het filesystem kan dus vrijwel nooit kapot raken door bad sectors, hooguit dat files ontoegankelijk worden. Dan kun je ook precies zien welke file en kun je die gewoon verwijderen of uit backup terughalen. Prima.

Bij redundante pools zoals RAID1 of RAID5/6/7 gaat ZFS zijn ballen laten zien. Onleesbare sector? Haha, zielig schijfje, zal ik jou eens van jouw probleempje afhelpen? Hier heb je de gegevens die in de bad sector stond. Dat weet ik omdat ik van een redundante bron lees: RAID ofwel ditto copies. Dus wat doen we? We overschrijven de bad sector met de data die daar hoorde te staan. Dat gebeurt direct na de eerste timeout. Het probleem is dan gelijk opgelost: door het overschrijven van de bad sector zal deze ofwel verdwijnen ofwel worden omgewisseld. Dit alles zonder dat de gebruiker of applicatie ooit problemen ondervindt. Bovendien kun je zien dat dit gebeurt doordat ZFS een read error aangeeft in de status output.

In normale situaties geldt dat ZFS immuun voor bad sectors is. Alleen als op meerdere schijven bad sectors zitten die precies op de 'verkeerde' plek zitten, krijg je problemen. De kans hierop is astronomisch klein. Zoiets als je gooit een steen tientallen meters weg en bij de tweede keer dat je dat doet komt hij precies op dezelfde plek neer. Dat is extreem toevallig.




Moraal van het verhaal?
Ouderwetse opslagtechnieken zoals legacy RAID engines en legacy filesystems (FAT, NTFS, Ext2, Ext3, Ext4, UFS, XFS, JFS, ReiserFS) bieden totaal geen bescherming tegen bad sectors. Dat is onacceptabel zeker omdat het probleem van bad sectors steeds groter wordt. Dit heeft te maken met dat de hoeveelheid bitfouten - uitgedrukt in de uBER-specificatie - gelijk blijft terwijl de datadichtheid blijft toenemen. Relatief gezien komen bad sectors daarom steeds vaker voor. Ik gelijk nu gemiddeld één bad sector per 3 tot 5 keer de schijf van A tot Z uitlezen. Dit soort specificaties gaat enkel op als je zeer grote hoeveelheden schijven gaat testen. Met een enkel exemplaar kun je alle kanten uit.

En dus, hoe bescherm ik mijn data?
Gebruik ZFS of een ander next-generation filesystem (ReFS en Btrfs zitten in de koker). Alleen die zijn geschikt voor de opslagtechniek van vandaag. Tot die tijd zul je backups moeten gebruiken om je data te beschermen. We zitten nu dus in een tijdperk dat de software achterloopt op de hardware. Microsoft en Linux hebben dus een groot probleem. UNIX is goed voorzien met ZFS en zit er comfortabel en warmpjes bij.

CiPHER wijzigde deze reactie 02-12-2012 00:36 (99%)

*gereserveerd2*

*gereserveerd3*

ziet er goed uit mannen !


hier nog wat losse zfs flodders :

Building your own ZFS fileserver
ZFS Evil Tuning Guide
ZFS Best Practices Guide
A Home Fileserver using ZFS
Home Fileserver: A Year in ZFS
Mirrored SSD ZFS root boot
NexentaStor Community Edition 3.0.4
OpenIndiana Wiki Home
OpenIndiana download

-
open source monitoring pakketten (zabbix)
benchmarks (bonnie++)
-
on twitter
http://twitter.com/OpenIndiana
http://twitter.com/FreeNas
http://twitter.com/nexenta
http://twitter.com/freebsd

borroz wijzigde deze reactie 31-03-2011 06:34 (131%)

het werd inderdaad wel eens tijd voor een eigen topic!
mooie intro. misschien kan je het verhaal van 4kb schijven ook nog toevoegen?
Recommended pool sizes voor RAID-Z : 3, 5, or 9 disks. In RAID-Z2, 6 or 10 drives.

En ook iets over caching en ZIL erbij misschien

Kinkt mooi. Ik kende het eigenlijk nog niet..

Nu de key question die ik nog niet direct terug kan vinden.
Wat is nou het voordeel van raidz versus de standaard linux software raid5 (mdadm)?

Ik heb momenteel een multi purpose thuisserver (web,mail,file,mediastream) met ubuntu 10 en 1pata os disk en 3 sata 1,5tb in raid5 (software raid) en ga die bak dit jaar ombouwen. Ik wil de taken wat scheiden dus ik ga er esxi opzetten en meerdere vm's die weer draaien op aparte storage vm die weer 2 pools krijgt (bestaande 3x1,5 en nieuwe 3x2tb erbij). Ik zou dus de storage vm met zfs kunnen maken als jullie me kunnen overtuigen dat ik dat wil

Er zijn eigenlijk een belangrijke verschillen bovenop alle dingen die ZFS al meebrengt (zoals ingebouwde fout checks): performance is doorgaans beter omdat het bekende "write hole" probleem zich bij RAIDz niet voordoet. Hier meer info.

Vergeet ook niet de andere leuke ZFS features, zoals snapshopts, compressie en deduplicatie

voodooless wijzigde deze reactie 29-03-2011 22:32 (14%)

quote:

Danfoss schreef op dinsdag 29 maart 2011 @ 22:20:
Kinkt mooi. Ik kende het eigenlijk nog niet..

Nu de key question die ik nog niet direct terug kan vinden.
Wat is nou het voordeel van raidz versus de standaard linux software raid5 (mdadm)?

Ik heb momenteel een multi purpose thuisserver (web,mail,file,mediastream) met ubuntu 10 en 1pata os disk en 3 sata 1,5tb in raid5 (software raid) en ga die bak dit jaar ombouwen. Ik wil de taken wat scheiden dus ik ga er esxi opzetten en meerdere vm's die weer draaien op aparte storage vm die weer 2 pools krijgt (bestaande 3x1,5 en nieuwe 3x2tb erbij). Ik zou dus de storage vm met zfs kunnen maken als jullie me kunnen overtuigen dat ik dat wil

Er zijn meerdere voordelen, maar een van de belangrijkste is de self healing functie.
Waar bij RAID5 onder MDADM na een bad block op een disk er een complete resycn gedaan moet worden op een nieuwe disk, kan zfs gewoon de sector reallocaten naar een werkende sector.

Ander voordeel is dat het met checksums werkt (maar ik geloof dat een bitmap redelijk gelijk is onder mdadm) hierdoor kan er heel snel gezien worden of een block nog intakt is (zonder het hele blok in te hoeven lezen).

Wat jij wil kan prima met ESXi, gewoon RDM's (Raw Device Mappings) maken van de disks in je server en die weer aan je ZFS vm geven. In je vm maak je de 2 pools aan. Deze worden dan door een soort RAID0 truuk gecombineerd gebruikt waardoor je ook nog een leuke performance krijgt vergelijkbaar met RAID50, maar wel iets langzamer omdat ZFS de data in verhouding over de vdev's gaat verspreiden (verhouding is ongeveer 3:4).

Bedenk wel zelf goed waarom je ZFS wil, de software erachter is niet voor iedereen even gemakkelijk.
Solaris is flink anders dan Unix en FreeBSD heeft ook zo zijn eigenaardigheden.

FreeNAS is wel weer leuk, maar niet echt een compleet OS.

Bovenstaande heeft eigenlijk niks met RAIDz te maken, maar is gewoon een feature van ZFS die op alle redundancy levels beschikbaar is.

quote:

voodooless schreef op dinsdag 29 maart 2011 @ 22:36:
Bovenstaande heeft eigenlijk niks met RAIDz te maken, maar is gewoon een feature van ZFS die op alle redundancy levels beschikbaar is.

True RAIDz is is in zijn eigen functie wat dat betreft ook niet heel anders dan MDADM RAID5.

Het werkt namelijk beide gewoon met parity
RAIDz is wel sneller omdat het met een dynamische stripesize werkt waar MDADM met een vaste stripesize werkt.

Dat is niet alleen het voordeel. Copy-on-write zorgt ervoor dat je geen RAID5 write hole hebt. Dat betekend dus dat je geen full stripe writes meer nodig hebt, wat met name random write performance ten goede komt. Random writes op een raid5 zijn veelal niet veel beter dan je op een enkele disk zou halen. RAIDz kent dit probleem dus niet.

voodooless wijzigde deze reactie 29-03-2011 22:46 (42%)

Ik ben overtuigd
Ik ga een plan opzetten voor mn operatie. Grootste uitdaging zal zijn hoe 3tb te backuppen. Maar dat is niet voor dit topic.

Waarom staat dit niet in NOS?

Dit is de HK niet.

Darkstone wijzigde deze reactie 29-03-2011 23:59 (87%)

quote:

Danfoss schreef op dinsdag 29 maart 2011 @ 23:10:
Ik ben overtuigd
Ik ga een plan opzetten voor mn operatie. Grootste uitdaging zal zijn hoe 3tb te backuppen. Maar dat is niet voor dit topic.

en dat probleem wordt alleen maar groter merk ik zelf ook ..

quote:

Danfoss schreef op dinsdag 29 maart 2011 @ 22:20:
Kinkt mooi. Ik kende het eigenlijk nog niet..

Grapje hoor.

quote:

Nu de key question die ik nog niet direct terug kan vinden.
Wat is nou het voordeel van raidz versus de standaard linux software raid5 (mdadm)?

Dat is een goede vraag! Allereerst kun je stellen dat Linux mdraid5 een degelijk traditionele RAID5 engine is die veilig is en goed performt.

Maar wat voor filesystem gooi je erop? Alle normale filesystems (buiten Btrfs en ZFS) hebben geen checksums. Dat betekent dat als er corruptie optreedt, een of meer bestanden corrupt kunnen raken. Blipjes in mp3tjes en filmpjes zijn nog tot daar aan toe, maar in data files kan dit funest zijn. Dan heb ik nog niet gesproken als filesystem metadata corrupt raakt, dan ben je vaak nog niet jarig.

Corruptie kan vele oorzaken hebben, maar cruciaal is dat je op de hoogte bent van corruptie. Bij normale filesystems is dat niet zo; je moet maar hopen dat je bestanden goed blijven. Het werkt allemaal goed, totdat. Bij ZFS is het voordeel dat je een zeer goede bescherming tegen corruptie hebt, en in het geval dat het zich toch voordoet dan weet je dat omdat ZFS je dankzij de checksums precies kan vertellen welke bestanden zijn aangetast. ZFS heeft ook redundante metadata, dus zelfs op een enkele disk zonder RAID bescherming heb je al redundante metadata, wat er voor moet zorgen dat het filesystem te alle tijde intact blijft.

Dus ZFS kun je vooral zien als extra bescherming voor je bestanden, en coole features die voor extra performance en veiligheid (snapshots, ditto blocks) kunnen zorgen. Voor de poweruser cq. tweaker die hoge eisen stelt aan performance én betrouwbaarheid is ZFS wel het beste wat er is.

ZFS met XFS of JFS of Ext4 vergelijken is dan ook onzin; alle laatstgenoemden zijn simpele NTFS-achtige filesystems zonder noemenswaardige features die je veiligheid significant vergroten. Ze pakken alleen het probleem van power loss anders aan. De enige echte concurrent voor ZFS is Btrfs - eveneens eigendom van Oracle, maar dit is alleen een filesystem zonder het RAID gedeelte. Vooralsnog is ZFS dus uniek, en daarom dat het enorm in opkomst is juist ook voor (gevorderde) thuisgebruikers die hoge eisen stellen.

En we hoeven de moeilijkheid ook weer niet te overschatten, als je linux raid kunt instellen kun je ook een FreeNAS web-interface bedienen; zelfs iemand zonder enige non-Windows kennis kan dat. De grote vraag of ZFS geschikt voor je is hangt dan ook voornamelijk af of je bereid bent iets nieuws te leren en tijd hebt om in die wereld te duiken. Zo niet dan zou het houden op goede backups, iets wat met ZFS minder nodig is.

Backups zijn natuurlijk heilig als ultieme bescherming voor je data, maar schept ook weer nieuwe problemen. Wil je 10TB backuppen dan moet je daarvoor je spaarvarken lelijk toetakelen en erg praktisch is het niet. Veel mensen zeggen 'ach als het weg is jammer dan' vertrouwende dat het waarschijnlijk niet gebeurt, maar ook niet het einde van de wereld als dat wel zo is. In zo'n geval is de bescherming van ZFS zeker een grote winst, omdat je zonder backup toch een hoger beschermingsniveau weet te bereiken.

quote:

FireDrunk schreef op dinsdag 29 maart 2011 @ 22:34:
Ander voordeel is dat het met checksums werkt (maar ik geloof dat een bitmap redelijk gelijk is onder mdadm) hierdoor kan er heel snel gezien worden of een block nog intakt is (zonder het hele blok in te hoeven lezen).

Ik dacht dat bitmaps voor mdraid enkel gebruikt werden om 'dirty blocks' bij te houden? Daarmee bedoel ik dat er blokjes van je RAID volume worden gemaakt waarmee in het geval van een stroomstoring slechts de 'dirty blocks' opnieuw gerebuild hoeven te worden, in plaats van volledige rebuild.

Btrfs onder Linux heeft wel checksums en ook andere features die tot voor kort uniek waren aan ZFS, maar is nog minder uitontwikkeld en production-ready.

quote:

voodooless schreef op dinsdag 29 maart 2011 @ 22:42:
Dat is niet alleen het voordeel. Copy-on-write zorgt ervoor dat je geen RAID5 write hole hebt. Dat betekend dus dat je geen full stripe writes meer nodig hebt, wat met name random write performance ten goede komt. Random writes op een raid5 zijn veelal niet veel beter dan je op een enkele disk zou halen. RAIDz kent dit probleem dus niet.

Je zegt het bijna goed, maar RAID-Z zorgt er juist voor dat alle writes 'full stripe blocks' zijn; dat is namelijk de optimale combinatie voor parity RAID waarbij je in één keer een I/O request afhandelt, in plaats van in meerdere stappen (read-modify-write).

Voorbeeld: stel we hebben een RAID5 met 4 disks en 128K stripesize. De full stripe block is dan:
Full stripe block = <total_disks> - <parity_disks> * <stripesize>
ofwel: (4-1) * 128K = 384K

Nu gaan we 96KiB schrijven:
1) we moeten nu eerst de bestaande data in alle data stripes gaan lezen (128K * 3 zoals de meeste engines doen)
2) nu wordt de nieuwe data over de oude heengelegd, en geschreven naar de data disks (3)
3) de data wordt geXORed en naar de parity disk geschreven (1)

Nu gaan we 384K schrijven:
1) schrijf 128K naar disk1, 128K naar disk2, 128K naar disk3 en 128K naar disk4 voor de parity
2) klaar! geen reads; geen extra seeks

Wat moderne RAID5 engines doen is dus blokken 'opsparen' die precies even groot zijn als de full stripe block. Deze zijn snel, alle andere writes zal langzaam zijn. RAID engines die dit niet doen, zullen hooguit 10MB/s aan RAID5 writes doen; de schijven moeten dan seeken als een gek en zo haal je het slechtste uit je hardeschijven; seeken en afwisselend read/write zijn ze niet goed in!

En RAIDZ dan?
Bij RAID-Z is de random write gelijk aan de random write van een enkele disk; dat is nog steeds erg goed! Bij RAID5 is de random write veel slechter dan die van een enkele disk, echter wordt dat vaak verborgen door de write buffer; bij hardware RAID kan die erg groot zijn. Maar gevolg is wel reads tussendoor enorm vertraagd worden, en dat geeft RAID5 op de desktop vaak een 'traag gevoel' en op druk belaste servers eigenlijk geen doen; die hebben SSDs nodig.

Als we bovenstaand voorbeeld aanhouden van 4 disks in RAID-Z, dan zou een 96KiB write er zo uit zien:
disk1: 32KiB write
disk2: 32KiB write
disk3: 32KiB write
disk4: 32KiB write (parity)

De stripesize in dit geval is dus 32KiB. Voor een bestand van 64KiB zou de optimale stripesize dan weer anders bepaald worden. Zo past ZFS dus in feite de 'full stripe block' aan aan de grootte van de write request; slim! Zo voorkom je raid5 write hole en trage random writes.

Nice! Een topic over ZFS!

Na professioneel kennis gemaakt te hebben met ZFS op Solaris machines draai ik momenteel op mijn desktop thuis met een ZFS dataset. Dit heb ik gerealiseerd met zfs-fuse, wat in mijn beleving prima draait bij een voldoende grootte arc cache.
code:

v|1.8G|[kevin@iusaaset ~]$ sudo zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank   928G   826G   102G    89%  1.04x  ONLINE  -
v|1.8G|[kevin@iusaaset ~]$ sudo zfs list -o name,compression,dedup,mountpoint
NAME                      COMPRESS          DEDUP  MOUNTPOINT
tank                           off            off  /tank
tank/achtergronden          gzip-9            off  /home/kevin/achtergronden
tank/backup                     on         verify  /home/kevin/backup
tank/backup/dataset1            on         verify  /home/kevin/backup/dataset1
tank/backup/dataset2            on         verify  /home/kevin/backup/dataset2
tank/boeken                 gzip-9            off  /home/kevin/boeken
tank/games                  gzip-7            off  /home/kevin/games
tank/kevin                     off            off  /home/kevin
tank/persoonlijk                on            off  /home/kevin/persoonlijk
tank/series                 gzip-7            off  /home/kevin/series
tank/software               gzip-7            off  /home/kevin/software

Zoals te zien in het overzicht maak ik, afhankelijk van de dataset, gebruik van compressie en/of deduplicatie. Ook worden er bij sommige datasets snapshots bewaard zodat ik oude data terug kan halen. Dit aantal snapshots is bij de backup datasets natuurlijk het hoogst.

Helaas bied zfs-fuse (nog) geen mogelijkheid om de snapdirs transparant te mounten, waardoor ik voor toegang tot een oude snapshot terugewezen ben op een clone van een snapshot. Deze dient dan handmatig gemount te worden, waarna ik de data van een snapshot af kan halen. Complete snapshots restoren is wel mogelijk op de originele manier.

Als laatste heb ik nog een externe storage pool op een disk, welke ik eens in de zoveel tijd inplug. udev reageert hierop, waarna er incrementele snapshots worden verstuurd, welke de changes sinds de laatste sync bevatten. Hierdoor heb ik altijd een complete kopie van mijn pool op deze externe schijf.

Mijn belangrijkste keuze voor ZFS was het gemak van het snapshotten van data in combinatie met het gebrek aan data rot en de garantie van dataconsistentie mbv atomic writes. Zoals C!PHER al aangeeft is het maar afwachten of je data goed blijft wanneer er gebruik word gemaakt van andere filesystems. Agreed, de meeste mensen zullen dit niet meemaken, maar het is toch lullig als je RSA key voor je password database last heeft van bitrot...

Al met al ben ik echt 100% tevreden met ZFS, zeker wanneer ik het op (open)solaris gebruik. Op linux is het iets meer behappen, maar ook dat werkt uitstekend voor (intensief) dagelijks gebruik. Zoals ik al zei draait mijn complete home directory op deze zfs pool. Sinds ik hiermee begonnen ben heb ik een keer gehad date de fuse daemon eruit knalde, maar deze crash werd perfect door ZFS opgevangen, waardoor er niets aan het handje was.

Bedankt voor deze geweldige thread, door het Het grote DIY RAID NAS topic deel 3 was ik er juist over uit welke hardware ik voor mijn nog te bouwen NAS ga gebruiken, ik was mij juist aan het oriënteren op ZFS in een 10 disc raidz2 configuratie, ik hoop voor de definitieve aanschaf hier nog de nodige ideeen op te doen

Hierbij ter aanvulling een 'zieke' ZFS setup met 140HDDs met in totaal 500GB aan L2ARC workspace.

L2ARC

icyx, ik ben nog wel benieuwd naar de performance van je FUSE opstelling. Kun je daar wat over zeggen?

quote:

voodooless schreef op dinsdag 29 maart 2011 @ 23:49:
icyx, ik ben nog wel benieuwd naar de performance van je FUSE opstelling. Kun je daar wat over zeggen?

Hier is mijn status:
code:

v|1.8G|[kevin@iusaaset ~]$ sudo zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Dit zijn twee WDC WD10EADS-00L5B1 disks.

Wanneer ik bonnie++ run op twee datasets, plain /home/kevin, en /home/kevin/boeken, krijg ik daar de volgende resultaten uit:
/home/kevin
/home/kevin/boeken
Voor de duideijkheid; dit ging over het volgende:
code:

v|1.8G|[kevin@iusaaset ~]$ sudo zfs list -o name,compression,dedup,mountpoint
tank/boeken                 gzip-9            off  /home/kevin/boeken
tank/kevin                     off            off  /home/kevin

Mocht je meer willen weten moet je het maar even aangeven (en hoe precies ), over een paar dagen heb ik weer tijd om het eea uit te voeren.

quote:

icyx schreef op woensdag 30 maart 2011 @ 00:30:
[...]


Hier is mijn status:
code:

v|1.8G|[kevin@iusaaset ~]$ sudo zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Dit zijn twee WDC WD10EADS-00L5B1 disks.

Wanneer ik bonnie++ run op twee datasets, plain /home/kevin, en /home/kevin/boeken, krijg ik daar de volgende resultaten uit:
/home/kevin
/home/kevin/boeken
Voor de duideijkheid; dit ging over het volgende:
code:

v|1.8G|[kevin@iusaaset ~]$ sudo zfs list -o name,compression,dedup,mountpoint
tank/boeken                 gzip-9            off  /home/kevin/boeken
tank/kevin                     off            off  /home/kevin

Mocht je meer willen weten moet je het maar even aangeven (en hoe precies ), over een paar dagen heb ik weer tijd om het eea uit te voeren.

50MB/s lezen en 5MB/s 50MB/s schrijven... Dat is niet echt snel
Maar daarom staat er in de startpost ook, Linux en ZFS gaan niet lekker samen

offtopic:
Lezen is een vak...

quote:

FireDrunk schreef op woensdag 30 maart 2011 @ 08:32:
[...]


50MB/s lezen en 5MB/s 50MB/s schrijven... Dat is niet echt snel
Maar daarom staat er in de startpost ook, Linux en ZFS gaan niet lekker samen

offtopic:
Lezen is een vak...

50MB/s is niet heel super inderdaad. Ikzelf heb één vdev in een mirror met 5400rpm schijven en ik zit op 75MB/s. Dat is met NexentaCore, wat ik overigens kan aanraden.

OpenIndiana vind ik ook wel erg interessant, maar dat is nog een beetje te vroeg voor om die te gaan draaien. En ik vermoed dat die ook meer stroom zal verbruiken dan NexentaCore. Het verschil tussen NexentaStor en NexentaCore was bij mij al bijna 10watt, vond ik vrij fors.

Waar komt dat stroomverbruik dan vandaan? Zou dat met deduplication ofzo te maken hebben?
Of zijn er andere settings die standaard aan/uit staan?

quote:

FireDrunk schreef op woensdag 30 maart 2011 @ 11:14:
Waar komt dat stroomverbruik dan vandaan? Zou dat met deduplication ofzo te maken hebben?
Of zijn er andere settings die standaard aan/uit staan?

Deduplication staat standaard uit dus daar zit het hem niet in. En het waren beiden clean installs dus er zit ergens een groot verschil. Zelf denk ik dat het met de GUI te maken heeft, nexentaStor heeft helemaal mooie meters e.d., daar zullen wel wat background processen voor lopen denk ik. Misschien dat dat het verschil maakt.

refererende aan de openings post:

Scrubben

Het is aan te raden om regelmatig een scrub te laten lopen. Zonder verdere onderbouwing heeft men het over 1x per week als je consumenten/desktop disk gebruikt. Via cron vrij makkelijk te realiseren. Scrub leest door alle data heen en checked de data adhv checksums en eventuele mirror's. In normaal gebruik zal ZFS alleen data checken die actief gelezen worden. Een bestand dat 1 jaar niet aanraakt wordt dus ook niet in de gaten gehouden. Scrub is daar de oplossing.

ZIL op aparte vdev

De ZIL wordt normaal gesproken op de disks weggeschreven waar ook de data staat, vanaf zpool versie <xx> kan de ZIL op een aparte/dedicated vdev geschreven worden zodat de meer random IO niet de prestaties van de meer sequentielle IO van de data beinvloed. Het wordt ten sterkste aanbevolen om de ZIL wel op een mirrored vdev te laten schrijven want defecten of corruptie van de ZIL vdev betekend verlies van alle data in de zpool. Een op een aparte vdev geplaatste ZIL kan niet ongedaan gemaakt worden, dat kan pas weer van zpool versie <yy>. Vanaf zpool versie <zz> is het mogelijk om zpool's met afwezige of defecte ZIL te benaderen/mounten en te herstellen.

ZIL op SSD's en TRIM

Er is (nog) weinig te vinden over de effecten van ontbrekende TRIM en levensduur icm met ZIL op SSD's

4K sector / Advanced Format schijven:

Omdat de schijven toch vaak 512B sector grootte melden aan het OS ondanks de interne 4K sector kun onder FreeBSD via een omweggetje ZFS vertellen dat het 4K schrijven zijn.

gnop create -S 4096 /dev/da1
zpool create/add <pool> mirror/raidz /dev/da1.nop /dev/da2.nop ......
zfs export <pool>
gnop destroy /dev/da1.nop
zfs import <pool>

Naar verluid is een 4K sector simuleren op het eerste /dev al voldoende.

zdb -C data | grep ashift

moet de waarde 12 opleveren.

code:

v|1.8G|[kevin@iusaaset ~]$ sudo zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Ik vraag mij al een tijdje het volgende af:

als resultaat van het commando 'sudo zpool status' krijg je de melding 'No Known data errors' terug.

Betekend dit dat er ook nog 'unknown data errors' kunnen zijn die ZFS niet detecteerd?
Ik zou anders de melding 'no errors' verwachten, of wordt hier een slag om de arm gehouden?

Dat past dus precies in het rijtje van de Periodieke Scrub. ZFS checkt altijd via de checksums of de gelezen data intact en consistent is, maar doet dat niet met terugwerkende kracht.

Je moet dus de Scrub zien als een veredelde filesystemcheck. Ik ga er niet van uit dat als je een volledige scrub gedraait hebt, dat je daarna no errors krijgt.

Solaris doesn't properly support the GPT partitions ZFSguru creates, but if you use GEOM formatting then it would be like whole disks to Solaris. The start LBA would be zero.

So this should work:
1) format disks with GEOM
2) create a pool with 4K sectorsize override
3) export the pool
4) import the pool on Solaris platform again
5) check ashift with:
zdb -e <poolname> | grep ashift

ashift=9 means optimized for 512-byte sectors
ashift=12 means optimized for 4K sectors

quote:

Boudewijn schreef op dinsdag 29 maart 2011 @ 23:12:
Waarom staat dit niet in NOS?

Dit staat niet in NOS, omdat het om een filesystem gaat en niet specifiek om een OS. In verschillende topic's onder andere welke RAID mogelijkheden werd steeds weer ZFS besproken, soms zo intensief dat het orginele onderwerp geheel ondersneeuwde. Daarom kan ik wel accoord gaan met een ZFS ervaring topic hier in OM.

edit: Inmiddels ook een alias van dit topic aangemaakt onder NOS.

_Dune_ wijzigde deze reactie 31-03-2011 08:47 (7%)

quote:

Danfoss schreef op dinsdag 29 maart 2011 @ 23:10:
Ik ben overtuigd
Ik ga een plan opzetten voor mn operatie. Grootste uitdaging zal zijn hoe 3tb te backuppen. Maar dat is niet voor dit topic.

Nou, daar zeg je nog eens wat. In de howto's zou natuurlijk een leuk stukje kunnen komen over "How to migrate to ZFS without losing data"

Als jij nou een mooie oplossing verzint hebben anderen er misschien wat aan

Ik heb hier een vergelijkbaar "probleem" voor migratie.
Mijn idee om het op te lossen is om te starten met een broken RAIDZ2. Dus een RAIDZ2 maken van bijvoorbeeld 3 schijven v/d 5. Schijf 4 en 5 zou je kunnen simuleren met een loopback device, puur om de RAIDZ2 aan te maken.
Zodra dat volume loopt, disable je de loopback en valt je RAIDZ2 terug naar non-redundant, maar werkt wel nog prima.

Dan kun je je data overpompen van twee bestaande schijven met data naar de nieuwe RAIDZ2. Als dat klaar is, veeg je de oude data disken leeg en voeg je ze één-voor-één toe aan het RAIDZ2 volume. Welke ze zal inbouwen in de RAIDZ2 array. En als dat klaar is heb je dus weer redundantie.

Je loopt hierbij dus wel risico om je data te verliezen als er tijdens deze operatie een disk mee ophoudt.
Maar het maakt het in theorie mogelijk om een migratie te doen.
Denk er ook aan dat je bron leesbaar moet zijn voor het OS waarin je ZFS gebruikt.


Mijn situatie is dat ik nu een 3-disk mdadm RAID5 opstelling met ext4 gebruik.
Ik zit te denken om naar ZFS op FreeBSD te gaan migreren. Ik denk niet dat die array onder FreeBSD gestart krijg. Dus ik zit te denken om een extra disk te halen, dat wil ik sowieso. Daar de data op te zetten, mogelijk in combinatie een disk die ik van de RAID5 kan missen.
Dan een broken RAIDZ of ZFS mirror te maken waar de data op kan en dan te kopiëren.

Waar ik nu nog tussen twijfel is gaan naar:

• ZFS mirror + mirror (RAID10, 4 disk)
• 4 disk RAIDZ2
• 5 disk RAIDZ2

Met de mirrors ben ik flexibeler qua uitbreiding en de performance is beter.
Maar ik ben minder redundant dat met RAIDZ2 en de snelheid heb ik niet zo nodig want het is pure storage die ik maar met 1 of 2 clienten tegelijk ga benaderen.
Maar met RAIDZ2 ben ik minder flexibel... maar met 5-disk RAIDZ2 verwacht ik prima te voldoen aan mijn capaciteitsbehoefte voor de komende 2 jaar. Met 4 disk zeker nog een jaar, en met mirror voeg ik makkelijker schijfjes toe. Dus...
Geld heb ik niet bepaald voor het oprapen, dus ik neig naar de mirror setup vanwege de simpliciteit.
Alleen vrees ik wel voor de consistentie van mijn data, want als er een schijf uitvalt ben ik direct kwetsbaar voor bitrot. En ik heb gemerkt dat er op 1 schijf al tenminste een keer bitrot heeft plaatsgevonden over het afgelopen jaar. Ik voorkom het actief door maandelijks mdadm te laten scrubben.

Wat is wijsheid hier? Tsja... kan allebei toch?

Ultraman wijzigde deze reactie 30-03-2011 17:14 (10%)

Wat je ook kan doen (zo heb ik het gedaan):

Een RAIDZ array is niet groter te maken in het AANTAL drives, maar wel door de onderliggende schijven te vergroten. Als je dus van 6x 1TB naar 6x 2TB zou gaan dan wordt bij het vervangen van de laatste schijf je array 10 TB ipv 5 TB. Als je daarbij schijven in partities opdeelt kan je dus ook een array maken (je suggereert zelf als zoiets met een loopback device) met minder fysieke schijven en kan je dus op die manier migreren naar ZFS alleen ben je in de tussentijd je redundancy inderdaad kwijt.

Ik heb mijn data van 4x1 TB Linux RAID5 met XFS gemigreerd naar 6x2TB (bestaande uit 4x 2TB en 4x 1TB drives) door het als volgt te doen (De 2 TB schijven zijn sda, sdb, sdc en sdd, het draait onder Debian):

• Ik heb op de 4x 2TB drives op 2 van die drives 2 partities aangemaakt van 1 TB. De 2 andere drives zijn gepartitioneerd in een stuk van 2 TB. Ik heb nu dus:
  • sda1 (1 TB partitie van 2 TB drive a)
  • sda2 (1 TB partitie van 2 TB drive a)
  • sdb1 (1 TB partitie van 2 TB drive b)
  • sdb2 (1 TB partitie van 2 TB drive b)
  • sdc1 (2 TB partitie van 2 TB drive c)
  • sdd1 (2 TB partitie van 2 TB drive d)
• Vervolgens heb ik een RAIDZ array gemaakt van deze 6 partities. Ik weet dat als sda of sdb failen ik alsnog alles kwijt ben. Totale vrije ruimte: 5 TB want 1 TB is de grootste onderliggende ruimte)
• Daarna heb ik alle data van mijn 4x1TB schijven gekopieerd naar de ZFS array.
• Vervolgens heb ik de 4x1TB schijven (sde-sdi) met RAID0 (of lineair) samen genomen als 2 TB md drives (als er nu iets mis gaat ben ik echt alles kwijt natuurlijk want mijn bron RAID array wordt nu vernietigd):
  • sde1 en sdf1 worden samen 2 TB door middel van Linux RAID met als naam md1.
  • sdg1 en sdh1 worden samen 2 TB door middel van Linux RAID met als naam md2.
• Ik zeg tegen ZFS dat hij sda2 moet replacen door md1 en daarna dat hij sdb2 moet replacen door md2. Ik heb nu alsnog een 5TB array maar deze is wel safe want er staat geen data meer gestriped op een enkele schijf.
• Vervolgens verwijder ik sda2 en sdb2 en maak ik sda1 en sda2 OOK 2TB in grootte. Resultaat: ZFS heeft een RAIDZ array van 6x2TB = 10 TB.

Het is nogal een klus en erg tijdrovend (ik heb elke keer tussendoor een scrub gedaan om te kijken of alles nog in tact was) maar het heeft wel gewerkt. Ik vond het erg lastig om te schalen naar een systeem waarbij ik later geen drives kon toevoegen maar bedacht me dat ik in de praktijk van afgelopen jaren dit ook niet echt gedaan heb. Bovendien hebben veel moederborden 6x SATA (het bord dat ik nu gebruik heeft 8x SATA). Mocht in de toekomst dus een 1 TB drive kapot gaan dan vervang ik md1 of md2 door een echte 2 TB drive en kan ik altijd ook nog naar een andere behuizing of moederbord door alle 1 TB schijven door 2 TB schijven te vervangen.

De performance valt natuurlijk onder Debian wel tegen maar mijn eerdere array draaide dus met XFS/Raid5 en de hele migratie was op deze manier het makkelijkst uit te voeren. Bovendien ben ik gewend met de Linux tools om dit te realiseren en het is vooral een 'WORM' array met media (write once, read many times ). Misschien dat ik nu de array draait de zaak nog wel migreer naar freeBSD of Nexenta oid.

Tenslotte nog 1 optie die ik mij later bedacht en volgens mij nog niemand op het internet geprobeerd heeft: mocht je nou echt later devices aan je RAIDZ array willen toevoegen en dit kan dus niet met ZFS misschien is dit dan wel wat:

• Maak een RAID5/6 array onder Linux (deze kan je growen en dus het fysiek aantal drives uitbreiden). Leg daaroverheen een 'normale' ZFS drive. Dus zonder RAIDZ, want RAID5/6 ligt er al onder. Dan heb je toch checksumming over je FS en bestanden zelf en je kan onbeperkt devices blijven toevoegen want als het onderliggende RAID5/6 array groeit, groeit het ZFS filesysteem wat er op ligt mee .

Overigens Ultramam:

> Met de mirrors ben ik flexibeler qua uitbreiding en de performance is beter.
> capaciteitsbehoefte voor de komende 2 jaar. Met 4 disk zeker nog een jaar, en met mirror
>voeg ik makkelijker schijfjes toe.

Daar wordt alleen je opslagcapaciteit niet groter van tenzij dus alle onderliggende schijven groter worden.

> En ik heb gemerkt dat er op 1 schijf al tenminste een keer bitrot heeft plaatsgevonden
> over het afgelopen jaar. Ik voorkom het actief door maandelijks mdadm te laten scrubben.

mdadm kan wel scrubben maar ook niet echt. Het gaat in elk geval geen bitrot tegen. Er is geen enkele informatie WELKE bron juist is. Het enige wat 'echo check > /sys/block/md0/md/sync_action' doet is controleren of van onderliggende schijven gelezen kan worden. Als dat niet kan dan wordt dat block herberekend door de zaak te xorren met de nog wel leesbare data. Vervolgens wordt het block geschreven naar de schijf die dan de niet leesbare sector probeert te schijven, wat niet gaat en deze dus relocate naar een plek waar het wel lukt (als het goed is!). Er is echter geen enkele garantie dat de data op de leesbare sectoren echter ook wel de juiste data is.

Bij ZFS kan je naar hartelust 'dd if=/dev/zero of=/dev/sdx' doen. Even scrubben en je originele data is terug en je WEET dat de integriteit ook klopt. Mocht je dit zelfs doen op 2 drives op random plekken: ZFS blijft in tact maar zal je wel melden dat bepaalde bestanden in je ZFS filesystem stuk zijn en niet te repareren. Dat was voor mij echt 'ZFS FTW'

Voor de mensen die btrfs overwegen: probeer maar eens /dev/null naar 1 of erger 2 drvives te sturen, het leverde mij kernel-panics op. Vandaar nog een reden voor ZFS for Linux...

Wat betreft mirrors: je kunt eenvoudig single disks omtoveren tot mirrors en andersom. Dus je kunt beginnen met één disk, hier data op zetten, later een disk toevoegen dan draai je een 2-disk mirror. Nu voeg je nog twee disks toe als mirror en heb je 4 schijven en de opslagruimte van 2 schijven. Nu kan je tijdelijk een diskje lenen van een mirror en detachen, en later weer toevoegen. Dat kan ZFS dus wel; alleen met RAID-Z werkt het helaas niet zo.

Je kunt dus met 2 disks beginnen en elke keer 2 disks toevoegen, maar dan draai je dus RAID10 met 50% redundancy level.

@Ultraman: performance van RAID-Z2 met minder dan 6 disks zou slecht zijn (meer info op hardocp 4K testing thread) - dus of een 3 of 5 disk RAID-Z of een 6-disk RAID-Z2 zou een betere configuratie zijn qua performance.

quote:

Betekend dit dat er ook nog 'unknown data errors' kunnen zijn die ZFS niet detecteerd?

Nee, wel zoals FireDrunk zegt dat passieve data niet gecontroleerd wordt zonder om de zoveel tijd een scrub te draaien. Maar alle data die jij aanspreekt op ZFS wordt gecontroleerd. ZFS garandeert 'end to end data integrity'; het zou NOOIT mogen voorkomen dat een applicatie corrupte data krijgt voorgeschoteld van ZFS. Als ZFS detecteert dat de data corrupt is, dan is die file simpelweg onleesbaar. Dat is veel beter dan de applicatie corrupte data voorschotelen en dan maar afwachten hoe het uit de soep loopt.

En dan nog iets over mirrored SLOG: ik ben daar niet echt voorstander van; je bent namelijk nog steeds niet veilig met een SSD zonder supercapacitor; als er bij een stroomstoring data corrupt raakt is het helemaal niet zo theoretisch dat dit beide SSDs zou betreffen. Ik zou mijn data liever door één SSD met supercapacitor laten beschermen dan door meerdere mirrored SSDs zonder supercap; die corruptie kunnen vertonen en dus je pool kunnen corrumperen. Met ZFS versie 19 kun je wel transacties terugrollen en SLOG devices verwijderen; vanaf deze versie is het gebruik van SLOG dan ook stukken veiliger.

Alleen valt het op het front van super capacitors volgens mij wat tegen. De G3 van Intel (de 320 that is) heeft er een. Maar van de andere voorstellen van sub.mesa, heeft de Marvell C400 er volgens mij geen. Op SF-2000 vlak heeft OCZ alleen een super cap op de Vertex 3 Pro. De Vertex 3 heeft er geen. Of heb ik nog wat SSDs gemist?
Nu leek de SF-2000 mij de betere route omdat TRIM van de G3 niet werkt, waardoor je extra ruimte moet laten.

Het is ook maar net wat je voor workload hebt. Als je veel (random) schrijft, en tussendoor ook nog wat leest, dan is een SLOG best handig (mist goed/veilig geïmplementeerd), zelfs op een simpele draaiende schijf (twee in mirror) kun je hier nog voordelen bij hebben.

Doe je echter veel leesacties van een redelijk vaste set van data, is een SSD cache veel effectiever. Daar heb je geen redundancy nodig. Als de cache SSD corrupt is, gebruikt ZFS de cache gewoon niet. Je kunt de SSD gewoon vervangen voor een andere en lekker doorhobbelen

Ik vraag me af of zo'n supercapacitor niet vrolijk zelf te bouwen is... Als je gewoon een flinke condensator en een voltageregelaar tussen je sata power en je SSD zet, zou dat ding dan niet gewoon zijn writes afmaken ookal valt zijn sata link weg?

Nu Intel met supercaps begint voor consumenten verwacht ik dat je straks voldoende keus hebt.

Overigens, de nieuwe SSDs van Intel zijn niet de G3 controllers waar intel het over had met postville refresh, de Marvell controllers in de 320 en 5xx Intel SSDs is een tijdelijke opvolger tot de G3 er komt, althans zo heb ik het begrepen. De Intel G3 zou nog 3Gbps SATA zijn, maar wel veel sneller zijn qua 4K random performance.

Hoe het nu allemaal loopt is nog maar te bezien, het kan zijn dat Intel pas veel later met hun nieuwe controller komt, bijvoorbeeld omdat ze hem 6Gbps SATA willen maken en daar meer tijd voor nodig hebben, en daarom bij Marvell aankloppen om nu tijdelijk hun controllers te gebruiken. Er zijn ook geruchten dat Intel naar Sandforce gaat, maar daar geloof ik dus zelf helemaal niets van. Intel heeft een goede controller dus waarom die lijn niet doorzetten?

En waarom zou de G3 geen TRIM ondersteunen? TRIM is ook niet zo belangrijk voor ZFS; dedicated spare space is wel aan te raden. Zoveel ruimte heb je ook niet nodig; gaat vooral om de snelheid.

@voodooless: leuke is natuurlijk dat je een nieuwe SSD als SLOG én L2ARC kan gebruiken. De SLOG hoeft maar 4GB groot te zijn, dus kun je de rest voor cache gebruiken.

@FireDrunk: maar de SSD moet wel weten dat hij moet 'afkappen' en de HPA naar NAND schrijven. Daarna kan hij veilig uitgeschakeld worden. Maar met zo'n zelf-hack gebeurt dat niet, dus houd je hetzelfde probleem. Ook als de SSD op dat moment niet aan het schrijven is, is een stroomonderbreking vervelend, omdat dan op de NAND nog een oudere versie van de HPA staat.

Dus ik zou gewoon voor een Intel G2.5/G3 of Vertex 3 Pro of Marvell C400 met supercap. De vraag is hoe lang alles nog gaat duren.. februari zouden we de Intel G3 krijgen; het is nu eind maart.

CiPHER wijzigde deze reactie 30-03-2011 22:59 (18%)

quote:

CiPHER schreef op woensdag 30 maart 2011 @ 22:56:
@voodooless: leuke is natuurlijk dat je een nieuwe SSD als SLOG én L2ARC kan gebruiken. De SLOG hoeft maar 4GB groot te zijn, dus kun je de rest voor cache gebruiken.

Kan dat wel? Moest je voor SLOG/L2ARC geen dedicated disk hebben i.p.v partitie? Zoniet vraag ik me af of ik voor mijn NAS een boot partitie kan maken op mijn SSD van een paar GB, en de rest voor cache kan gebruiken? Scheelt namelijk weer een USB sticky

Ik ga het wel ff testen als Virtualbox nu eindelijk eens een keer wil meewerken

voodooless wijzigde deze reactie 30-03-2011 23:03 (7%)

Alleen Solaris heeft problemen met partities, FreeBSD heeft een mooi GEOM framework die deze problemen niet heeft. Sommige dingen die je leest zijn dus Solaris-specieke limitaties. Zo kun je ook niet van een RAID-Z booten onder Solaris, maar wel onder FreeBSD.

En ja je kunt een ZFS partitie maken voor je OS, een partitie voor L2ARC, een partitie voor SLOG en een partitie voor extra spare space (ongebruikt). Zo ongeveer gebruik ik het nu, maar wel mijn OS op de HDD pool.

Alleen of FreeBSD dus..

Edit: correctie: ik heb zojuist in OpenIndiana een partitie als cache kunnen toevoegen. Mooi spul weer

voodooless wijzigde deze reactie 30-03-2011 23:58 (70%)

De laatste paar dagen al flink wat ingelezen voor een nieuwe zelfbouw NAS en ik neig erg richting een OS dat ZFS ondersteund alleen zit ik nog wel met een vraag.
In normale raid configuraties moeten alle hardeschijven van hetzelfde typen zijn. En ik heb momenteel al een synology NAS draaien met daarin 4x een Samsung F3 van 2TB.

Kan ik dan als ik een nieuwe nas bouw met daarin 6x WD20EARS in een RAIDZ2 configuratie. Nadien mijn 4 samsung schijven als een nieuwe pool toevoegen en werkt dit dat probleemloos met mijn WD pool? Of is het beter voor de compabiliteit om voor samsung F4's te gaan ipv WD?

Ja dat kan. Ik zou ze de twee soorten wel scheiden van elkaar. Dus de WD in een RAIDZ2 gooien en de Samsungs in een losse RAIDZ(2) of twee mirrors toevoegen. Alles zit dan gewoon in een pool alsof het een grote bak met data is. ZFS is zo slim dat hij ziet welke devices een bepaalde IO load aan kunnen en zal dat gebruiken om de lasten zo handig mogelijk te verdelen over de beschikbare disk groepen.

Problematischer is het waarschijnlijk als je de WD + Samsungs in een grote RAIDZ2 gaat zetten. De kans is groot dat dat niet echt optimaal gaat presteren. Theoretisch is het echter geen probleem. Je kunt het natuurlijk altijd benchmarken.

Kan iemand in de openingspost nog even bijvoegen, dat ZFS nooit sneller wordt dan de langzaamste schijf in de pool?

Ik krijg OpenIndiana maar niet werkend onder ESXi, iemand die een (fatsoenlijke) ZFS distro al onder ESX(i) draaiend heeft gekregen?
Vreemd, een powerdown van de VM did the trick...

offtopic:
En een powerup daarna uiteraard...

FireDrunk wijzigde deze reactie 31-03-2011 08:51 (31%)

@Skinkie, is dat zo? Is dat zo voor elke configuratie? Dus ook in RAIDZ? Voor 'normale' RAID arrays is dat namelijk niet het geval.\

@TankiEEE, alle schijven zijn 2 TB toch die je wilt gebruiken alleen heb je 512 en 4096 bytes cluster disks door elkaar met die WD schijven en de Samsung schijven (er zijn van Samsung overigens 512 EN 4kb sector schijven te vinden in 2 TB uitvoering maar heel duidelijk welke je krijgt is het niet). Je kan altijd een array maken van die 10 disks samen met wat performance loss als je alles als 512 byte clusters benadert. Ik weet niet of je dat wat uitmaakt. Voor mijn 'storage behoeften' zou ik daar niet mee zitten maar liever een 18TB opslag hebben . Haal je die schijven dan ook uit je Synology en hang je ze in je zelfbouw nas of knoop je ze met ISCSI of zo aan elkaar?

Contagion wijzigde deze reactie 31-03-2011 09:54 (76%)
Reden: @TankiEEE erbij gezet

ZFS is een prima FS, het is alleen zo jammer dat het voornamelijk onder solaris draait, terwijl de rest van onze servers op Linux draaien. Dan moet je veel scripts twee keer schrijven, en dat is wat jammer. Verder draaien wij nu ook al bijna een jaar naar alle tevredenheid op ZFS, waarbij wij voornamelijk voor ZFS gekozen hebben vanwege de snapshots, en de zfs send/receive functionaliteit.

Mijn volgende stap gaat een linux (vm) worden met zfsonlinux.org/kqstor.com om te zien hoe goed dat werkt (in eerste instantie voor offsite replication, maar als het goed en stabiel werkt kan ik het ook inzetten als main storage).

quote:

Kees schreef op donderdag 31 maart 2011 @ 11:49:
ZFS is een prima FS, het is alleen zo jammer dat het voornamelijk onder solaris draait, terwijl de rest van onze servers op Linux draaien. Dan moet je veel scripts twee keer schrijven, en dat is wat jammer. Verder draaien wij nu ook al bijna een jaar naar alle tevredenheid op ZFS, waarbij wij voornamelijk voor ZFS gekozen hebben vanwege de snapshots, en de zfs send/receive functionaliteit.

Mijn volgende stap gaat een linux (vm) worden met zfsonlinux.org/kqstor.com om te zien hoe goed dat werkt (in eerste instantie voor offsite replication, maar als het goed en stabiel werkt kan ik het ook inzetten als main storage).

Dat zou voor mij ook echt wel kewl zijn Ik zou best eens willen proberen of dat werkt, maar ik ben niet zo'n held in compilen, misschien toch maar eens op storten dan

quote:

Contagion schreef op donderdag 31 maart 2011 @ 09:49:
@Skinkie, is dat zo? Is dat zo voor elke configuratie? Dus ook in RAIDZ? Voor 'normale' RAID arrays is dat namelijk niet het geval.\

Als je 1 raidz(of mirror) hebt is je iops net zo snel als de iops van 1 disk. Om de data te controleren worden namelijk bij lezen alle schijven gelezen om de data te controleren (en te healen). Lezen is dus een relatief dure actie. (je bandbreedte, MB/sec kan wel toenemen, maar je aantal operaties niet)

Om meer snelheid te krijven kun je wel een vdev toevoegen: 2 raidz in een pool is net zp snel als 2 disks.

Staat ook in de administration guide.

Hier is het duidelijk samengevat:
http://constantin.glez.de...tem-performance#mirroring
====

Ik ben me aan het inlezen om te kijken of een zfs server een goede optie is om een backup server van te maken. Aangezien een backup echter pas veilig is als hij ook ergens anders staat, en dat "ergens anders" dus shared storage moet kunnen zijn (2e server is denk ik te duur voor deze knutseloplossing). Nu kan zfs ook files als devices zien, dus dan kun je gewoon shared storage daarvoor gebruiken. (of via iscsi..) Echter kun je ooit een device dat je aan je zpool hebt toegevoegd ooit nog kleiner maken(kleinere mirror device toevoegen?) ?

Ben ook aan het kijken naar zfs send/receive achives, maar dat is meer een offline dan een online oplossing.

leuk_he wijzigde deze reactie 31-03-2011 12:17 (11%)
Reden: Link toegevoegd, en bandbreed opmerking.

Maar als je op 6 schijven tegelijk leest met 50 MB/sec (in RAIDz) en dat moet controleren tegen de checksums, dan is alsnog de leessnelheid toch (even door de bank genomen) 250 MB/sec mits je proc snel genoeg de data kan checken?

Edit: Ah ik zie jou edit nu . Ik gebruik ZFS echt alleen voor storage van media. En dat is voornamelijk sequentieel lezen. Daarbij gaat het aantal MB/sec natuurlijk wel omhoog, alleen onder ZFS-fuse kom ik natuurlijk niet in de buurt van de XFS performance die ik eerst had, hoewel het vooral de write performance is die heel ver terugvalt tov XFS.

En over het stukje onder je streep; kan je niet gewoon rsyncen naar een remote location (waar wellicht ook ZFS draait ). Zo doe ik het iig. En direct voor het rsyncen wordt op de backup locatie ff een snapshot gemaakt.

Contagion wijzigde deze reactie 31-03-2011 12:20 (59%)

quote:

Contagion schreef op donderdag 31 maart 2011 @ 12:17:
Maar als je op 6 schijven tegelijk leest met 50 MB/sec

Bandbreedte en Iops opmerking toegevoegd aan mijn vorige post. en ook een link. het is niet zo simpel als "net zo snel als de traagste disk", maar ik had al wel vastegesteld dat zfs gelijke disks wil hebben in een raid/mirror. Hoe loadbalancing NU werkt voor meerdere vdevs in een pool is me niet duidelijk. Waarschijnlijk nog steeds op basis van grote van de vdevs, en nog niet op baiss van performance (is wel beloofd maar wanneer blijkt bij zfs altijd vaag denk ik)

rzyncen naar een remote locaktie is een oplossing, maar dan moet daar dus een trusted server staan. daar een zfs device neerzetten heeft als voordeel dat die meteen encrypted kan zijn. Probleem is dat je beveiling op een andere lokatie (het ligt immers dicht tegen een hobbie oplossing aan) niet bekend is. En als het geen online oplossing is er ook al weinig reden zfs te gebruiken, dan kan het net zo goed met tar/gzip/openssl.

leuk_he wijzigde deze reactie 31-03-2011 12:27 (25%)

Mis nog een paar dingen in de openingspost:
- zfs send/receive. Snapshots zijn maar de helft van een goede backup, als alle schijven van je raidz(2/3) tegelijk kapot gaan (brand, kortsluiting, diefstal, etc), ben je alsnog alles kwijt. zfs send over ssh naar een offsite server kan de andere helft van je backup zijn.
- deduplication. voor bepaalde usecases kan dat je heel veel ruimte schelen.
- encryption. Voor gevoelige data.

Verder is misschien een tabel met alle OSen handig, waarin aangegeven wordt welke kernel en userland gebruikt wordt, laatste zpool versie, etc.

quote:

Contagion schreef op donderdag 31 maart 2011 @ 09:49:
@Skinkie, is dat zo? Is dat zo voor elke configuratie? Dus ook in RAIDZ? Voor 'normale' RAID arrays is dat namelijk niet het geval.\

@TankiEEE, alle schijven zijn 2 TB toch die je wilt gebruiken alleen heb je 512 en 4096 bytes cluster disks door elkaar met die WD schijven en de Samsung schijven (er zijn van Samsung overigens 512 EN 4kb sector schijven te vinden in 2 TB uitvoering maar heel duidelijk welke je krijgt is het niet). Je kan altijd een array maken van die 10 disks samen met wat performance loss als je alles als 512 byte clusters benadert. Ik weet niet of je dat wat uitmaakt. Voor mijn 'storage behoeften' zou ik daar niet mee zitten maar liever een 18TB opslag hebben . Haal je die schijven dan ook uit je Synology en hang je ze in je zelfbouw nas of knoop je ze met ISCSI of zo aan elkaar?

Ja de bedoeling was er eigenlijk een groot array van te maken indien mogelijk. Dus eerst een pool maken met 6x 2TB schijven (wss Samsung F4's voor de zekerheid). Daarna data kopiëren van de DS410 naar de zelfbouw NAS en dan de disks van de Synology overzetten. Dan kan de Synology namelijk in de verkoop

Maar ik ben er nog niet helemaal uit of ik er dan één groot array van maak met dus F3's en F4's door elkaar of dat ik er 2 aparte pools van maak. Dus voor ieders soort schijf een aparte pool. Zal er nog even over moeten nadenken. Bedankt voor de antwoorden iig

Zou dit iets zijn? Om een kant en klare ZFS oplossing aan te dragen? http://www.zenabox.com/index.html

quote:

BackLash schreef op donderdag 31 maart 2011 @ 22:01:
Zou dit iets zijn? Om een kant en klare ZFS oplossing aan te dragen? http://www.zenabox.com/index.html

u$ 1749,- voor een 6 tb raidz doosje ..
maar is wel de eerste kant en klare oplossing die ik zie (in die prijsklasse)

borroz wijzigde deze reactie 31-03-2011 23:31 (12%)

@TankiEEE: ik zou er geen probleem mee hebben hardware te mixen alleen de onderliggende wel iets kleiner maken dan de volledige drive voor als je eens met een drive zit die net wat minder fysieke sectoren heeft dan een eerderen in de array. Ik neem aan dat je genoemde thuis-NAS niet als 'business oplossing' wordt ingezet, maar als je toch RAIDZ(2) gebruikt levert je dat wel een dikke 18 (16) TB aan ruimte op met 10 drives van 2 TB. Het motto van ZFS garandeert je end-to-end integriteitscontrole van je data dus alleen daarom zou ik het zeker aandurven om drives te mixen .

Ik heb in mijn pool nu 4 Seagate 1 TB drives zitten (ST31000340AS), 2 Samsung HD203UI's en 2 HD204UI's.

Die ZenaBox ziet er wel mooi uit eigenlijk,maar beetje duur is het wel,vergeleken met zelfbouw. maar vergeleken met vergelijkbaar commercieel 6TB NAS met die opties,valt het eigenlijk nog wel mee.

Enig idee waar dat ding nou precies op draait? Ik zie dat er een image te downloaden is vanaf SF, maar ik heb nu geen echte computer tot mijn beschikking om een VM op te starten.

http://sourceforge.net/pr...s/Version%201.0%20Stable/

quote:

Kompaan schreef op vrijdag 01 april 2011 @ 00:27:
Die ZenaBox ziet er wel mooi uit eigenlijk,maar beetje duur is het wel,vergeleken met zelfbouw. maar vergeleken met vergelijkbaar commercieel 6TB NAS met die opties,valt het eigenlijk nog wel mee.

Enig idee waar dat ding nou precies op draait? Ik zie dat er een image te downloaden is vanaf SF, maar ik heb nu geen echte computer tot mijn beschikking om een VM op te starten.

http://sourceforge.net/pr...s/Version%201.0%20Stable/

aan die image heb je niks in VM.. is specifiek voor die hardware.
lijkt erop dat het gebaseerd is op FreeBSD.. is erg weinig over te vinden nog, maar het geeft wel een signaal waar het naar toe kan gaan kwa techniek met de home nassen ..

En voor diegene die mochten twijfelen over de verdere ontwikkeling van FreeNAS, zie hier de announcement van FreeNAS 8.0 RC4 door Josh Paetzel himself. Downloaden doen we nog steeds vanaf SF, incl. de RC 4 Release Notes.

Ravefiend wijzigde deze reactie 01-04-2011 09:18 (35%)

quote:

Ravefiend schreef op vrijdag 01 april 2011 @ 09:15:
hier

quote:

It is highly recommended to use ZFS
for new volumes, even if the underlying device is a volume exported by a
hardware RAID controller.

Grappig ^,^

quote:

There is one last bit of new functionality, which is GUI replacement of drives
in volumes, and a few small pieces, such as the ability to edit powerd
settings in the GUI.

Dat is dan wel weer belangrijk

quote:

borroz schreef op vrijdag 01 april 2011 @ 01:10:
[...]
aan die image heb je niks in VM.. is specifiek voor die hardware.

Dit gaat mij er niet van weerhouden het lekker toch te proberen als ik verhuisd ben en mijn echte computer weer geinstalleerd is

quote:

lijkt erop dat het gebaseerd is op FreeBSD.. is erg weinig over te vinden nog, maar het geeft wel een signaal waar het naar toe kan gaan kwa techniek met de home nassen ..

BSD+ZFS+mooie web interface lijkt mij ook een erg goede combi voor thuisgebruik

quote:

Ravefiend schreef op vrijdag 01 april 2011 @ 09:15:
En voor diegene die mochten twijfelen over de verdere ontwikkeling van FreeNAS, zie hier de announcement van FreeNAS 8.0 RC4 door Josh Paetzel himself. Downloaden doen we nog steeds vanaf SF, incl. de RC 4 Release Notes.

yessssss ..
* gelijk aan de slag

Ook weer geen VMXNET3 Waarom willen al die bouwers daar toch niet aan mee werken

jij bent ook niet gauw tevreden

mooi hoor die freenas 8 rc4 .. periodieke snapshots ect.
kan iemand nog iets zeggen over compressie levels en quota's

inmiddels een gek probleem.
wil ssh naar die freenasdoos en kom er niet in.
(de webgui werkt prima)

* opgelost- maak eerst een nieuwe user aan en log daarmee via ssh in

borroz wijzigde deze reactie 02-04-2011 00:40 (81%)

Voor de mensen die FreeNAS toch virtueel draaien, gebruik ook GEEN vmxnet2.
Ik heb last van flink wat timeouts als ik die gebruik. (60% van de pings komt maar aan)

freenas# dd if=/mnt/ramdisk/randomfile.bin of=/mnt/pool/test3.bin bs=1M
988+0 records in
988+0 records out
1035993088 bytes transferred in 1.689741 secs (613107661 bytes/sec)
freenas#

slik...

quote:

borroz schreef op vrijdag 01 april 2011 @ 13:48:

inmiddels een gek probleem.
wil ssh naar die freenasdoos en kom er niet in.
(de webgui werkt prima)

wireshark ziet dit..
iemand een idee wat er loos is ?

Heb je SSH wel aangezet? (en root login ook allowed)

FireDrunk wijzigde deze reactie 01-04-2011 15:24 (69%)

Even iets opmerken over wat er gezegd wordt over dat een vdev de performance heeft van een enkele disk. Dat is wel heel kort door de bocht. Het gaat alleen om random I/O; niet om sequential I/O. Dus een grote RAID-Z kan 1000MB/s doen en rond de 60 IOps; de IOps schaalt dus niet met het aantal disks.

Wat doe je hier aan?
1) als je vrijwel geen random I/O doet (alleen grote bestanden) is dit niet zo'n issue.
2) meerdere vdevs dan maar? leuk heb je 4* 60 IOps; nog steeds traag!
3) L2ARC toevoegen? Dan gaan je random read IOps significant omhoog (100.000+ bij goede SSDs)
4) SLOG toevoegen? Dan gaan je random write IOps (én sequential write) flink omhoog.

Dus in de praktijk niet zo'n probleem. Wel kun je stellen dat een pool met meerdere mirrors (RAID10 zeg maar) met hardeschijven meer IOps bereikt. Dus als je geen SSDs kunt of wilt inzetten dan zou dat een afweging kunnen zijn. Zelf denk ik dat als je random I/O performance nodig hebt je gewoon aan SSDs moet denken; die doen dat zoveel beter dan HDDs en dit is een unieke feature van ZFS die de performance van een grote HDD pool flink omhoog kan gooien met een paar veel kleinere SSDs.

@FireDrunk: houd in je achterhoofd dat ZFS een grote buffer heeft, en je dus iets van 40GB moet schrijven voor een echte "sustained write" test. 10GB minimaal. Voor kleinere tests krijg je te hoge resultaten omdat een deel nog in de RAM staat op het moment dat dd klaar is met schrijven.

Hmm, maar ik kan (nog )geen ramdisk van 40GB aanmaken

Maar je hebt toch niet persé random-write nodig? Zolang ZFS compressie maar uit staat.

# 40GB zero-write
dd if=/dev/zero of=/poolmountpoint/zero.file bs=1m count=40000

SLOG kun je trouwens wel aardig testen met een ramdisk; SLOG van 1GB kan al genoeg zijn.

CRAVUNX01# dd if=/dev/zero of=/mnt/pool/zero.file bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 171.255734 secs (250792613 bytes/sec)
CRAVUNX01#

Mwoh, dat met 4 disks in RAID0 striping ...

FireDrunk wijzigde deze reactie 01-04-2011 16:59 (3%)

Dat ziet er realistischer uit. Je kunt het andersom ook weer inlezen:

dd if=/mnt/pool/zero.file of=/dev/null bs=1m

(overigens: bij UNIX wordt lower-case 'm' gebruikt en bij Linux wordt upper-case 'M' gebruikt; maar bij jou werkt M kennelijk toch?)

quote:

FireDrunk schreef op vrijdag 01 april 2011 @ 16:58:

CRAVUNX01# dd if=/dev/zero of=/mnt/pool/zero.file bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 171.255734 secs (250792613 bytes/sec)
CRAVUNX01#

Mwoh, dat met 4 disks in RAID0 striping ...

bij mij 169347209 en inlezen 213722783

( e35m1-pro / 8 gb) 3 x 2 tb raidz (2 x 203 + 1 x 204) + 60 gb ocz ssd cache

* die cijfers zeggen me eigenlijk niks
* balen, ik kan dat niet via ssh doen

borroz wijzigde deze reactie 01-04-2011 21:52 (18%)

CRAVUNX01# dd if=/mnt/pool/zero.file of=/dev/null bs=1M
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 96.621398 secs (444515127 bytes/sec)
CRAVUNX01#

Over terug lezen gesproken Dit zijn wel waardes waar ik blij van word

ZFSguru 0.1.8p3 is uit!

http://zfsguru.com/forum/announcements/127

Tenminste hij is nog aan het uploaden staat er. Ben zeer benieuwd

Misschien ook leuk voor in dit topic ?

http://www.anandtech.com/...-testing-and-benchmarking

Wel aardig artikel, maar gaat vooral in op ZFS als oplossing voor SANs, en niet echt voor een NAS server. Het grote verschil is dat bij een SAN er maar één computer toegang heeft tot de data. Dus Windows 7 die een iSCSI-disk krijgt aangeleverd en zet daarop NTFS filesystem. De ZFS server deelt die iSCSI disk dan maar met één windows-pc; niet meerdere.

Bij een NAS heb je juist dat de data op ZFS zelf staat en andere computers er tegelijkertijd naar kunnen verbinden. Maar toch wel aardig artikel, ik zal het zo in de openingspost zetten.

quote:

Ravefiend schreef op vrijdag 01 april 2011 @ 09:15:
En voor diegene die mochten twijfelen over de verdere ontwikkeling van FreeNAS, zie hier de announcement van FreeNAS 8.0 RC4 door Josh Paetzel himself. Downloaden doen we nog steeds vanaf SF, incl. de RC 4 Release Notes.

Op het eerste gezicht gebruik deze freenas versie zpool versie 15.(even gestart in mijn virtual box) Niks mis mee, maar om met zfs te experimenteren wil ik juist een recente versie van zfs. Ik moet nog even uitzoeken of alleen opensolaris express een recente versie heeft of de zfs of dat de zfs-fuse versie ook bij is.


@hieronder, bedankt. als je dat niet ziet is dat heel moeilijk te vinden.

leuk_he wijzigde deze reactie 02-04-2011 23:50 (4%)

Op wikipedia staat geloof ik een lijst met welk OS welke versie van ZFS gebruikt.

Wikipedia: ZFS

FireDrunk wijzigde deze reactie 02-04-2011 14:29 (31%)

quote:

FireDrunk schreef op zaterdag 02 april 2011 @ 14:29:
Op wikipedia staat geloof ik een lijst met welk OS welke versie van ZFS gebruikt.

Ah, die tabel heb ik ooit toegevoegd daar goed te zien dat ie ook voor anderen nuttig is.

Ik heb zfs wel eens gebruikt op linux met zfs-fuse. Werkte niet geweldig, vooral erg traag. Ik ben wel erg benieuwd hoe de nieuwe in-kernel opties zijn, heeft iemand daar ervaring mee? Of anders met zfs op debian/kFreeBSD?

Ik heb eergister ZFS gecompiled om het native onder linux te draaien, maar omdat het nog een beetje betá is qua interfaces, moet je op een vdev een EXT2 filesystem zetten. Dat kost je nogal wat performance.
Maar verder werkt het eigenlijk wel prima. Ik haalde met 4 disks in striping iets van 60MB/s lezen en schrijven.

Maar dan draai je Ext2 filesystem op een ZVOL; een virtuele hardeschijf op ZFS. Dan heb je dus niet de meeste voordelen van ZFS. Dat was hoe FUSE draaide in het begin. Pas als je ook ZFS filesystem gebruikt dat je kunt zeggen dat je ZFS draait; zo'n ZVOL is alleen het RAID gedeelte van ZFS zeg maar (RAID-Z) zonder het filesystem zelf.

quote:

FireDrunk schreef op zondag 03 april 2011 @ 13:02:
Ik heb eergister ZFS gecompiled om het native onder linux te draaien, maar omdat het nog een beetje betá is qua interfaces, moet je op een vdev een EXT2 filesystem zetten.

Gebruik je dan wel de laatste beta?

quote:

Please keep in mind the current 0.5.2 stable release does not yet support a mountable filesystem. This functionality is currently available only in the 0.6.0-rc2 release candidate.

quote:

CiPHER schreef op zondag 03 april 2011 @ 13:47:
Maar dan draai je Ext2 filesystem op een ZVOL;

Ik ben altijd gek op plaatjes...




File system ontbreekt dan dus nog...

leuk_he wijzigde deze reactie 03-04-2011 14:07 (6%)

ZPL is het filesystem en ZVOL is dus een virtuele hardeschijf opgeslagen door ZFS (inclusief redundancy als RAID-Z enzo). Maar als je alleen ZVOLs kunt gebruiken, heb je geen echt ZFS filesystem met checksums voor je bestanden enzo.

Kan KQInfo ZFS module alleen met ZVOLs overweg?

Je moet een filesystem op een ZVOL zetten ja... Beetje kak dus...

Dan is in feite alleen het "RAID" gedeelte werkend; veel features van ZFS mis je dan, en je bent nog steeds afhankelijk van een ouder filesystem om je dataintegriteit te bewaken; niet ideaal dus.

Kun je wel snapshots maken van de ZVOL en compressie inschakelen enzo?

Dat kan ik niet meer kijken, heb de VM al verwijderd Maar het was niet echt moeilijk om te doen, Ubuntu 10.10 zijn prima handleidingen voor.

quote:

CiPHER schreef op vrijdag 01 april 2011 @ 23:29:
Wel aardig artikel, maar gaat vooral in op ZFS als oplossing voor SANs, en niet echt voor een NAS server. Het grote verschil is dat bij een SAN er maar één computer toegang heeft tot de data. Dus Windows 7 die een iSCSI-disk krijgt aangeleverd en zet daarop NTFS filesystem. De ZFS server deelt die iSCSI disk dan maar met één windows-pc; niet meerdere.

Bij een NAS heb je juist dat de data op ZFS zelf staat en andere computers er tegelijkertijd naar kunnen verbinden. Maar toch wel aardig artikel, ik zal het zo in de openingspost zetten.

Klopt, maar zit ook een stukje benchmarking in. Dus leek mij niet helemaal irrelevant voor het _grote_ ZFS topic ;-)?

Ik heb met hdtune op een iscsi zfs volume zitten testen, kan het kloppen dat de zil voornamelijk in de <4k random iops naar voren komt? Ik kan overigens bijzonder weinig cijfers vinden tussen met én zonder-zil.

Eventjes terug ging het over het feit dat er optimale aantallen disks zijn om te gebruiken bij ZFS:
RAID-Z: 2, 3, 5 of 9 disks
RAID-Z2: 6 of 10 disks

Nu is het zo dat ik mijn FreeNas server wil uitbreiden. Momenteel is er een RAID-Z pool van 4*1.5 TB disks. Dit zou ik willen veranderen naar 6*1.5 TB. Deze zijn niet optimaal maar in hoeverre heeft dit nu precies impact op de performance ? Alles gaat gewoon over gigabit netwerk dus de snelheid zal zeker daar cappen... Hoeveel performanceverlies treedt er op in de praktijk ?

Momenteel haal ik slechts snelheden van 50MB/s read en 45MB/s write, waarschijnlijk gewoon FreeNas die een beetje de mist in gaat maar voor mijn doeleinden kan ik er mee leven. Wat ik wel raar vind is de vorm van de transfer-grafiek bij schrijfacties naar mijn pool, in plaats van een eerder constante curve met lichte fluctuatie valt deze steeds weer op nul...

Als je met FreeNAS een verkeerde partitie gebruikt en je schijven zijn 4K sector dan kan dat je near-zero throughput verklaren. Maar dat kan ook een andere oorzaak hebben.

Als je wilt uitbreiden naar 6 * 1.5TB zul je de data die er nu opstaat eraf moeten halen en een nieuwe pool moeten aanmaken. Vervolgens kun je de gegevens dan terugzetten. Niet zo handig als simpelweg een vdev toevoegen dus. Bovendien zou ik voor een RAID-Z2 gaan; zeker als het 4K schijven zijn, presteert dat beter dan een 5-disk RAID-Z. RAID-Z2 geeft je ook veel betere bescherming.

Ook ik ben aan het stoeien met een nieuwe server...

atm heb ik een xeon x3440 met 8GB op een supermicro x8sil-f
Host OS is Vsphere ESXi 4.1 @USB (latest)
Guest OS is Nexentastor Community edition (latest)

De guest boot vanaf een 8GB bagger trage test iscsi target bij gebrek aan een extra HBA voor lokale guest install
VTd is enabled en de ibex peak (ICH) sata controller wordt rechtstreeks aan de guest aangeboden
Aangesloten op de ICH zijn 4x 1.5TB Seagate LP disks (geconfigureerd als raidz1) en 1x Kingston SSD-now van 64GB als cache. Verder heeft de guest de beschikking over 4 CPU cores en 4GB intern. het systeem heeft de beschikking over een e1000 NIC en VMware tools zijn geinstalleerd.

Op een ander systeem (W2008r2) heb ik mijn iSCSI initiator geconfigureerd en heb ik effectief een GPT partitie van 3.9TB toegevoegd aan dit systeem. Met Crystaldiskmark en een 500MB setting haal ik de volgende resultaten:
-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 98.145 MB/s
Sequential Write : 58.909 MB/s
Random Read 512KB : 67.639 MB/s
Random Write 512KB : 59.386 MB/s
Random Read 4KB (QD=1) : 5.306 MB/s [ 1295.4 IOPS]
Random Write 4KB (QD=1) : 5.349 MB/s [ 1305.8 IOPS]
Random Read 4KB (QD=32) : 67.047 MB/s [ 16369.0 IOPS]
Random Write 4KB (QD=32) : 62.774 MB/s [ 15325.7 IOPS]

Test : 500 MB [I: 0.0% (0.2/3071.9 GB)] (x5)
Date : 2011/04/05 22:12:44
OS : Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)

Zijn dit aannemelijke resultaten of is hier nog verbetering te behalen?

Edit1: Met een 4000MB setting zijn de prestaties een stuk minder Waar gaat het fout en waar is er verbetering te behalen? De ZFS pool moet wel in staat zijn om gelijktijdig HD te streamen naar mijn mediaplayer en gelijkertijd schrijven van een groot bestand na een usenet download. Dit gaat bij mijn huidige RAID5 van drie disks op een ich9r niet

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 44.837 MB/s
Sequential Write : 51.906 MB/s
Random Read 512KB : 14.954 MB/s
Random Write 512KB : 49.339 MB/s
Random Read 4KB (QD=1) : 0.728 MB/s [ 177.8 IOPS]
Random Write 4KB (QD=1) : 0.761 MB/s [ 185.8 IOPS]
Random Read 4KB (QD=32) : 2.060 MB/s [ 503.0 IOPS]
Random Write 4KB (QD=32) : 1.866 MB/s [ 455.5 IOPS]

Test : 4000 MB [I: 0.0% (0.2/3071.9 GB)] (x5)
Date : 2011/04/05 22:48:04
OS : Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)

Ik heb een LSI SAS kaart in bestelling staan welke ik wil voorzien van IT firmware zodat de ICH gebruikt kan worden voor een aantal andere disks met daarop minimaal twee andere guests: W2008r2 webserver en W2008r2 file/media/download/ts/mailserver. Deze server zal ook dedicated het iSCSI vol van Nexentastor toegewezen krijgen. Ook het geheugen zal nog uitgebreidt worden naar 16GB.

Ik wil graag de server in de meterkast zetten en pas over een jaar of drie aan vervanging gaan denken. Zie ik nog iets over het hoofd of maak ik ergens een fout@eigen brein?

Ik drop deze post even hier vanwege ZFS, maar hij zou ook in het zuinige server topic kunnen staan of in het diy nas, maar ik probeer zoveel mogelijk te verenigen in één apparaat

edit2: tijdens de 4000MB test schoten de toegewezen resources (4xCPU en 4GB) richting 100% load. ZFS lust dus wel wat

ransbal wijzigde deze reactie 05-04-2011 23:13 (20%)

Random I/O boven de 10MB/s kan niet van een HDD afkomen; dus dat gebeurt door RAM. Bij 4GB test past het grootste al niet in RAM zodat je scores dus ook lager zijn. Toch is 45MB/s read en 52MB/s write wel een beetje laag. De random scores zijn normaal voor HDDs.

Meer RAM of een SSD kun je gebruiken om random I/O op te krikken (en sequential write). Maar heb je nu tijdens normaal gebruik oke performance? Films die schokken?

quote:

CiPHER schreef op woensdag 06 april 2011 @ 01:07:
Random I/O boven de 10MB/s kan niet van een HDD afkomen; dus dat gebeurt door RAM.

quote:

ransbal schreef op dinsdag 05 april 2011 @ 22:22:
en 1x Kingston SSD-now van 64GB als cache. Verder heeft de guest de beschikking over 4 CPU cores en 4GB intern. het systeem heeft de beschikking over een e1000 NIC en VMware tools zijn geinstalleerd.

Cipher heeft ook een SSD aangesloten. he? Dus wellicht is hij ook nog eens de random I/O van die "cache" aan het testen naast de werking van de cache. ...Als hij een benchmark size neemt die aanzienlijk groter is dan het geheugen van de file server (12 GB ofzo..) .

Verder: kun je niet vmxnet netwerk adapter installeren?
nope, opensolaris heeft deze nog niet.

Probleem bij deze benchmark is echter vooral dat je niks hebt om mee te vergelijken. Wat ideeen:
-Maak een eigen benchmark met je eigen typische workload en kijk of je performance hoog genoeg is. (wat ransbal eigenlijk ook vraagt)
-Installeer een willekeuirige linux en formateer op ext(3/4), en voer dan dezelfde benchmakr uit. (moet je wel een deel van 1 van je harde schijven voor opofferen voor boot schijf?) via softraid
-Installeer het eens op bare metal, Esx is uiteraard niet gratis(wat betreft performance), en het is uiteraard wel interresant om te zien hoeveel het werkelijk uitmaakt.

quote:

CiPHER schreef op woensdag 30 maart 2011 @ 21:44:
@Ultraman: performance van RAID-Z2 met minder dan 6 disks zou slecht zijn (meer info op hardocp 4K testing thread) - dus of een 3 of 5 disk RAID-Z of een 6-disk RAID-Z2 zou een betere configuratie zijn qua performance.

Heb je toevallig een linkje naar betreffende thread/post? RAIDz2 met 4 disks zou voldoen aan de 4k sector "eisen" voor betere performance. Natuurlijk is 6 disks sneller dan 4, maar is het verschil onevenredig groot?

Ik ga 4 2TB disks nemen. De vraag is of ik die in RAIDz2 zet, of in dual mirror. CPU-wize is de tweede optie de beste natuurlijk, maar wat betreft betrouwbaarheid zit ik met RAIDz2 weer wat beter.


Edit: ik neem aan dat je doelt op deze post

voodooless wijzigde deze reactie 06-04-2011 20:29 (7%)

Ik vind dat 'gigantische' verschil eigenlijk wel meevallen... Die snelheden zijn zat acceptabel...

Als ik het zo zie valt dat inderdaad mee. En vooral de eerste benches zijn de verschillen raar. In latere benches met wat tweaking klopt de schaalbaarheid eigenlijk best wel goed, ondanks 4k "probleem".

ZFS is dus 'beter' in een 'slechte' eigenschap dan we dachten