Het grote ZFS topic

[Verwijderd]

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. 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 6-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) [i]vdev[/i] [b]nog[b]niet uitbreiden met één of meer disks ([sub]dat is nog in ontwikkeling[/sub]). 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). * - Zie uitleg een stuk terug bij voordelen ZFS 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 en afgeleiden als Illumos • FreeBSD • Linux • In iets beperkte mate OSX 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 ontwikkelen, maar het originele team achter ZFS is verdwenen met de overname. Beschikbare varianten: • Nexenta (Stor); een op (Open-) Solaris (/Illumos?) gebaseerde distributie speciaal ontwikkelt voor NAS/SAN gebruik. Gratis versie is gelimiteerd tot 18TB. • napp-it; een uitgebreide web-interface voor Illumos. • 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, sinds FreeBSD 7.0 geïntegreerd (waar we tegenwoordig op 11 zitten, dus al erg lang). FreeBSD heeft 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 met first class support voor ZFS inclusief de webGUI. • 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. In de praktijk is het op veel besturingssystemen intussen erg gemakkelijk geworden om het te installeren, voor systemen als Ubuntu zijn er al PPA's om ZFS te installeren, en Gentoo levert bijvoorbeeld de sourcecode gewoon mee in de ISO. Beschikbaar zijn: • ZFSonLinux (Kernel implementatie) • ZFS-on-Fuse (Userland Fuse implementatie) (eigenlijk af te raden ten opzichte van eerstgenoemde, mits zwaarwegende redenen zoals geen root toegang.) • 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 virtualisatie te gaan werken, maar dat zou ik alleen doen als je daar bekend mee bent. Vragen over ZFS icm een specifiek virtualisatie pakket kan je beter stellen in het topic voor het desbetreffende virtualisatie pakket, dat zorgt ervoor dat dit topic minder vervuild.

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: Elke moderne Celeron (G1610 / G1820) of Pentium (G3220 etc) voldoet voor ZFS. Oudere Atom's (op de Avoton na) zijn niet aan te raden, die kunnen maar 4GB geheugen aanspreken, en dat is een veel gevallen te krap. Het kan wel, maar dan moet je goed weten wat je doet, en wat ZFS tuning toepassen. CurlyMo heeft ZFS aan de praat op een miniscuul x86 bordje, met maar een beperkte hoeveelheid RAM. Geheugen: Minimaal 4GB is aan te raden. Wil je 1Gb Ethernet continu blijven halen, is 8GB aan te raden. Moederbord: Maakt weinig uit, zoek in de reviews naar een zuinig bord met een leuke AHCI controller. In het DIY RAID NAS topic komen legio bordjes langs die lekker zuinig en modern zijn. Wat misschien nog wel de belangrijkste tip is: Kijk of bijvoorbeeld elk budget onderdeel (zoals de netwerkkaart) ondersteund is in het OS dat je wil gebruiken. Zo zijn FreeNAS en Solaris afgeleiden wat kieskeuriger qua hardware dan Linux. Krachtige ZFS NAS Processor: Een sterke i5 of Xeon. Socket 1150/1151(v1/v2) of 2011(-3). Voor ECC support moet je even goed opletten. Moederbord: Een Supermicro of gelijkwaardig bord dat ECC support. Geheugen: ECC! (Let op dat Registered geheugen alleen werkt op Socket 2011(-3), en dat je voor Socket 2011-3 DDR4 geheugen nodig hebt. Qua hoeveelheid ligt het een beetje aan je pool, maar als je echt een krachtige server wil is 16 of 32GB aan te raden. Als je ZFS gaat combineren met ESXi een een flink aantal VM's, wil je al snel richting 32GB gaan. Controller: Er zijn SuperMicro borden met onboard LSI2308 controller. Mooie aanrader! Wil je een losse HBA, kan je voor bijvoorbeeld een IBM M1015, Dell H200, of een LSI 9201-16i gaan. Voordat je iets koopt, check even in de topics of deze controllers op het moment nog steeds gangbaar zijn. Er veranderd nog wel eens wat in storage land, en ook wij kunnen niet continu de startpost blijven updaten. Schijven: Western Digital Green of Red zijn momenteel erg populair. De nieuwste Seagate series zijn ook veel in gebruik. Let op dat je goed moet kiezen tussen TLER of non-TLER schijven. Beide hebben hun voor- en nadelen. Hitachi maakt volgens velen technisch de beste schijven, maar er zijn vooral 7200RPM schijven van Hitachi, dus zit je qua stroomverbruik al snel hoog met Hitachi.

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.

Hoe zit het precies met TLER-disks in combinatie met ZFS?

Voor de meeste Hardware RAID en Windows FakeRAID is TLER verplicht. Dit is een functie van de hardeschijf die de error recovery min of meer uitschakelt, door deze te beperken tot 7 seconden. Dit voorkomt dat de RAID engine de schijf uit de array gooit zodra er bad sectors gevonden worden en je met een kapotte array zit. Bij ZFS en non-Windows software RAID is dat anders. Daar heb je geen TLER nodig om je data te beschermen. Toch kan het beperken van de timeout wel voordelen bieden door lange wachttijden bij bad sectors te voorkomen. Je videostream zou hierdoor onderbroken kunnen worden en ook Virtual Machines vinden het niet fijn als ze een tijd lang niet met hun disk kunnen communiceren. Echter, wat je met TLER hardwarematig doet, kan je operating system ook softwarematig. Zo kun je onder BSD-platform de timeout instellen, wat hetzelfde effect geeft als TLER. Andere platforms bieden mogelijk vergelijkbare functionaliteit. TLER kan daarnaast ook heel gevaarlijk zijn. Het schakelt min of meer de 'laatste defensielinie' uit. Stel je hebt een redundante array zoals een RAID1/mirror waarbij één disk helemaal dood is. De overige disk heeft bad sectors. Dan is de recovery-functionaliteit van de hardeschijf de laatste kans om je data helemaal intact te kunnen uitlezen. In zulke gevallen is TLER zeer onwenselijk en kan een gevaar opleveren voor je gegevens. In gevallen waar je nog wel over redundantie beschikt, maakt het voor je data niet uit.

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 • BSD Now - ZFS

Handige tutorials:

Migreren van data binnen dezelfde pool Upgrade van v28 naar v5000 zonder alle features te activeren Hoe werken feature flags Lijst met gesupportte features flags per platform ACHI SSD in FreeBSD 9.1 ZFS send/receive van en naar een bestand Patitioneren van je SSD voor je systeem, SLOG en L2ARC (in ZFSGuru) ZFS send/receive op een corrupte pool Draaien op en terugzetten van een ZFS On Root backup ZFS send/receive tussen pools ACL + Samba voorbeeld Aanvullingen? Laat het weten!

[ Voor 255% gewijzigd door FireDrunk op 29-11-2018 08:47 . Reden: ZFSguru er uit, wat versie updates, feature flags linkje toegevoegd. ]

[Verwijderd]

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.

[ Voor 99% gewijzigd door Verwijderd op 02-12-2012 00:36 ]

[Verwijderd]

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

[ Voor 81% gewijzigd door Verwijderd op 02-04-2011 00:40 ]

[leuk_he]

Verwijderd 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...

[ Voor 6% gewijzigd door leuk_he op 03-04-2011 14:07 ]

[Wouter.S]

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...

[Verwijderd]

alle begin is moeilijk

wat ik eigenlijk wilde zien is de sector size nu ik 4 dezelfde 204 drives in een pool heb
ashift=9 means optimized for 512-byte sectors
ashift=12 means optimized for 4K sectors

en ik lees het volgende mbt L2ARC cache :

'I have zfs cache (L2ARC) on SSD ocz revox2.

But i read that L2ARC was designed to either improve performance or do nothing, so there isn't
anything that should be bad. To explain what is meant by do nothing - if you
use the L2ARC for a streaming or sequential workload, then the L2ARC will
mostly ignore it and not cache it. This is because the default L2ARC settings
assume you are using current SSD devices, where caching random read
workloads is most favorable.

Anybody know how i can tune L2ARC's settings for working L2ARC with a streaming or sequential workload?

In FreeNAS 8 RC4:
freenas# sysctl vfs.zfs.l2arc_noprefetch
vfs.zfs.l2arc_noprefetch: 0

But I don't know how I can edit sysctl.conf for working vfs.zfs.l2arc_noprefetch=1 after reboot? '

als je nu voornamelijk films streamt vanaf je zfs pool .. dan heeft een cache geen zin want zfs gebruikt het toch niet ?

* iets gevonden :

There are some changes that can be made to improve performance in certain situations and avoid the bursty IO that's often seen with ZFS.

Loader tunables (in /boot/loader.conf):

# Disable ZFS prefetching

# http://southbrain.com/sou...are-comes-slowly-zfs.html
# Increases overall speed of ZFS, but when disk flushing/writes occur,
# system is less responsive (due to extreme disk I/O).
# NOTE: Systems with 4 GB of RAM or more have prefetch enabled by default.
vfs.zfs.prefetch_disable="1"

# Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This
# should increase throughput and decrease the "bursty" stalls that
# happen during immense I/O with ZFS.
# http://lists.freebsd.org/...2009-December/007343.html
# http://lists.freebsd.org/...2009-December/007355.html
vfs.zfs.txg.timeout="5"

Sysctl variables (/etc/sysctl.conf):


# Increase number of vnodes; we've seen vfs.numvnodes reach 115,000
# at times. Default max is a little over 200,000. Playing it safe...
# If numvnodes reaches maxvnode performance substantially decreases.
kern.maxvnodes=250000


# Set TXG write limit to a lower threshold. This helps "level out"
# the throughput rate (see "zpool iostat"). A value of 256MB works well
# for systems with 4 GB of RAM, while 1 GB works well for us w/ 8 GB on
# disks which have 64 MB cache. <<BR>>

vfs.zfs.txg.write_limit_override=1073741824

Be aware that the vfs.zfs.txg.write_limit_override tuning you see above
may need to be adjusted for your system. It's up to you to figure out
what works best in your environment.

[ Voor 147% gewijzigd door Verwijderd op 10-04-2011 15:59 ]

[Verwijderd]

zfsguru.. zelfde 'zfs motor' als FreeNAS , mijn indruk, meer snelheidsfluktuatie , min of meer even snel.

[Verwijderd]

leuk_he schreef op maandag 11 april 2011 @ 10:54:
[...]

Heb je gezien dat er ook een 1.7 (oudere) preview versie is met een zfs pool versie 28?

eerlijk gezegd had ik er overheen gekeken.



is zfs pool 28 sneller tov 15 ? inmiddels OpenIndiana aan het bekijken

[ Voor 23% gewijzigd door Verwijderd op 11-04-2011 12:06 ]

[Verwijderd]

Wat betreft snelheid: dat kun je niet zomaar vergelijken. ZFS v15 kan nieuwere code hebben dan ZFS v28.

OK.. maar ik, als leek, kijk gewoon naar .. 'hoe snel is mijn samba share, gisteren met FreeNAS 8 ( ZFS15) /raidz gem. 100 mb .. stabiel (schrijven / 66 lezen), daar ben ik tevreden mee.

Maar aangezien ik ook andere taken heb/wil moet ik toch naar een wat volwaardiger systeem toe (wel met ZFS), met alle gevolgen van dien want ... lezen/prutsen/falen/lezen/vragen ..

(het lijkt mij leuk om tzt een lcd info panel erin te fabrieken (via usb)...)

maar inmiddels ben ik ook bij ZFS 28 aangekomen (tussen het zonnen door)



* resultaat 1e bonnie ++ > http://img232.imageshack.us/img232/6155/bonnieone.jpg

natuurlijk een SMB share aangemaakt:
schrijven _{van windows client naar OpenIndiana zfs 28 pool :}

lezen :



- in vergelijking met FreeNAS/ZFS 15 is OpenIndiana/ZFS 28 met lezen cifs ca. 15% sneller !

ga hetzelfde nog eens proberen met een ssd cache aan de poel ..

[ Voor 35% gewijzigd door Verwijderd op 11-04-2011 20:59 ]

[Verwijderd]

het installen van openindiana op een usb sticky maar even aan de kant gegooid en een verse 1 tb sata disk opgeofferd (overkill..ik weet het)

nieuwe pool aangemaakt met 4 x 204's en dit maal 60 gb ssd write cache.. en ineens valt mijn oog op het volgende in napp-it (mooi mooi) :



hij staat dus op 512b sektor size terwijl deze pool 4k sektorsize kan, blijkbaar moet je dat toch zelf ergens gaan instellen.
ik ga nieuwe poging doen die evt. glitches in beeld te krijgen.

[Verwijderd]

af en toe glitch.. hier 10 gb via smb van win client naar pool zfs 28

* opnieuw opgebouwd, nu met zfs 15.. exact hetzelfde beeld

---

openindiana oi-dev-148-x86/napp-it 0.415p
intel(R) Core(TM) i3 CPU 540 @ 3.07GHz
MSI H55M-ED55 - Micro ATX
Intel PRO/1000 GT Netwerkadapter
8 GB : 2 x 4 GB - DIMM 240-pins - DDR3 - 1333 MHz / PC3-10600 - CL9 - 1.5 V - ni
Intel RAID Controller SASUC8I (IT flashed)
4 x Samsung EcoGreen F4EG HD204UI in raidz
1 x OCZ agility2 60 gb ssd poolcache
boot'disk hd103sj
level one gsw o841 switch

---

[ Voor 80% gewijzigd door Verwijderd op 12-04-2011 18:34 ]

[x-RaY99]

Hierbij nog een screenshot van het copy'en van een windows box naar de OpenIndiana ZFS pool.
Dit dus over gbit, via cifs naar een dual quad met 12GB geheugen en 4 2TB schijven.

Je zou toch verwachten dat de gbit verbinding vol te trekken moet zijn. Volgens de benchmark in napp-it zou de pool 220MB/s write en 320MB/s read moeten kunnen doen. CPU usage staat bij seq write wel op 99%, maar dat is van 1 core.

[x-RaY99]

Op het atom bordje met 4GB geheugen en 24x 2TB schijven (via de intel/lsi sas HBA) is de performance zoals te verwachten erg laag. Kernel tijd zit continue over de 90% met een 200MB vrij geheugen.

Zaagtanden ohne ende:



Dus op zoek naar een uATX bordje met een i5 en een sloot geheugen. Asus zou je moeten vermijden lees ik, gigabyte/msi zou dan wel kunnen. Max geheugen bij die bordjes is zo'n 16GB las ik, alleen de (vergelijkbare) supermicro bordjes kunnen 32GB ECC behappen.

[Verwijderd]

ben een beetje aan het spelen met mirrors in de vdev



- Automatic ZFS Snapshot Rotation on FreeBSD
- Automatic ZFS Snapshot Rotation on FreeNAS

[ Voor 48% gewijzigd door Verwijderd op 14-04-2011 13:50 ]

[Verwijderd]

[b]
Dit alles onder OpenIndiana met Napp-it 0.416a.

dat heb ik momenteel ook draaien.. zit alleen met dit, of is dit normaal ? :



heb geinstalled vanaf de live cd ..
* zojuist van 8 naar 16 gb.. merk nog weinig verschil

[ Voor 9% gewijzigd door Verwijderd op 15-04-2011 10:41 ]

[Verwijderd]

hoe is dit mogelijk.. 2x dd bench direkt achter elkaar en verschillende waarden en dan die nogal vreemd hoge read... iemand


[ OI/napp-it/16gb/raidz2 6x2tb + 1x spare ]

[Joseph]

Dadona schreef op zondag 17 april 2011 @ 22:07:
Mis ik iets of lijkt dat gewoon op de meest recente versie van FreeNAS qua web interface?

Euuhhh?

Dit:


vs Dit:

Maakt toch een behoorlijk verschil...

[Dadona]

FreeNAS 8 RC2

[Verwijderd]

van win7-64 naar samba share in zfs tank onder openindiana/napp-it

[Verwijderd]

Tp21 schreef op woensdag 27 april 2011 @ 17:11:
btrfs kan net zoals ZFS zelf raid doen, op het moment raid 0 en 1, maar in de (nabije) toekomst ook raid 5 en 6.

Hey dat is nieuws voor mij -- je hebt gelijk! Voor RAID5 en 6 moet je dan nog wel naar ouderwetse lagen grijpen, maar dit betekent wel dat Btrfs inderdaad een geduchte concurrent van ZFS kan worden in de toekomst. Ik vond het erg jammer dat Btrfs (naar ik dacht) nog steeds 'ouderwets' RAID nodig had en dit niet zelf kon doen. Maar dat kan dus wel, gelukkig.

Gelukkig, want keuzevrijheid is duidelijk in het voordeel van eindgebruikers. ZFS is fantastisch, maar een goed alternatief voor Linux-gebruikers is zeker niet verkeerd. Dat gezegd, voorlopig blijft ZFS toch wel de beste keus voor een NAS met goede bescherming voor je data, in elk geval totdat Btrfs volwassen is geworden.

@raymonvdm: zelf zou ik oude 80GB disks in de prullenmand gooien; die verbruiken relatief héél veel energie voor héél weinig opslag en zijn ook erg traag. Een 80GB disk heeft 40GB platters schat ik, dat is héél veel stappen terug van de huidige 666/750/1000GB platter generatie waar we nu zitten.

40GB @ 8W = 5GB per watt
2000GB @ 4W = 500GB per watt

Nieuwe schijven zijn dus een factor 100 zuiniger per opslageenheid. Laat staan de snelheid. Met de prijzen van Samsung F4 2TB is ook niets mis.

@warcow: Atom of Zacate zou prima moeten kunnen voor een simpele RAID-Z met weinig disks. Voor 8 disks of minder is dat wel oke, als je geen topsnelheid verwacht en geen geavanceerde functies als SHA256 checksums, compressie, encryptie, deduplicatie enzo gebruikt. Ook een Atom kan >2GB/s aan XOR doen.

Maar de beperking van Atom is dat je max 4GB RAM hebt, terwijl Zacate tot 16GB (in de praktijk 2x4= 8GB) kan doen. Bovendien biedt Zacate je een modernere chipset met 6x 6Gbps SATA. Nadeel is weer dat de gangbare bordjes geen Intel SASUC8i controller ondersteunen, dus uitbreiding is dan weet een probleem.

Hoeveel geheugen je nodig hebt ligt aan je wensen, maar voor een simpele config is 4GB prima te doen. Minder zou ik niet doen, dat ga je in elk geval in de snelheid merken. Ga je voor Zacate dan zou ik zeker 2x4= 8GB nemen, 1.35V DDR3 is mogelijk voor een nog lager verbruik.

Dat sub-10W Core i3 is alleen mogelijk met heftige tuning, reken op 22W met een PicoPSU met een kaal systeem (voeding, moederbord, geheugen en cpu-fan). Als je een conventionele ATX voeding wilt gebruiken kan het verbruik snel stijgen tot 40W - de meeste ATX voedingen zijn erg inefficient bij lage loads (50-60W schat ik). Ook 80+ voedingen met certificaat; die worden namelijk niet lager dan 20% load getest - en zelfs een 300W voeding is bij 20% load al 60W. Zie bijvoorbeeld dit plaatje:

[Verwijderd]

viel mij wat tegen



> bonnie++ results
-
hier nog een (wat vreemd) testje - 4 mirrors

[ Voor 252% gewijzigd door Verwijderd op 14-05-2011 15:20 ]

[Verwijderd]

Ultraman schreef op vrijdag 13 mei 2011 @ 13:41:
[...]

Ik wilde net gaan vragen: "Pomp je data over middels Samba over een Gigabit netwerk?"
De eerste is erg onbetrouwbaar om snelheid te testen en de tweede trek je gewoon vol.

Ik snap dat het wel realistische data is, want dit is blijkbaar wat je er mee zult doen.
Maar het zegt weinig over de snelheid die je met verschillende ZFS stripes kunt behalen. Eerder dat Samba + Gigabit bij jou gelukkiger wordt van een single disk.

er liggen nu 2 patchkables over de vloer ..



kijken hoe/en of dat werkt

[Verwijderd]

zit ineens met de volgende vraag.
sluit een ntfs geformatte externe disk via esata/usb aan op openindiana en systeem wil niet (auto)mounten.
ziet hem wel.


hoe doe ik dat.. via de terminal

[Verwijderd]

DARKLORD schreef op zaterdag 14 mei 2011 @ 12:37:
openindiana draait hier echt goed. freebsd had ik soms spontane reboots. al dat uitgeklede (van operation systems) schiet gewoon niet op. openindiana heeft ook nog een GUI wat handig is. napp-it kan alleen nog wel wat beter met functies. vind het gebruik van previous versions in windows nog steeds geniaal. en het instellen van rechten op de windows server ACL manier

sabnzbd installeren ging makkelijk. ik krijg alleen transmission 2.22 niet gecompiled. iemand daar succes mee? package van opensolaris is namelijk nog maar transmission versie 1.x

binnenkort moederbord kopen met VT-d en dan esxi installeren. pci passthrough HBA naar OI voor NAS. en dan daarnaast nog een web/mail server installeren.

is het ook noodzakelijk om een Xeon processor te kopen voor vt-d? en heeft een xeon verplicht ecc geheugen nodig?

gebruikte jij nou ook een geflashte intel raid controller SASUC8I ?

zoja.. zou jij voor mij is kunnen kijken (via ssh) .. ik krijg steeds iets vreemds, welke disk/kabel ik ook pak.
' Failed to inquiry this logical disk '


format -e </dev/null | egrep "[0-9]\."

[Verwijderd]

[Verwijderd]

Dan maar alle fans losgekoppeld en de case open laten staan tot de nieuwe er zijn.
Dit is in bestelling:
Nexus 80mm PWM Real Silent Case Fan SP802512H-03PWM x4
Scythe mini-KAZE 60mm SY602012L x2
En zo blijven we bezig , tijd voor bier

ben erg benieuwd of dat nu veel uitmaakt .. heb ook 80mm fannetjes gezien van 6 db en fanvibratie isolators.

en omdat mijn zfs nas voor de miljoenmiljardste keer helemaal uit elkaar lag en ik onderdeel voor onderdeel ben gaan testen, gelijk even gekeken naar de verschillen tussen een disk aangesloten op een geflashte SASUC8I en direct op mobo... valt reuze mee eigenlijk.

[ Voor 54% gewijzigd door Verwijderd op 31-05-2011 20:25 ]

[Verwijderd]

txt versie OI 151 is beschikbaar




* zoals te zien had/heb ik een IRQ probleem op 16

[ Voor 19% gewijzigd door Verwijderd op 06-06-2011 11:26 ]

[Verwijderd]

dit is nog niet veranderd

he ..
Name : driver/storage/mpt_sas
Summary : LSI MPT SAS 2.0 Controller HBA Driver
Publisher: openindiana.org
Version: 0.5.11
Build Release: 5.11
Branch: 0.151
Packaging Date: Mon May 23 15:30:06 2011
Size: 684.21 kB
FMRI: pkg://openindiana.org/driver/storage/mpt_sas@0.5.11,5.11-0.151:20110523T153006Z

[ Voor 64% gewijzigd door Verwijderd op 10-06-2011 23:40 ]

[Verwijderd]

mocht het gaan regenen :



leesvoer

[FiXeL]

Beetje bezig geweest met de toekomstige Freenas server:



Dit kaartje had ik nog liggen, een 2GB USB stick op bankpas formaat, met dank aan Mokveld

Eenmaal uitelkaar gesloopt (hey, het kaartje heeft de afgelopen paar jaar flink wat beschadigingen opgelopen aan de buitenkant, en was gratis gezien het een relatiegeschenk was)



Het PCB-tje op een stukje printplaat geplakt, en een interne USB header eraan gesoldeerd....



Aan de onderkant nog wat verlichting plakken....



En voila... Inpluggen en intern een 2GB drive + verlichting voor de aanstaande installatie van Freenas 8.0. Er komt naast de hardware voor mijn nieuwe systeem ook 4x 2GB DDR2 geheugen aan, en 6x 2TB hitachi HDD's.

[Kriss1981]

Verwijderd schreef op maandag 25 juli 2011 @ 03:04:
Waar zie je die 'aggressive' memory tuning eigenlijk?

Op deze afbeelding zijn de ZFS tuning opties te zien, waar je tijdens de installatieprocedure uit kunt kiezen.

Verwijderd schreef op maandag 25 juli 2011 @ 11:58:
Je kunt in top kijken hoeveel ruimte je vrij hebt. Probeer eens lokaal iets van 100 gigabyte schrijven ofzo; en dan na een aantal minuten maximale load kijken hoeveel geheugen je echt vrij hebt. Is dat minder dan 1 gigabyte dan raad ik aan je memory tuning iets te verzachten. En sowieso: gebruik SWAP! Met ZFS ZVOL kun je heel mooi swap inschakelen. Commando's kan ik voor je opzoeken als je wilt.

Wanneer het systeem alleen gebruikt wordt door BOINC is er ongeveer 4 á 5GB vrij geheugen en tijdens het schrijven van 128GiB schommelt dit tussen 700 en 1100MB. Het is dus mogelijk om de projecten die meer geheugen vereisen mee te laten doen.

Met ZFSguru kan ik via de webinterface een ZVOL aanmaken. Hoe groot moet deze zijn? 1xRAM?

Hieronder de resultaten van de benchmark. Ben er zeer tevreden mee, want trek mijn gigabit lijntje mooi vol. Alleen wanneer het systeem tijdens het streamen van een bluray gaat parren/rarren dan wil de film nog wel eens gaan stotteren. Dit komt waarschijnlijk doordat het downloaden/parren/rarren op dezelfde pool gebeurt. Dit vanwege een tekort aan SATA poorten. Er komt binnenkort een LSI kaart bij met 8xSATA, zodat ik een aparte pool kan maken voor SABnzbd.

Pool : data
Read throughput : 443.9 MB/s
Write throughput: 242.7 MB/s

[Sleepie]

CurlyMo schreef op zaterdag 30 juli 2011 @ 14:01:
Al geprobeerd om handmatig je duplex mode in te stellen?

Dit is wat ik zie in napp-it:


Ziet eruit als full duplex toch? Alleen 100 mbit ipv 1 gbit

Als ik trouwens die tweede NIC activeer, kan ik helemaal niet meer inloggen op de napp-it web GUI

[Verwijderd]

1 - 'zuinige' server met de E35M1-M PRO .. sasuc8i werd niet herkend.



2 - in de MSI H55M-ED55 werkte die wel.



maar toen bedacht ik me 'he..ik wil een 2e sasuc8i erbij plaatsen' .. dat werkte weer niet.

3 - uiteindelijk die 2 kaarten aan de gang op een super micro X8sil-F





mijn oorspronkelijke budget is daardoor wel iets overschreden

[ Voor 3% gewijzigd door Verwijderd op 31-07-2011 11:22 ]

[FiXeL]

Mn NAS is bijna af!



Specs:

Mobo: Asus P5Q Pro
CPU: Intel E8400 Core 2 Duo @ 3Ghz
RAM: 4x 2GB Kingston DDR2
VGA: Cheapass pci-e kaartje
HDD: 6x 2TB Hitachi in Raid-Z2
OS: Freenas 8.0

Draait super! Totaal 7.8TB opslag, en ik haal gemiddeld iets van 70MB/Sec. met uploaden naar de nas, tot pieken van 100MB/Sec. Alleen heb ik een vraag over de swap file... Er wordt bij het samenvoegen van een Raid-Z2 array per schijf 2GB gereserveerd voor een swap file.. Maar die wordt nauwelijks gebruikt omdat het geheugengebruik niet boven de 6,5GB uitkomt. Is dit normaal, of gaat het OS meer Ram gebruiken zodra de HDD's voller raken? Volgens de GUI van Freenas wordt er maar een paar MB van gebruikt zo nu en dan.

[warcow]

Of spindown werkt moet ik nog even controleren. Het verbruik zonder spindown is 50 Watt. Als hij stevig bezig is stijgt het verbruik naar max 70-75 Watt. (Spindown staat al wel aan, maar toen ik thuiskwam was het verbruik nog steeds 50 Watt dus ik hier kijk ik nog even naar)

Bij deze een screenshot van de statistieken. Tijdens deze statistieken beschrijf ik de nas vanaf een windows 7 pc met CIFS. Dit gaat volgens windows met 50 mb/s. (gigabit lan, ik lees vanaf een 500gb sata schijfje)


Advanced power management staat op level 1, wat doet dit precies? (kan het zo snel nergens vinden online)

edit: aha, volgens dit: http://support.freenas.org/ticket/242 moet de APM op minimaal 127 staan omdat de schijven anders meteen een spindown doen als er een paar seconden niks gebeurt. Het zou prima kunnen dat mijn schijven meteen al een spindown doen. (zo klinkt het ook steeds als ik weer iets probeer te lezen/schrijven)
In dat geval moet ik genoegen nemen met 50 Watt verbruik in spindown. Had liever 40 gezien maar dit is nog acceptabel.

[ Voor 32% gewijzigd door warcow op 24-08-2011 21:59 ]

[Pantagruel]

Sleepie schreef op vrijdag 26 augustus 2011 @ 12:24:
SuperMicro heeft naast de op Marvell controllers gebaseerde kaartjes ook nog wel op LSI chipjes gebaseerde kaartjes.
Bijvoorbeeld de pricewatch: Supermicro AOC-USAS-L8i (LSI1068E kloon, net als de SASUC8i).
Die zou je er nog bij kunnen zetten
(Let wel op, geen standaard formfactor dat kaartje)

Klopt is een UOI kaart (min of meer een 'op de kop' uitvoering van een normale PCIe kaart), maar dat zal een recht geaarde tweaker niet remmen. Een bracket verbuigen/modden of nylon afstandhouders werkt goed. In het geval van t laatste verlies je wel 2 slots voor t plaatsen van 1 kaart als je dit picje zo ziet:.



Maar als je de spacers op de juiste manier plaatst lijkt het dat je slechts 1 slot gebruikt en niet 2 posities gebruikt.



En inderdaad de HBA's met een Marvel chipset lijken voornamelijk kommer en kwel te veroorzaken.

[ Voor 5% gewijzigd door Pantagruel op 26-08-2011 13:16 ]

[Bierkameel]

Ik ben een server aan het bouwen met FreeNAS 8.
Mobo: Supermicro X7SPA-HF-D525 met een Atom D525 dus en 4GB DDR3 en 2 x Intel GBit NIC onboard.
4 x 2TB Samsung EcoGreen F4EG HD204UI
1 x WD Raptor WD3000HLFS 300GB 10K schijf als cache schijf.
Installatie op een 16GB Sandisk stick.

Als ik een raidz pool aanmaak met de cache schijf dan haal ik zo'n 60MB/sec lezen en schrijven, de CPU is niet echt druk dus dat moet sneller kunnen lijkt me? Met of zonder cache schijf lijkt ook niet veel verschil te maken.
In de BIOS staan de poorten op AHCI, HT heb ik uitgeschakeld dus hij zit 2 echte core's ipv 4 core's met HT maar dat maakt ook niet veel verschil, ik heb de X64 en X86 versie van FreeNAS al geinstalleerd.


Hmm was wat grote bestanden aan het kopieren en toen kreeg ik dit:

[ Voor 15% gewijzigd door Bierkameel op 11-09-2011 13:17 ]

[Pantagruel]

Verwijderd schreef op zaterdag 17 september 2011 @ 12:21:
..snipzz..

Dat is de hele clue achter de 'GNOP optimization for 4K disk' methode onder FreeBSD.

..snipzz..

Gisteren 2x 2TB EARS (de 'beruchte' 4k sector disks) bijgekocht om op 't magische getal van 10 disks in totaal te komen.

De harde waren in gebruik (table top test opstelling)

SuperMicro X9SCM-F
Xeon E3-1230
4x4GB Kingston ECC UDIMM
Areca ARC-1221x
1x 36 GB WD Raptor tbv ZFSGuru 0.1.8
10x 2TB WD EARS
560W Chieftec PSU
Verdeling van disks:
- Areca ARC-1221x (8x 2TB EARS in pass-through mode, write-through caching)
- On-board SATA 2x 2TB EARS

De Areca heb ik ter test in pass-through in gebruik, het is min of meer toch zonde om een echte hardware RAID controller op deze manier te gebruiken. Binnenkort zal de ARC-1221x plaats maken voor een IBM M1015 (=LSI 9240 8i zonder R5/R50 ondersteuning) welke in IT mode gaat draaien.

Array data vlgs ZFSGuru:



Benchmark run van de array, bij de keuze voor 'default' bij 'sector size override':



Benchmark run van de array, bij de keuze voor '4K' bij 'sector size override':



In ieder geval is te zien dat een geforceerde 4K sector size override betere benchmark resultaten laat zien dan de auto optie. Nu is de interne benchmark routine wellicht niet de beste marker om op af te gaan maar wel een makkelijke om even te doen.

[Pantagruel]

Prut, gedonder in de glazen

Klaarblijkelijk is de Areca ARC-1221x niet zo erg blij met 8x een 2 TB EARS in pass-through mode.



Een handje vol read en write errors stak de kop op na een kopieer actie ca. 300 GB richting de NAS.
Mbt de data is er niets aan de hand, voorlopig is slechts een test.

Ik ben wel benieuwd of dit soort gezeur verdwijnt zodra ik de IBM ServeRAID M1015 in IT mode heb en de array laat doen. De Areca is zo te zien te 'edel' om als domme HBA te gebruiken.

Een 'zpool clear Vault' gaf slechts 76k aan 'resilvered' data.



In de tussentijd de array maar eens wat meer 'stressen' en wat data om de oren gooien, zien wat er dan uit komt rollen.

De firmware van de ARC-1221x is trouwens v 1.47 en zou een fix moeten bevatten voor ZFS en JBOD/pass-through mode.

..
2009-6-2
1 Fix Opensolaris+ZFS to add device to mirror set in JBOD or passthrough mode
2 ARC1680 BIOS:add 3 minutes timeout
..

Update-tje 00:14

ARGGHHHH

Zit ik net mijn eigen eerdere post te bekijken, zie ik dat de data van nu geen 'gnopped' drives zijn.

Output van:

diskinfo -v /dev/ada[12]

/dev/ada[1/2]

512 # sectorsize
2000398934016 # mediasize in bytes (1.8T)
3907029168 # mediasize in sectors
4096 # stripesize
0 # stripeoffset
3876021 # Cylinders according to firmware.
16# Heads according to firmware.
63 # Sectors according to firmware.
WD-WCAZA4302486 # Disk ident.

diskinfo -v /dev/da[01234567]

/dev/da[0 t/m7]
512 # sectorsize
2000398934016 # mediasize in bytes (1.8T)
3907029168 # mediasize in sectors
0 # stripesize
0 # stripeoffset
243201 # Cylinders according to firmware.
255 # Heads according to firmware.
63 # Sectors according to firmware.
WD-WCAZA5515171 # Disk ident.

Klaarblijkelijk is het dus niet goed gegaan en is de ZFS pool terug gezet naar de 512 Byte instellingen van de eerste aanmaak van de pool. De switch naar de 4k sector override heb ik na de benchmark run gedaan door de pool eruit te mikken en opnieuw aan te maken, klaarblijkelijk werkt dat dus niet op die manier.
Morgen de pool eens echt om zeep helpen (destroy pool) en dan t riedeltje van voren af aan beginnen, ach zo testen we wat af

[ Voor 64% gewijzigd door Pantagruel op 20-09-2011 00:20 . Reden: Update ]

[zzattack]

@Pantegruel: het is gelukt


Het kostte de nodige debugging.. Maar uiteindelijk rond half 3 werkte het

Enkele pointers:
- de default shadow:format is "@GMT-%Y.%m.%d-%H.%M.%S", deze moet je overriden zodat het voorste apenstaartje wegvalt
- de shadow dir paths worden (onterecht) als symlink buiten de share gezien en met de default setting "wide links = no" mag dit niet. Workaround is wide links disablen. Die setting is ook incompatible met de default setting unix extensions = yes, dus deze overriden met no

code:

[global]
        wide links = yes
        unix extensions  = No

[share]
        path = /fileshare/
        vfs objects = shadow_copy2
        shadow:snapdir = .zfs/snapshot
        shadow:localtime = yes
        shadow:sort = desc
        shadow:format = GMT-%Y.%m.%d-%H.%M.%S

Ik heb het onder samba 3.6 voor elkaar gekregen omdat de debugging sinds de vfs_shadow_copy2 rewrite van juli sterk verbeterd is. Wellicht dat het met deze config ook onder de 3.5 versie uit de ports tree werkt.
Mocht je de samba 3.6 port niet gebuild krijgen, dan moet je misschien net als ik tdb upgraden:

portsnap fetch update
cd /usr/ports/databases/tdb
make install clean

[iRReeL]

pool: Archive
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-2Q
config:
NAME STATE READ WRITE CKSUM
Archive DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
c3t3d0 ONLINE 0 0 0
c3t5d0 ONLINE 0 0 0
c2t545d0 UNAVAIL 0 0 0 cannot open
etc...

En als ik dan een replace doe in napp-it





Vage nieuwe naam ook, zolang.. "c5t50014EE6AADF2AA3d0"

[Verwijderd]

Bierkameel schreef op donderdag 27 oktober 2011 @ 10:28:
Niet helemaal mee eens, ik heb zelf een Supermicro X7SPA-H-D525 met 2 x Intel GB, 6 x SATA en een PCIE 4x slot, en bovendien IPMI wat voor een servertje erg handig is, passief gekoelt en erg zuinig.

SuperMicro maakt leuk spul, maar Intel Atom is expres gecastreerd door Intel en dat maakt het voor ZFS niet zo'n heel interessant platform.

Atom beperkingen:

• PCI-express 1.0 ipv 2.0
• maximaal 4GiB geheugen; terwijl ZFS op FreeBSD pas lekker werkt vanaf 8GiB; Brazos kan 16GiB (2x8GiB) aan
• met de US15W chipset beperkt aantal SATA poorten; dat SuperMicro bord gebruikt wel een ICH9R wat natuurlijk beter is
• lagere performance dan Brazos (hoeveel weet ik niet precies; maar mogelijk heeft Brazos meer geheugenbandbreedte wat voor ZFS wel uit kan maken)
• last but not least: bijna het dubbele idle power, alhoewel je een PicoPSU moet gebruiken om dat te zien; met een normale voeding is het verschil veel kleiner.

Paar links met idle power vergelijkingen:




Bron: http://techreport.com/articles.x/20401/5

Met een zuinig Brazos bordje kun je mogelijk nog extremere verschillen zien. SuperMicro maakt overigens meestal wel zuinig spul, alleen jammer dat ze geen/nauwelijks AMD spul doen een Brazos-versie van dat mobo wat je noemt zou echt wel gaaf zijn.

FireDrunk schreef op donderdag 27 oktober 2011 @ 10:39:
Bedoel je deze?
pricewatch: MSI E350IA-E45

Beetje jammer van het fannetje

Die heb ik ja; 8,9W is het laagste waar ik aan kwam onder Ubuntu. Wel zonder HDD, DVD, SATA, netwerk en CPU fan. Die fan alleen al verbruikt 0,9W!

MSI maakt wel zuinig spul dus dit kan best wel eens het meest zuinige bordje zijn. Nu draai ik met 2 HDDs en gigabit en fan en 8GiB RAM op zo'n 14,1W, nog steeds erg netjes vind ik.

Maar die fan wil ik wel vervangen. Het liefst door een groter heatsink met Arctic Thermal Adhesive, dus lijm die fixeert zodat je geen klemmetjes enzo nodig hebt. Hopelijk gaat dat werken, dan zou ik een heel zuinig passief gekoeld systeem hebben.

Overigens: een Core i3 2100T kan ook superzuinig zijn met het juiste moederbord en PicoPSU, dus dat kan ook een optie zijn. Wel iets hoger piekverbruik wat uitmaakt voor PicoPSU en de hoeveelheid schijven dat je erop kunt aansluiten, maar Core i3 heeft wel betere performance, meer PCIe uitbreidingsmogelijkheden en een moderner platform. Maar ook wel duurder natuurlijk.

[ Voor 6% gewijzigd door Verwijderd op 27-10-2011 11:06 ]

[Danfoss]

Ik heb nu sinds 3 weken een ZFSGuru draaien op ESXi 5.
ZFSGuru draait zelf op een root-on-zfs install op een vmdisk op mijn esxi datastore (SSD). Ik heb 4 Samsungs F4 2TB via physical RDM gemapped en daar een raidz1 pool mee gemaakt. Deze pool is puur voor opslag en mediastreaming. Tot op heden werkte het wel ok. Voor mijn gevoel is de cpu usage een beetje hoog bij veel schrijven via nfs. Ik kan met zo'n 60Mb/s via netwerk schrijven, dat vind ik wel genoeg voor voornamelijk media streamen.

Nu zette ik vanmiddag een download aan op een andere vm die wegschreef op de pool en de performance donderde ineens in elkaar. Ik ben eens gaan kijken en zie in de console van ZFSGuru de volgende meldingen:


De smart status pagina geeft de volgende meldingen:


Wat ik sowieso raar vind is dat de power cycle count van die disk anders is dan de andere disks.
Is dit een doodgaande disk? Hij draait nu een scrub (76%, 200M/s) en heeft 4k repaired tot op heden.

[Verwijderd]

1 van mijn ZFS fileservers:
op Atom gebaseerd mammaplankje (D510) met wel 4GB aan RAM!
9 van die 1TB groene WD HDD's, 1 als boot disk en de rest in 4 mirrors (3,1TB netto ofzo).

vanaf elke client constante prestaties die meer dan voldoen:



mijn mening: als fileserver ALLEEN is het goed te doen, snel zat qua netwerkoverdracht.

[Verwijderd]

Nouja die random write kan minder dan 0,01MB/s zijn. Zie bijvoorbeeld:



Hardeschijven doen ongeveer 1MB/s dus 0,01MB/s is 100 keer langzamer dan een hardeschijf random writes doet, en we weten allemaal dat hardeschijven best traag zijn met random I/O (writes iets sneller dan reads).

[Femme]

Ik ben de afgelopen dagen beziggeweest met wat proefbenches op mijn systeem met twaalf Seagate Barracuda Green 2TB drives op twee LSI SAS2008-controllers en vijf OCZ Vertex 30GB drives op de onboard sata-controller van AMD SP5100-southbridge. De cpu is een Opteron 4122 met 32GB RAM. Er werd geboot vanaf een OCZ Vertex 120GB en ik heb er later ook nog een Adata S511 120GB (SandForce-chipset) aan toegevoegd als log-device. Deze hing aan één van de sas 6G-poorten. Verder zat er nog een Qlogic QLE2464 fibre channel-hba in.

OpenIndiana installeren ging zoals eerder gemeld voorspoedig. Ik heb me tot nu toe beziggehouden met het benchen van de prestaties van volumes die via iScsi of fibre channel worden geëxporteerd. Hiervoor heb ik gebruikgemaakt van onze standaard trace-based benchmarks die worden uitgevoerd door Intel NAS Performance Toolkit.

Een iscsi volume target creeëren en deze mounten via de iscsi-initiator van Windows 7 was simpel. Fibre channel was ook niet moeilijk alleen blijkt het niet mogelijk om multipath I/O te gebruiken in Windows 7. Voor MPIO moet je Server 2008 gebruiken.

In de testconfiguratie hingen de twaalf drives in een striped mirror. De l2arc bestond uit vijf Vertex 30GB drives.

De prestaties in de trace-based benchmarks waren nogal wisselvallend. In sommige gevallen was de bovenstaande configuratie niet sneller dan een enkele VelociRaptor 600GB, soms waren de prestaties beter dan van een enkele Vertex 120GB. Het toevoegen van een log-device aan de pool had geen duidelijk positief effect op de prestaties. In bepaalde tests zoals de boot- en game-traces waren de responstijden erg hoog (bijna factor tien hoger dan van een moderne ssd) terwijl deze traces naar verhouding veel goed cachebare reads bevatten. Het inschakelen van caching van prefetch reads (set zfs:l2arc_noprefetch=0) om de l2arc beter te vullen had ook geen duidelijk effect op de prestaties. Het verlagen van zfs_vdev_min_pending (minimale I/O queue van een vdev) van de default van 4 naar 1 had ook geen duidelijk effect. De fluctuaties tussen runs zijn veel hoger dan we normaal gesproken gewend zijn van harde schijven en ssd's wat het vergelijken bemoeilijkt.

De dataset van de trace benchmarks heeft een omvang van 90GB. Tijdens de tests wordt er 43,2GB aan data gelezen. In theorie kan dit gecached worden door de l2arc (5x 30GB). De grootte van de arc was 24,5GB. De l2arc groeide gedurende de tests naar bijna 30GB.

Om de resultaten in perspectief te zetten heb ik een VelociRaptor 600GB en een Vertex 120GB aan de grafieken toegevoegd. Een Vertex is naar huidige maatstaven een trage ssd. De nieuwste modellen zijn gemiddeld een factor twee sneller.

Workstationprestaties (o.a. traces van beeldbewerking in Photoshop, foto's beheren in Lightroom, video-editing in Sony Vegas Pro)



Prestaties van verschillende soorten file copies en I/O op de datapartitie in de Photoshop-, Lightroom- en Vegas Pro-traces.



Bootprestaties, traces van het booten van Windows 7 en het starten van applicaties op twee verschillende systemen. De gemiddelde responstijden waren hier erg hoog.



Trace van I/O op de datapartitie in de Sony Vegas Pro-trace. De trace bestond voornamelijk uit kleine redelijk willekeurige reads afkomstig van het inlezen van frames uit full hd-videofragmenten om deze op de tijdlijn weer te kunnen geven.



Trace van Photoshop, Lightroom inclusief alle activiteit van het besturingssysteem en de Photoshop-scratchfile. Daardoor relatief veel writes. Het zfs san presteert hier vrij goed. Het resultaat is de gemiddelde responstijd, dus lager is beter.



Je ziet in alle bovenstaande grafieken dat de prestaties over het algemeen toenemen als de benchmark wordt herhaald. De verbetering van de prestaties stopt na de derde run:





De bovenstaande resultaten vond ik teleurstellend gezien de specs van de achterliggende hardware (32GB RAM, een l2arc met vijf ssd's van 30GB, dedicated slog-device en twaalf disks in raid 10.

IOMeter liet op zich wel goede resultaten zien. De fileserversimulatie doet I/O's met een uiteenlopende grootte met een verhouding van 80/20 tussen lezen en schrijven bij oplopende queue-depths. Er werd getest op een testbestand van 16GB. De prestaties schalen uitstekend en er wordt blijkbaar goed gebruikgemaakt van de caches gezien het feit dat de prestaties veel hoger liggen dan van een enkele Vertex 120GB.



In IOMeter doet hij 23MB/s op 4K random reads met een queue = 1. Bij queue = 8 schaalt dit naar 104MB/s. Sequentiële reads zijn 156MBs bij queue = 1 en 343MB/s bij een queue van acht uitstaande I/O's. Dit zijn vrij goede resultaten.

Inmiddels heb ik ook Windows Server 2008 R2 geïnstalleerd om te kunnen benchen met multipath I/O. MPIO aan de praat krijgen is eenvoudig en een kwestie van deze feature toevoegen in het beheerdinges van je server. Onder Windows 7 zie je vier disks waarvan er drie niet gebruikt mogen worden omdat Windows herkent dat het om dezelfde volumes gaat die via verschillende paden worden aangeboden. Met AS-SSD haal ik uitstekende resultaten:



Het is me niet helemaal waarom de configuratie in NAS Performance Toolkit nogal matig presteert terwijl ik er uitstekende resultaten uithaal in AS-SSD en IOMeter.

[Verwijderd]

ZFSguru heeft twee nieuwe releases aangekondigd: 0.2-beta en beta2.

This version, 0.2-beta, adds some important features the ZFSguru web-interface was lacking so far.
• New Partition map editor for visual disk formatting
• New Disks->Memory page for configuring memory devices and file-images
• New Pools->Cache page for configuring L2ARC devices
• New Pools->Log page for configuring SLOG devices
• The Files->Browse page now uses AjaxPlorer when available
• The Pools page now can be used to perform disk operations such as disk replacement, converting single disks to mirrors, etc.
• The Pools->Create pagenow features an option to force the use of disks, even though they contain an old ZFS filesystem
• other changes I've missed.


Beta2, released on the 6th of January 2012, adds:
• new Files->Permissions page to manage file permissions and samba user authentication
• Files->Volumes allows creating thin-provisioned volumes called sparse zvols
• Files->Volumes allows creating swap devices
• Files->Volumes allows resizing existing volumes
• Disks can be sorted on the Disks->Formatting and Disks->SMART pages
• Files->Snapshots page has been redesigned with more functionality
• Allows upgrading filesystems on the Files->Filesystems page
• Allows upgrading pools to a specific version on the Pools->Status page
• Allows renaming pools by exporting and then importing using a different name


Download LiveCD
http://static.zfsguru.com...2.0-beta-livecd-amd64.iso

Link naar release topic: New release: 0.2-beta and beta2

In beide beta's kun je ook een stukje werk van mij zien, namelijk de partition map editor waar ik aan gewerkt heb. Dat ziet er ongeveer zo uit:



Als iemand hier eens wat Linux/Windows/Apple/Solaris diskjes onder ZFSguru wil laten draaien ben ik benieuwd of ze goed herkend worden. Daar valt denk ik nog veel aan te verbeteren.

[Verwijderd]

Overigens merk ik in benchmarks geen prestatieverschil tussen een pool met ashift=9 en ashift=12 bij gebruik van Seagate Barracuda Green 5900.3 harde schijven.

Zijn dat 4K schijven? Zo ja, dan merk je vooral verschil bij niet-optimale configuraties.

Optimale configuraties voor 4K schijven zijn:
RAID-Z: 3, 5 of 9 schijven (data_disks + 1 parity)
RAID-Z2: 4, 6 of 10 of 18 schijven (data_disks + 2 parity)
RAID-Z3: 5, 7 of 11 of 19 schijven (data_disks + 3 parity)
Zoals je misschien kunt zien, de data_disks moet een macht van 2 zijn, dus 1, 2, 4, 8, 16.

Dus als je een RAID-Z van 3 of 5 schijven maakt dan heb je ook bijna geen nadeel van de 4K sectors en heb je dus niet persé ashift=12 nodig.

Voor zvols kun je ook overwegen de 'sync' attribuut op off te zetten. Dan doe je geen sync writes meer en dat kan behoorlijk sneller zijn afhankelijk van je client.

Oh en Femme, als je ooit een testbak met veel schijven en veel RAM hebt, en je hebt even tijd.. wellicht kun je dan de Benchmark feature in ZFSguru eens gebruiken. Install ZFSguru eerst naar een extra systeem disk (normale hdd) want de livecd is niet voor ZFS performance getuned. Na die installatie kun je bij Disks->Benchmark een lange automatische benchmark starten die vele RAID-Z configuraties afgaat. Afhankelijk van de testgrootte kan dit uren of dagen duren met veel schijven. Maar je produceert wel hele mooie grafiekjes waarin je een aantal zaken kunt afleiden, zoals het schalen van performance met meer disks en niet-optimale configuraties.

Deze benchmark is destructief, dus je disks mogen geen pools of data bevatten. Doe alleen de sequential test. Ik zou de eerste run op de laagste test size houden zodat je ziet dat het werkt. De echte run moet minimaal 64GiB zijn voor goede nauwkeurigheid, maar 32GiB kun je eventueel ook overwegen. Eenmaal draaiende hoef je verder niets te doen; de pagina refresht en geeft de grafiek met (onvolledige) resultaten weer. Best een mooie feature.

Voorbeeld:

[Pantagruel]

Mijn Mellanox MHEA28-XTC HCA's zijn vandaag binnen gekomen (wat een ballen vervoerder is USPS, tracking info loopt hopeloos achter). ZFSguru 0.2.0-beta3 op CD gezet (De GA-X38-DQ6 die als test plank dient wil niet vanaf stick booten noch een BIOS update accepteren ("BIOS id check error") vanaf een USB stick. HCA erin gefrot en bootstrappen die handel [GA-X38-DQ6, E7400, 8Gib RAM, GTS8800 ( for some l33t gr4ph1c5 at the CLI)]

system's log knipseltje wat er toe doet mbt OFED:

Jan 19 18:48:47 zfsguru kernel: ib_mthca0: <ib_mthca> mem 0xea800000-0xea8fffff,0xea000000-
0xea7fffff irq 16 at device 0.0 on pci2
Jan 19 18:48:47 zfsguru kernel: ib_mthca: Mellanox InfiniBand HCA driver v1.0-ofed1.5.2
(August 4, 2010)
Jan 19 18:48:47 zfsguru kernel: ib_mthca: Initializing ib_mthca
Jan 19 18:48:47 zfsguru kernel: Trying to mount root from ufs:/dev/md0 []...
Jan 19 18:48:47 zfsguru kernel: WARNING: TMPFS is considered to be a highly experimental
feature in FreeBSD.
Jan 19 18:48:47 zfsguru kernel: ib_mthca0: HCA FW version 5.1.000 is old (5.3.000 is
current).
Jan 19 18:48:47 zfsguru kernel: ib_mthca0: If you have problems, try updating your HCA FW.
Jan 19 18:48:47 zfsguru kernel: ib0: max_srq_sge=27
Jan 19 18:48:47 zfsguru kernel: ib0: max_cm_mtu = 0x10000, num_frags=16
Jan 19 18:48:47 zfsguru kernel: ib0: Attached to mthca0 port 1
Jan 19 18:48:47 zfsguru kernel: ib1: max_srq_sge=27
Jan 19 18:48:47 zfsguru kernel: ib1: max_cm_mtu = 0x10000, num_frags=16
Jan 19 18:48:47 zfsguru kernel: ib1: Attached to mthca0 port 2

rest van system's log: http://pastebin.com/xvgcb9Eu
Kernel log: http://pastebin.com/j8hVnheL


De SFF-8470 kabels (2m) zijn nog steeds onderweg (HongKong) dus jammer genoeg geen transfer
speeds of link setup voorlopig.

Aangezien IB pas net is toegevoegd aan ZFSguru (0.2.0-beta3) ga ik de huidige setup op basis van 0.1.9 voorlopig nog even niet upgraden. Neemt niet weg dat er volop gepield gaat worden met de test plank, arrgghh ongeduldig wachten op die kabels, niet altijd mijn beste eigenschap.

Pic's or it didn't happen:

[Pantagruel]

Een update mbt Infiniband:

De kabels zijn gisteren aan gekomen, kwam er alleen achter dat de connector toch schroef bevestiging was en niet klem (wat ik nodig heb). Heb de connector los moeten schroeven om de boel aan te kunnen sluiten.
aan de Mellanox HCA's.

Een quickie Iperf test IPoIB.

Iperf server: GA-X38-DQ6, 8 Gib RAM, E7400, GTS8800,on-board RTL nic, HCA at PCIe x16 #2
Iperf client: Asus P5N7A-VM, 4 Gib RAM, E6600, on-board video, on-board Nvidia nic, HCA at PCIe x16

1e test: Win7 x64 -> Win7 x64 OFED drivers.



192.168.1.x zijn de on-board Gbit nic's en 10.10.4.x de 10Gbit HCA's.
Jammer genoeg doet de Realtek slechts ca. 50% van de 'advertised' speed als het om single thread throughput gaat, geklokt: 437 Mbit/sec.
De Mellanox HCA's doen het beter maar de 1 Gbit/sec is voorlopig nog geen 10 Gbit.

2e test: Win 7 x64 -> ZFSguru 0.2.0-beta3 liveCD.



192.168.1.x zijn de on-board Gbit nic's en 10.10.4.x de 10Gbit HCA's.
De onboard NIC's halen bij een hogere TCP windows size wel hun 'advertised' , geklokt: 939 Mbit/sec.
De Mellanox HCA's doen het beter, 3.13 Gbit/sec in single thread 64 K TCP windows size is niet slcht, maar het zou nog beter moeten kunnen.

Na een de man pages van iperf es doorgenomen te hebben en een hint van CiPHER de que depth verhoogt

3e test: Win 7 x64 -> FreeBSD 9 custom OFED kernel



De Mellanox HCA's doen het beter, 6.34 Gbit/sec bij 8 threads en een TCP windows size van 64 K is het betere werk.


Conclusie tot nu toe:
De Windows 7 default TCP window size van 8 Kb remt waarschijnlijk de on-board nic's, de 10Gbit HCA's leiden er definitief onder (single threaded transfer). FreeBSD's default TCP window size van 64 Kb doet het behoorlijk veel beter. Infiniband topt pas bij een que width van 8 en dan kom je redelijk in de buurt van de maximale doorvoersnelheid die je "in 't wild" zou verwachten (max. is ca. 80% van theoretische snelheid ivm overhead)

[Pantagruel]

FireDrunk schreef op zaterdag 21 januari 2012 @ 11:47:
20% overhead op TCP? Valt wel mee hoor, al helemaal als je 64k transfer sizes hebt, dan is het eerder 2-5%.
Je kan dus nog iets sneller

Heb je CPU belasting bekeken? Misschien is je PCIe chipset gewoon niet sneller.

Ik vrees dat je gelijk hebt, de E6000 is 100% belast tijdens de test, de E7400 in de FreeBSD bak heeft nog 20% over.

Spelen met de TCP windows size geeft nog net even dat beetje meer, maar de rek is niet groot. >= 256K geeft geen verbetering t.o.v 128K.

[FDMK]

Verwijderd schreef op maandag 23 januari 2012 @ 21:34:
Kun je wat screenshots geven ofzo? Draait het wel zonder ESXi dus direct op de host?

Dat is nooit geen optie dus dat ga ik niet proberen . Wat ik tot nu al geprobeerd heb is:

Clean install 0.1.8, werkt
Clean install 0.1.8 > 0.1.9, werkt
Clean install 0.1.8 > 0.1.9 > 0.2 beta 3, boot niet verder vanwege screen
Clean install 0.2. beta3, boot niet verder vanwege screen



Dit dan tot oneindig.

Ik ga dit ook nog proberen op een fysieke bak die ik op het werk heb staan met een Perc6i/1068E maar aangezien ik de controller via VT-D passthrough naar mn VM zal het niet veel verschil maken.

[ Voor 17% gewijzigd door FDMK op 23-01-2012 21:46 ]

[iRReeL]

Ik dacht al dat het iets met de labels te maken zou kunnen hebben omdat ik dit niet op orde heb. Disk benchmark pakt ook maar 1 disk terwijl ik 10 disks aanvink (aan de andere kant hebben alle disks nu een 4 KiB sector (wat eerst nog op default 512 stond) dus de benchmark heeft blijkbaar wel alle 10 disks geformatteerd, allemaal label ZFS).

- Ik had eerder een zpool aangemaakt met napp-it, die had ik een tijdje in gebruik, toen verwijderd.
- Toen wilde ik met 4K override testen dus via ZFSguru alle disks een voor een GEOM format (wilde graag compatibility met openindiana) gedaan en label gegeven zoals de disk naam al was (DISKS - PHYSICAL DISKS- Quickformat)( da0, ada1 etc). Zpool 4K aangemaakt



- Terug naar opensolaris maar dit gaf problemen (veel H: errors), met Napp-it pool weer verwijderd en een nieuwe pool aangemaakt (voor de rest niets format of label).

Voor de andere zpool geldt hetzelfde, nooit naar label gekeken of zelfs format gedaan. Met napp-it kom je dat eigenlijk niet echt tegen (ik iig niet). Met die F2 pool lukte het dus ook niet om die in ZFSguru aan te maken dus had ik zelf zpool create gedaan.

Ik heb nooit een disk gekopieerd, als ik een zpool aanmaak verschijnen de labels zoals ze zijn 'vanzelf'. Ik heb gister wel kunnen opgraden naar 9.04 maar weet niets van die partitie manager met kleurtjes.


Omdat ik toch veel problemen had met openindiana blijf ik nu toch bij feebsd dus kan ik wel GPT format doen, dat zal ik vanmiddag proberen en dan nog 's testen.

EDIT: alle disks een aparte label gegeven en nu draait de benchmark idd op 10 disks. Oef hij gaat me nogal wat testjes draaien.. Was misschien handig om erbij te vermelden wat ie allemaal gaat doen zodat de gebruiker een beetje idee heeft hoelang het gaat duren. Ik heb nu trouwens ook 10 disks aangevinkt maar toch doet ie ook met 5,7,8,9 disks testen, ik zou eigenlijk denken dat de test zich beperkt tot het aantal disks dat ik geselecteerd had. Hierna nog 's de test met de 4K override (want die was ik vergeten te selecteren lol). 512b benchmark onderbroken en met 4K override benchmark gestart.

Meest belangrijk is 10 disks Raidz2 (no 4K override)
Now testing RAIDZ2 configuration with 10 disks: cWmRd@cWmRd@cWmRd@
READ: 489 MiB/sec 447 MiB/sec 489 MiB/sec = 475 MiB/sec avg
WRITE: 444 MiB/sec 477 MiB/sec 471 MiB/sec = 464 MiB/sec avg

10 disks raidz2 (4K override)
Now testing RAIDZ2 configuration with 10 disks: cWmRd@cWmRd@cWmRd@
READ: 602 MiB/sec 624 MiB/sec 651 MiB/sec = 626 MiB/sec avg
WRITE: 536 MiB/sec 509 MiB/sec 510 MiB/sec = 518 MiB/sec avg

Kun je ook labels aanpassen op een bestaande zpool (zonder dataverlies)? Misschien wel beter om problemen te voorkomen.

[ Voor 26% gewijzigd door iRReeL op 27-01-2012 09:49 . Reden: update ]

[Pantagruel]

Na een periode van vruchteloos testen in een poging om iSCSI over IPoIB aan de gang te krijgen begon de twijfel over het correct functioneren van de Infiniband HCA's en de el-cheapo kabel toe te nemen.

Om eventuele twijfel rondom de spullen uit de wereld te krijgen heb ik met het blog van David Hunt op de verwerkingsbak op de test opstelling Ubuntu 11.10 gezet. Na een uurtje prutsen en wat kleine soms voor de hand liggende veranderingen was Infiniband & SRP up and running.
Om maximale bandbreedte te garanderen heb ik een 2GB RAMDISK aangemaakt met daarin een 2 GB zero filled bestand dat als SRP target zou gaan dienen.

Na toevoeging van de OFED SRP software en de installatie van de SRP miniport driver (extra storage device wordt toegevoegd aan je windows 7 bak) was Windows disk management bereidt om een nieuw 'apparaat' toe te voegen en te formatteren voor gebruik. Wat klikjes verder werd 't vers geformatteerde schijfstation geopend voor gebruik, mm dat voelde als snel aan dat openen.

Het kopieren van wat data van af de 128GB M4 SSD kwam maximaal op 260 MB/sec write speed, mm niet helemaal wat de spec's beloven (500 MB/sec), wellicht tijd voor een scrubje.

Crystal Disk Mark dan maar:


Mmm, beter, maar 4k Q32 misschien wat teleurstellend.

Atto DiskBench downloaden en een test met Queue depth op 8 (meer in lijn met de iperf test):


Ja, dat lijkt er definitief meer op.

Conclusies:

IB,IPoIB en SRP initiator/target op Ubuntu linux voor elkaar krijgen is een eitje, maar vooral te danken aan het werk van David Hunt . Het handje vol kleine dingetjes is niet noemens waardig.

De Infiniband spullen (HCA's en kabels) doen wat ze beloven. Bij een transfer size van 64K en groter bij een Queue depth van 8 leveren de beloofde read/write speeds van 900MB/sec en beter.

De belangrijkste waarneming is echter dat de hardware gewoon goed werkt en er geen reden is om hier verder nog aan te twijfelen.
Eventuele afwijkingen t.o.v de hier behaalde snelheden zullen dus eerder te maken hebben met de kinderschoenen status van de drivers,software of een configuratie blunder van de gebruiker .

Wat nu te doen?, verder prutsen met FreeBSD/ZFSGuru 0.2.0-b4 in de weet dat de info rondom SRP en FreeBSD zeer beperkt is, of overschakelen op ZFS on linux in de wetenschap dat het alles behalve droog is achter de oren.

[Bolk]

Nee, wat ik wil bereiken is dat de storage van m'n VM's gecentraliseerd staan op de storage server (dan kan ik ook met High Availability aan de gang). Alleen de frontend servers virtualizeren het o/s, terwijl zij via een NFS (of iSCSI) mount hun data halen van de storage server. De storage server wordt RAIDZ2 met 6 2TB disks. Om het kort te zeggen: de virtuele harddrives van de VM's staan op de storage server.



Alleen schijnbaar door de sync writes van NFS-clients van de frontend ESXi servers, is dat nogal een aanslag op de performance. iSCSI heeft dit probleem schijnbaar niet. Reden om NFS te gaan gebruiken is de schaalbaarheid.

Ik zal het moeten gaan testen (met/zonder SSD als SLOG), maar vroeg me af of iemand ervaring heeft met een ZFS storage solution voor ESXi.

[FireDrunk]

Zoveel dus, vreemd dat jij er toch problemen mee hebt.

[ItsValium]

Ik kan de ervaring van syl765 met de sync optie van ZFS op een NFS-share voor ESXi alleen maar bevestigen.

Opzet hier is : ESXi5 nodes met NFS shares op een Nexenta ZFS HA omgeving.

Screenshot hieronder:
Links Sync Enabled Rechts Sync Disabled op dezelfde VM net na elkaar gedraaid. De Writes hebben grote verschillen tussen beide.

[fluppie007]

Iemand een idee wat deze "medium error" wilt zeggen ?
Kan het gerelateerd zijn aan mijn performance problemen ?

edit:

Volgens mij komt dit van mijn DVD-rom drive...
Ik las in het ZFS forum dat je moet installeren voor benchmark tests te doen...
Even gedaan en ik krijg het volgende:

Niet-optimale pool van 4 disks ( Samsung F4EG HD204UI 2TB ) op de LSI 9220-8i met 4K sector override

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 16 GiB
Data source : /dev/zero
Read throughput : 184.6 MB/s = 176.1 MiB/s
Write throughput: 182.5 MB/s = 174.1 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 32 GiB
Data source : /dev/zero
Read throughput : 328.3 MB/s = 313.1 MiB/s
Write throughput: 146.7 MB/s = 139.9 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 320 MB/s = 305.2 MiB/s
Write throughput: 297.3 MB/s = 283.5 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 128 GiB
Data source : /dev/zero
Read throughput : 307 MB/s = 292.8 MiB/s
Write throughput: 281.3 MB/s = 268.3 MiB/s

[ Voor 78% gewijzigd door fluppie007 op 12-02-2012 16:22 ]

[fluppie007]

Na de advanced benchmark onder ZFS guru 0.2 beta5

Ik zal vermoedelijk voor 9 disks in RAID-Z gaan. 5 disks zijn nieuw en kan ik gelijk mee starten. De andere 4 kan ik pas gebruiken na het overpompen van de data. Dat is dan een pool met 5 echte en 4 memory disks ?

Vb. van een echte disk: da0 GPT: StorageDisk1 2 TB 1.8 TiB 4 KiB <ATA SAMSUNG HD204UI 0001>

Memory disks, 4K Sector en 1.8 TiB groot ? Welke memory backing ?
Dan data overpompen, memory disks deleten en de 4 nieuwe toevoegen ?

[ Voor 59% gewijzigd door fluppie007 op 14-02-2012 09:38 ]

[FireDrunk]

Ter verduidelijking van Ultraman:

nForce design tussen 4 en 750 verschilt niet zoveel.

[ Voor 6% gewijzigd door FireDrunk op 21-02-2012 09:29 ]

[Megalith]

Na een aantal dingen uitgeprobeerd te hebben op verschillende platforms (FreeNas, ZFSGuru en OpenIndiana) heb ik mijn ZFS testserver icm OpenIndiana +Nappit en fibrechannel ook aan de gang. Testsysteempje bestaat uit een Core i3 2100, 16GB RAM, Intel 320 120GB SSD en vier WD20EARS (2TB) in een RAIDZ2 opstelling met de SSD als read-cache device.
FreeBSD was eerder eigenlijk al afgevallen omdat er geen LDAP ondersteuning in de kernel ingebouwd zat en mijn fibrechannel hba niet native ondersteund werd (HP FC2242, rebranded Emulex LPe11002 DP). Initiator is een Server 2008 bak die deze target in eerste instantie alleen zal gebruiken om Hyper-V machines op op te slaan. Als de opstelling me na een aantal maanden testen goed bevalt zal ik ook de raid6 set van mijn areca naar zfs migreren. Maar daar ben ik nog een beetje voorzichtig mee omdat ik het OS niet zo goed ken dat ik alle familiefoto's ed. er zomaar aan over wil laten.

Ik moet zeggen dat ik ontzettend blij ben geworden van de presaties van ZFS! Het is alleen erg jammer dat Solaris (voor zover ik weet) geen ondersteuning biedt om je SSD zowel als read als write cache te gebruiken. Het gebruik van read cache is erg goed te zien in de CrystalDisk benchmark, uitgevoerd op de Windows server, dus over FibreChannel. Al helemaal omdat er slechts twee disks gebruikt worden. Bij quedepth 32 bijna 56k IOPS bij read actions en maar 1600 write IOPS.


VS CrystalDisk benchmark op de Areca


ZFS version is nu nog 15, maar wellicht dat ik hem wil upgraden naar 28 zodat ik hem bij hoge nood ook nog kan importen onder FreeBSD. Verder heb ik ook nog geen tuning o.i.d gedaan. Iemand tips voor tuningoptions die de (write) performance positief beïnvloeden?

[Verwijderd]

Het zijn Mini-SAS aansluitingen. Zo heb je maar twee kabels die elk in 4 SATA kabels veranderen, afhankelijk van welke kabels je neemt. Norco behuizingen met ruimte voor veel schijven hebben een model waarbij je gewoon meerdere Mini-SAS kakbels kunt inpluggen, dus elke kabel 4 disks zonder op te splitsen. Maargoed normaal werk je dus met deze kabels:

SFF-8087 (niet Reverse!)



De kabels moet je meestal apart kopen. En ja je kunt 3TB+ disks op deze controller aansluiten dacht ik, check dat nog even voor de zekerheid via google.

[Dinh]

Screens:
in Dos:


in EFI Shell:

[Erik1]

De HBA is via passthrough aan de VM gegeven, waardoor er volledige controle over de hardware is. Wat helaas niet kan is direct booten vanaf een disk die aan de HBA hangt, is denk ik een beperking van de VMware bios. Ik heb dus een virtuele schijf gemaakt om vanaf te booten. Die staat op de VMware datastore op een 2,5" 160GB schijfje aan de onboard sata.

De disks hebben wel een "da" naam ipv "ada". Misschien omdat het een SAS adapter is waar SATA schijven aan hangen? TRIM zal dus helaas niet gebruikt kunnen worden, onderpartitioneren moet dat nadeel opvangen.


Wat ik er verder nog naast ga draaien in ESXi:
- pfSense: Komt in alle vlans te hangen als router/firewall en VPN toegang vanaf internet
- Windows XP of 7: Remote desktop / downloads als mijn desktop PC uit staat.
- Debian: TV server / recorder (er zit een DVB-C kaart in de server)

Verder een testomgeving waar ik snel een paar machientjes kan optuigen zonder met fysieke hardware te hoeven slepen

Zou natuurlijk ook prima met bijv. virtualbox op FreeBSD als host kunnen, maar met vmware heb ik het meeste ervaring.

Verwijderd schreef op zaterdag 17 maart 2012 @ 16:41:
Je benchmark is slechts 8GB groot; je moet met 8 keer je RAM testen voor nauwkeurige resultaten; dus je zult net iets lagere maar realistische scores krijgen met 64GB testfile, wat geloof ik ook de default is als je test via de Web-interface (Pools->Benchmark).

Inderdaad een stuk lager!

code:

ZFSguru 0.2.0-beta5 pool benchmark
Pool            : bigpool (4.53T, 0% full)
Test size       : 64 GiB
Data source     : /dev/zero
Read throughput : 311.1 MB/s = 296.6 MiB/s
Write throughput: 228.4 MB/s = 217.8 MiB/s

Wil je een pool met meerdere vdevs, dan maak je eerst de pool aan met de eerste vdev op de Pools->Create pagina. Daarna voeg je telkens een vdev toe op de Pools->Expand pagina. Dus je begint met een mirror van 2 disks, je expand met een mirror van 2 disks, nog een keer expanden met een mirror van 2 disks, en je hebt een pool met 3 vdevs en 6 disks in totaal (RAID1+0).

Ah, de expansion tab had ik even gemist

[Pixeltje]

Spullen zijn binnen en ik heb mijn NAS inmiddels draaien. Na alle ellende met de webshop nu ook ellende met m'n mooie nieuwe spulletjes (of eigenlijk, vooral met de spullen die ik nog had).



Is dit einde disk, of valt er nog iets te redden?

Zou goed klote zijn, want van deze vier schijven kwam er één aan als DOA, één is twee maanden terug RMA gegaan wegens reallocated sector count die als een idioot bleef stijgen, en nu zou er dus weer een terug moeten. Het gaat om Seagate Baaracuda 5900 rpm schijven, 2TB/stuk. ST32000542AS .

Heb geen geld om 4 nieuwe schijven te kopen, dus deze seagate's moeten het nog even uithouden..

[ Voor 37% gewijzigd door Pixeltje op 18-03-2012 22:20 ]

[Pixeltje]

Ik ben toch bang dat er meer aan de hand is..

Bij het opstarten komt dit in beeld;


(klikbaar voor groter)
Wat op zich logisch is als er een schijf stuk is, ad1 is ook de schijf die in de webgui van FreeNAS nu als 'unknown' staat.

Tijdens het afsluiten..

(klikbaar voor groter)

Dat lijkt te duiden op een geheugenprobleem? De NAS blijft overigens hangen op deze melding en sluit niet verder af. Ben nu bezig de kabels van alle schijven te vervangen. /dev/ad0 (de problematische schijf) zat zo te zien goed aangesloten op poort 0 van het moederbord, dus nu met andere kabels weer op die poort aangesloten.

--

Edit:
Nog steeds errors op die schijf. Als ik de schijf loskoppel geen errors, als ik een andere schijf aan AHCI0 hang, ook geen problemen. Kan ik hieruit concluderen dat ik inderdaad een dode schijf heb?

Overigens is met het verwijderen van de kapotte schijf ook de page error bij het afsluiten weg.

[ Voor 31% gewijzigd door Pixeltje op 19-03-2012 18:49 ]

[HyperBart]

OK, het wordt weer allemaal wat onduidelijker en ik snap enkele dingen niet...

Tweakertjes to the rescue

Ik heb in de voormiddag OpenIndiana geïnstalleerd in VMware Workstation met een 10GB bootdiskje op mijn SSD in mijn workstation, napp-it er over gegooid, 4x 100GB thin provisioned VMDK's er aan gehangen, en beginnen experimenteren...

Hot add van die disks werkte, leuk, na een rescan vond ie ze allemaal netjes, proper!

Dan maar een pool aangemaakt:



Joepie! Pool is aangemaakt:



Maar nu heb ik geen volume, klopt dit?



Ik dacht dat het enige wat je moest doen voor data op je storage machine op te kunnen opslaan het aanmaken van een vdev met daarbovenop een pool was... Blijkbaar niet?

Kan iemand hier wat meer uitleg over geven? Wat doe ik hierna? een ZFS Folder aanmaken of een volume aanmaken, nu wordt het redelijk technisch en op een dieper niveau met mountpoints en shares enz... veronderstel ik (?)

[HyperBart]

Ik heb 'm terug geimporteerd en alles was terug...

Had wel de VM afgesloten via de shell, su shutdown now, maar dan gaf ie heel de tijd van die vragen waar ik op dat moment niet aan uit kon:



En sinds de install van Napp-it heeft hij ook de naam van mijn host verandert naar die aaaaaa en die tekentjes er tussen met dan mijn hostname die ik hem had gegeven erachter...

Waar kan je nu ergens die UNIX permissies instellen?

bart@²²²ééOpenIndianaVM:/pooltje$ ls -la
total 10
drwxr-xr-x+  5 root root  6 2012-03-24 14:14 .
drwxr-xr-x  25 root root 26 2012-03-24 17:30 ..
-rw-r--r--+  1 root root  0 2012-03-24 14:14 Bonnie.log
drwxrwxrwx+  3 root root  3 2012-03-24 17:43 test1
drwxrwxrwx+  3 root root  3 2012-03-24 17:43 test2
drwxrwxrwx+  4 root root  7 2012-03-24 17:43 test3
bart@²²²ééOpenIndianaVM:/pooltje$

En toch geraak ik niet binnen in die shares met root...

En what the al mijn users zijn ook weg, mijn mail instellingen voor notifications zijn, what the hell is er met die VM gebeurd

[ Voor 64% gewijzigd door HyperBart op 24-03-2012 17:56 ]

[Dinh]

Eindelijk heb ik alle spullen binnen

Drie van deze in een Lian Li PC-50



Helaas nog niet alles gevuld. Heb momenteel 6x Seagate 3TB in een RaidZ2 als main storage en 3x oude harddisk als scratch. Verder nog een Crucial M4 64GB als OS en een Intel X25-E 32GB als ZIL.

En zo ziet het dan eruit:



Planning is dat er binnenkort nog een Crucial M4 64GB erbij komt als cache. En later uitbreiden met nog eens 6x Seagate 3TB.

Bench zonder enige tweaks:

qdtc [ ~ ]$ zpool status
  pool: qdtc
 state: ONLINE
 scan: none requested
config:

	NAME            STATE     READ WRITE CKSUM
	qdtc            ONLINE       0     0     0
	  raidz2-0      ONLINE       0     0     0
	    gpt/qdtc0   ONLINE       0     0     0
	    gpt/qdtc1   ONLINE       0     0     0
	    gpt/qdtc2   ONLINE       0     0     0
	    gpt/qdtc3   ONLINE       0     0     0
	    gpt/qdtc4   ONLINE       0     0     0
	    gpt/qdtc5   ONLINE       0     0     0
	logs
	  gpt/zfsslog0  ONLINE       0     0     0

errors: No known data errors

qdtc [ ~ ]$ dd if=/dev/zero of=/zfs/qdtc/movies/downloads/zero.file bs=1m count=40000
40000+0 records in
40000+0 records out
41943040000 bytes transferred in 99.217154 secs (422739802 bytes/sec)

qdtc [ ~ ]$ dd of=/dev/zero if=/zfs/qdtc/movies/downloads/zero.file bs=1m            
40000+0 records in
40000+0 records out
41943040000 bytes transferred in 114.176136 secs (367353822 bytes/sec)

Met deze resultaten trek ik de 1GB Lan met gemak dicht lijkt mij.

[FireDrunk]

Speelgoed!

[Pantagruel]

FireDrunk schreef op zondag 15 april 2012 @ 15:41:
Onder Ubuntu had ik ook problemen, maar ik kan me even meer herinneren wat, maar onder CentOS:
Infiniband werkte niet out of the box, ik had nog een aantal packages nodig om OpenSM aan de praat te krijgen.
Toen ik dat eenmaal had, wilde de IB versie in de Yum repository niet samenwerken met OpenSM, en heb ik dus het complete IFEB package geinstalleerd (en dus gerecompiled) en toen werkte er wel een aantal dingen (OpenSM). Maar om daarna IP-over-IB aan de praat te krijgen, moest ik toch wel wat dingen handmatig instellen.

Intussen yum remove libib* gedaan, dus kan niet echt meer verder
Op een regenachtige zaterdag kijk ik er nog wel een keer naar.

Op zich was het geen raket wetenschap.
Voor een root shell, zodat je niet iedere keer 'sudo' hoeft te tikken

Bash:

sudo bash 
apt-get update
apt-get upgrade

/etc/modules onder handen nemen en de volgende modules toevoegen:

ib_sa
ib_cm
ib_umad
ib_addr
ib_uverbs
ib_ipoib
ib_ipath
ib_qib
ib_srpt

Om de subnetmanager te installeren:

Bash:

apt-get install opensm 

Vervolgens /etc/network/interfaces aanpassen:

auto ib0
iface ib0 inet static
address 10.10.0.40
netmask 255.255.255.0

Na een reboot worden alle relevante infiniband toevoegingen in /sys gemaakt, de ipoib modules geladen, en de infiniband poort met een ip adres in de lucht gebracht.

Vlgs t blog van David Hunt geeft connected mode een betere doorvoersnelheid dan IpoIB sec.
Om connected mode te krijgen run je als root vanuit de shell:

Bash:

echo connected >`find /sys -name mode | grep ib0`
echo 65520 >`find /sys -name mtu | grep ib0`

Makkelijker is het om het meteen bij t opstarten van ib interface te laten doen, daarvoor voeg je het geheel op de volgende manier toe aan /etc/network/interfaces:

auto ib0
iface ib0 inet static
address 10.10.0.40
netmask 255.255.255.0
up echo connected >`find /sys -name mode | grep ib0`
up echo 65520 >`find /sys -name mtu | grep ib0`

Voor het opzetten van een SRP target verwijs ik naar David Hunt's blog .

Het heeft mij meer tijd en moeite gekost om een grotere RAMdisk onder OpenIndiana voor elkaar te krijgen en deze op de juiste manier aanbieden. Van de ramdisk sec kun je een SRP-lun maken maar dat liep stuk op toegangsrechten. Uiteindelijk van de ramdisk een zfs pool gemaakt en dan een zero file in deze pool als SRP-lun presenteren (geen idee of een vdev of een zfs folder ook werkt).

(Ik zal later controleren of ik t bij t juiste eind heb, de tekst is uit t blote hoofd, kan zijn dat ik iets vergeten ben)

En ja, de snelheden van en naar het RAMdisk SRP-target op de OpenIndiana test bak is niet kinderachtig. Maar mocht OI toch een write plafond hebben dan blijft t jammer, om Jim Carrey te quoten "So much horse power,.. and nowhere to gallop'.

Om uit te sluiten of de MHEA28-2TC IB HCA ( degene met geheugen) stiekem toch niet beperkend is (zou me verbazen) zou ik deze ook in een linux bak moeten testen. In de eerdere tests met een MHEA28-XTC HCA in een linux bak was deze in ieder geval niet beperkend en waren lees- en schrijfsnelheid gelijkwaardig.

Een andere factor zou de IB driver van OpenIndiana kunnen zijn. Ik heb eerlijk gezegd geen idee of die driver ontwikkeling nog plaatsvindt sinds het ter ziele gaan van OpenSolaris.

Update:
Een verse Ubuntu 11.10 installatie en wat infiniband gefrunnik verder is er uitsluitsel over eventuele beperkingen die de MHEA28-2TC zou kunnen geven tov de eerder gebruikte MHEA28-XTC uit de wereld geholpen.

Een atto bench van een 4 Gig RAMdisk als SRP target gepresenteerd:



Conlusie:
De MHEA28-2TC doet niets onder voor de eerder gebruikte MHEA28-XTC (zoals ik al verwachte) en zet dezelfde +900 MB/sec neer. Het lijkt er dus op dat OpenIndiana inderdaad de schrijfsnelheid beperkt tot zo'n ca. 550MB/sec.

[ Voor 7% gewijzigd door Pantagruel op 15-04-2012 23:22 . Reden: Update ]

[Wouter.S]

Vandaag merkte ik dat mijn pool op mijn ZFSguru Nas niet meer bereikbaar was. Even checken leverde dit op


Het betreft een raidz pool met 6*1.5TB Samsung schijven. Volgens de Smart data zijn alle schijven gewoon bereikbaar...Van het grootste gedeelte heb ik wel een backup maar het zou tof zijn als ongeveer alles te herstellen is...Als ik de discription lees maak ik hieruit op dat het mogelijk is om de pool terug te brengen naar een vorige toestand en dat alle wijzigingen in de laatste 908 minuten verdwenen zullen zijn.

Is het zo eenvoudig als gewoon even via SSH 'zpool clear -F bigtank' uitvoeren ? Of zijn er andere opties ? Kortom wat is nu het beste plan van actie ?

[NIK0]

Ik heb een soortgelijke vraag, heb me de afgelopen weken behoorlijk ingelezen in diverse zaken (storage virtualisatie etc).
Ben met name gecharmeerd hoe deze meneer het gedaan heeft:

http://www.livingontheclo...-building-san-in-box.html



Ik wil graag een soortgelijk iets maken alleen zou ik dan werken met 4 x 1 TB (reeds al wat jaartjes in bezit en nu nog verdeeld over 2 verschillende machines) + dan nog 1 aan te schaffen 2 TB Seagate 7200 RPM schijf. (prijsverschil tussen 1 en 2 TB is te klein om nog een 1 TB disk erbij te halen)
De CPU zou dan een Core i3 2100 worden.

Bedoeling is om via Nexenta 2x 900 GB VMDK toe te wijzen en daar een mirror te maken en die vervolgens te geven aan een NAS VM (Windows 2008r2, foto's, tv series) waar brok 1 van disk 1 (1TB) en de andere 900 GB brok van disk 5 (2 TB) afkomstig is.
Daarnaast wil ik dan van disk 2,3,4 en 5 de 900 GB VMDK's ook aan Nexenta geven om als VM datastore voor ESXI te gaan fungeren.

Vragen die opborrelen:
1) Nog op- en of aanmerkingen op de setup zoals in het blogstuk is beschreven..?

2) Die VMDatastore zal wel een beetje moeten performen, kan ik het beste 2x een mirror aanmaken of een RAIDZ, of RAIDZ2 volume..? (geen idee hoeveel % verschil er tussen mirror, RAIDZ of RAIDZ2 volume zit, meningen lijken nogal uiteen te lopen: http://nexentastor.org/boards/5/topics/5822)

3) Hoe bepaal je hoe groot je een cache maakt voor een data volume? (waar je dan evt een SSD stukje voor kunt gebruiken)

Sorry voor evt. n00b vragen, ben het ZFS topic aan het doorworstelen maar het is veeeel info over 120 pagina's ..

[ Voor 4% gewijzigd door NIK0 op 01-06-2012 22:14 ]

[libero]

Ik heb een zfs server in de test hangen, echter twijfel ik nogal aan de prestaties.
De specs zijn als volgt:

Iluminos/Open indiana
2x xeon 5620
96GB RAM
12x 2TB seagate tank (1 tank van ca. 10TB) (daarna 1 iscsi target naar 1 lun/volume van 10TB)
2x 250GB SSD rpool
1x 240GB SSD cache

Dit is gekoppeld via comstar iscsi met 10GB aan een ESX machine.
De test voer ik vanaf een windows 7 vm uit. MTU=1500
Zijn onderstaande scores normaal voor een systeem van deze specs?
De sequential writes lijken me nogal laag?

[ Voor 3% gewijzigd door libero op 07-06-2012 21:50 ]

[libero]

HyperBart schreef op donderdag 07 juni 2012 @ 23:05:
Doe al eens een keertje een dd met if=/dev/zero...

Kijk eens wat daar je seq writes zijn... Stap voor stap de lagen gaan troubleshooten...

Als dat wel een ander resultaat geeft zou je eens kunnen proberen een LUN als RDM aan een VM te geven ipv als datastore te gebruiken voor het hosten van een VMDK die je aan een VM geeft...

Dan krijg ik dit:


deze resultaten zijn dus niet goed? wat zou ongeveer normaal moeten zijn?

[FireDrunk]

344MB/s write vind ik niet belabberd... Het kan misschien beter, maar echt slecht is het niet...
Kan je eens met iostat -x (ik geloof dat dat wel op Solaris te runnen is) kijken of je veel IOWAIT hebt?

iostat -x 1

Deze dus:


En belast:

[ Voor 28% gewijzigd door FireDrunk op 08-06-2012 09:08 ]

[HyperBart]

HyperBart schreef op vrijdag 08 juni 2012 @ 14:12:
Ik heb ondertussen eens wat benches getrokken met IOmeter:


Test name Latency Avg iops Avg MBps cpu load
4K; 100% Read; 0% random 0.11 9104 35 48%
4K; 75% Read; 0% random 0.17 5815 22 34%
4K; 50% Read; 0% random 0.25 3932 15 27%
4K; 25% Read; 0% random 0.34 2938 11 22%
4K; 0% Read; 0% random 0.44 2251 8 20%
4K; 100% Read; 100% random 0.11 9063 35 51%
4K; 75% Read; 100% random 0.17 5789 22 33%
4K; 50% Read; 100% random 0.25 3984 15 27%
4K; 25% Read; 100% random 0.34 2906 11 21%
4K; 0% Read; 100% random 0.45 2235 8 18%

Test name
Latency
Avg iops
Avg MBps
cpu load

4K; 100% Read; 100% random
0.11
9063
35
51%

[ Voor 8% gewijzigd door HyperBart op 08-06-2012 14:41 ]

[iRReeL]

Helaas gaat het niet helemaal goed met mijn servertje, vorige week een probleem dat 1 client wel nog toegang had tot de shares maar de andere machines niet. Gisteren weer geen shares, geen ZFSguru en krijg dit te zien:


Een reboot werkt dan ook niet, niet alle disks waren beschikbaar en begrijp ik het correct dat 1 van de 2 M1015 kaarten niet goed werkt en uitvalt? Na een power off/on werkt dan alles weer voor 'n paar dagen..

In ZFSguru system / kernel log kon ik verder geen foutmeldingen vinden.

[iRReeL]

iRReeL schreef op donderdag 24 mei 2012 @ 12:24:
Ik zou graag een upgrade uitvoeren van 9.0-004 naar 9.1-001. Ik kan op de "ZFSguru Installation" wel op "download 9.1-001" klikken en hij geeft dan ook dat de image download maar daarna kan ik deze nogaltijd niet selecteren.
...
You will need a ZFSguru LiveCD mounted in your CD/DVD drive, or download a system version in order to continue.

Dadona gaf aan dat het bij hem ook niet werkte. Omdat ik nu een intel 320 heb geplaatst was ik alles opnieuw aan het installeren en nu dat ik bijna klaar ben zie ik dat de upgrade naar 9.1-001 nu wel werkt. De download is gelukt en de installatie ook.

Nu kan ik dus weer beginnen met het configureren Ik ben weer slim bezig
edit: virtio drivers voor virtual box en SABnzb zijn 'not available' voor 9.1-001
Ik ben nu bezig met deze guide om SABnzb handmatig te installeren..

Server was vanmorgen weer gecrashed dus ik zal de kabels eens omwisselen.

[ Voor 11% gewijzigd door iRReeL op 20-06-2012 16:56 ]

[iRReeL]

Sja het probleem onstond omdat bij 9.1 Sabnzbd niet meer gesupport is en toen ben ik dus de guide gaan volgen (terwijl ik Virtual Box al geinstalleerd had).

Dus ik kan ff opnieuw beginnen, Sabnzbd installeren volgens Kriss' z'n guide (incl port updates) en als ik daarmee klaar ben dan VirtualBox in ZFSguru installeren? Daarna mag ik geen port updates meer draaien, iig niet meer voor virtual box.

Of anders misschien ff wachten tot die nieuwste versie beschikbaar is met de laatste 9-STABLE of kan ik die zelf installeren? Daar is nog geen ZFSguru versie van toch.

[iRReeL]

NIK0 schreef op dinsdag 26 juni 2012 @ 12:00:
[...]


Mmm, welk OS gebruik je inmiddels in je setup..?

<n00bmode aan>
Welke optie is dat binnen het bios en enig idee of dat nog mogelijk is na het flashen..?
<n00bmode off>

Ik heb alleen ZFSguru gebruikt op deze setup. Welke optie? Bootvolgorde van de kaarten? Ja dat is nog aanwezig met de IT firmware.

[Verwijderd]

justice strike schreef op donderdag 28 juni 2012 @ 01:30:
[...]
ik zou als ik jouw was kijken naar een platinum rated voeding. Ik heb zelf een antec earthwatts 450. Die geeft 450watts, maar die is wel extreem efficient. Je bespaart daar tov je huidige voeding zo'n 9% aan stroom. Dat ligt op 150 watt load al op 15 watt en als je 300 watt trekt op 30 watt (grofweg).

Platinum klinkt leuk, maar dat geldt alleen maar voor de range tussen 20% en 100% max vermogen. Aangezien je vrijwel continu op 5% load zit, zal je efficiency sterk afwijken van wat de voeding opgeeft. Onder de 20% load gaat de efficiency sterk omhoog. Die voeding die ik aanraadde is één van de weinige voedingen die dan nog minimaal 80% efficient is, terwijl sommigen al onder de 55% zakken bij dergelijke loads; ook met allerlei 80-plus labels dat zegt dus helemaal niets!

dat gezegd hebbende. als je alleen een fileserver wil draaien en af ent oe nieuwsgroepen en torrents will downen... vraag ik mij af waarom je niet voor een low power fusion gaat. Mijn veronderstelling is dat je niet meer hoeft te hebben dan gigabit wat volgetrokken moet worden.

Inderdaad een overweging; maar qua stroomverbruik zal het wel meevallen versus wat hij nu heeft, en qua prijs is het ook niet veel goedkoper:

Asus C60M1-I moederbord (Mini-ITX, AMD C-60 = 2x 1.0GHz, 2 DDR3 DIMMs; kunnen waarschijnlijk 8GiB modules aan net als mijn Brazos bordje; officiëel wordt daar niets over gezegd.

Koop een intel gigabit kaart erbij, ik heb een gevoel dat de realtek implementatie die op die borden gebruikt worden niet heel erg performen. daarbij is het handig om die uitbreidmogelijkheden te hebben.

Realtek doet net net zo goed als Intel in vrijwel alle gevallen. Slechte drivers kunnen soms nog wel voor problemen zorgen, maar Intel heeft evengoed last gehad van driverproblemen met hun netwerkadapters. Koop alleen een Intel NIC als je Realtek/onboard problemen geeft. Grote kans dat je gewoon 950 megabit haalt over een goede kabel, waar Intel dan iets van 960 megabit haalt; kortom niet de moeite waard alleen als je concrete problemen hebt.

En als je wilt kunnen uitbreiden, kun je beter maar niet je enige PCIe x16 slot verspillen aan een PCIe x1 NICje. Je hebt die slot nodig voor een IBM M1015 controller bijvoorbeeld, voor 8 extra disks.

afhankelijk van je performance eisen wil je misschien ook naar green drives gaan kijken. Heeft even wel wat zorg nodig maar je kunt daar zeker met 6 schijven genoeg snelheid mee bereiken op gigabit mee vol te stouwen. scheelt weer een paar watt en dat is op jaarbasis ook weer geld

Ik lees overal verschillende verhalen daarover.... misschien moet ik gewoon voor zo'n microdrive gaan... als die nog bestaan

Nee joh, fragiele mechanische techniek. Als je USB wilt kun je een USB hardeschijf of nog beter een goede USB stick nemen. De Adata N005 non-PRO bijvoorbeeld. Info kun je bijvoorbeeld hier vinden, maar ik heb er heel erg lang naar moeten zoeken dus terugvinden wat ik met google allemaal gevonden heb, gaat niet zo snel lukken.

http://nettronic.wordpres...usb3-flash-drives-review/

[ Voor 3% gewijzigd door Verwijderd op 28-06-2012 14:01 ]

[victorb]

Ben vanavond begonnen met expirimenteren met ZFS op echte hardware. Van de week al via virtualbox openindiana gedraait. Maar dat was toch even stapje te hoog. Het ZFS deel was duidelijk en heb dingen uitgeprobeerd alleen het file sharen ging niet zoals ik wilde . Daarom nu freenas proberen en het draaien van usb stick en alle hd's voor opslag bevalt me wel.

De quad core (Q6600) heb ik teruggeclocked naar 1.6ghz en ik heb 8gb geheugen. Ik heb de areca 1220 uit het systeem gehaald en de disken gewoon op mobo in geplugt (gewoon random). cdtje met freenas erin en 2gb usb stick en geinstaleerd. Ik heb de youtube tutorials van freenas bekeken en het bevalt me tot nu toe wel. NFS filesharing gaat met 100MiB/s.

Ik ga de komende tijd er lekker mee klooien en uitproberen. Zodat ik kan kijken wat ZFS voor mij kan en wat het niet kan. En dan bepalen wat ik voor hardware ga aanschaffen als filserver. Ik zit iig te denken aan een IBM Serveraid M1015.

Wat is makkelijkste manier of de snelheid te meten van de ZFS pool?

[revox862]

Twee schijven in mijn ZFS pool laten (soms) het volgende zien:





Stuk?

IBM M1015 in IT met 10x 1.5TB WD Green RAIDZ2.
SMART klaagt over hoge load cycle ~500000.

[Verwijderd]

Als je voedingreviews moet geloven komen ze nooit onder 80% efficiency. Toch is de efficiency bij een Brazos servertje waarschijnlijk lager dan 50%; de voeding gebruikt dan meer stroom dan het computersysteem zelf.

45W is een hoog wattage wat je opgeeft. Dat komt overeen met 4 ZFS servers of 11 tot 15 hardeschijven. Als je inderdaad denkt dat je zeker 45W gaat verstoken, heeft een PicoPSU geen zin. En als je al zoveel idle verstookt; hoe ga je dan onder de 150W piekbelasting komen? Kortom, PicoPSU is leuk voor een 12W server met pieken net boven de 100W. Dat is de situatie waarin een PicoPSU het meeste verschil maakt.

Mijn stroommetingen met PicoPSU versus ATX voedingen geven aan dat nieuwe ATX voedingen flink onzuinig kunnen zijn. Een 10 jaar oude ATX voeding doet het bij mij met 10 watt idle stukken beter dan een 'moderne' Huntkey voeding. Echte kwaliteitsvoedingen heb ik niet getest, maar diverse reviews geven aan dat juist dit soort voedingen enorm inefficient kan zijn bij lage belasting.

Er is simpelweg niemand die voedingen test op 2 of 5 procent belasting. Lager dan 20 procent wordt vrijwel nooit getest. Doe je dat wel dan krijg je cijfers als:



Waar denk je dat deze lijnen gaan eindigen bij 10W belasting?

[NIK0]

Guru's

Ik heb een bonnie++ test gedaan op mijn 3x 1TB mirror zijn dit "normale" waardes..? Bedoeling is om 'm te gebruiken als VM Datastore...(geen peakperformance benodigd)

[ Voor 6% gewijzigd door NIK0 op 15-07-2012 19:37 ]

[Pantagruel]

sloth schreef op woensdag 18 juli 2012 @ 09:49:
Dat zou erg leerrijk zijn

Ik beschik namelijk op dit moment over een non-VT-D compatible ESXi setup. Hier zou ik ZFSGuru guest op willen met een enkele disk attached via RDM, net om een betere data integriteit te verkrijgen.

Ook ben ik benieuwd of SMART en spindown met deze opstelling nog zouden werken.

Zow, een beetje prutsen verder.

RDM aangemaakt richting de SATA drive (400GB WD) aanwezig op de on-board SATA controller van t X9SCM-F moederbord mbv dit blogje. De vier andere SATA disks (320GB WD) hangen dus aan een passthrough LSI SAS2008 (IT mode M1015). RDM disk aan de ZFSguru VM toegevoegd en opgestart.

Screenshot van de hdd sectie van de ZFSguru webinterface:


Van boven naar beneden: de VM disk aanwezig op de SSD, de 400 GB WD en de vier andere 320 GB WD's.

Screenshot van de SMART sectie van de ZFSguru webinterface na een klik op de 'scan all' knop:


Arghh, rot kabeltje??, nee een brakke molex splitter ( hddtje gaat uit, hddtje gaat aan, je kent t wel).

Dus ja, SMART uitlezen van een HDD werkt zowel voor een HDD aan een passthrough controller als voor een RDM drive.

[NIK0]

@CiPHER

Geprobeerd om m'n Nexenta volume naar ashift=12 om te zetten met ZFS Guru wat op zich wel gelukt is maar ik ben niet tevreden aangezien het andere zaken weer sloopt.

1) Eerst geprobeerd met ZFS guru direct een mirror aan te maken met de 2 (nexenta gpt geformatteerde disken) met 4K support. Dit gaat niet, ZFS-Guru zegt dat de namen conflicteren
EXTRA INFO:
Een Nexenta formatted disk ziet er zo uit:


2) In ZFS-Guru Disken geformatteerd met GEOM en een label aan de disken gehangen. Mirror pool aangemaakt en opzich alles prima, export pool, import pool in Nexenta en Pool wordt herkend.

NADEEL: Ik kan de disken niet meer "benaderen" voor bijv smartmon om de temps op te vragen of bijv via het tooltje blocksize kon ik niet langer de blocksize van de disken opvragen. In de GUI zag ik ook iets raars, bij het volume stonden de disken en daaronder stonden ze nogmaals gelist bij available disken als een mogelijke "Hot Spares (only in available state)" wat niet zo hoort.

3) Toen geprobeerd in ZFS-Guru beide disken te formatteren met GPT en een label gegegeven. Daarna het freebsd boot-stukje destroyed via DESTROY BOOT PARTITION
Disken vervolgens in een mirror gehangen en pool export gedaan.

Pool daarna geprobeerd in Nexenta te importeren maar dat lukt dus niet..
Cannot get exported volumes list: Assertion failed: rn->rn_nozpool == B_FALSE, file ../common/libzfs_import.c, line 1077, function zpool_open_func

Dus met GEOM wel succes alleen geen mogelijkheid meer tot smartmontools data en rare zaken in de gui. Format via ZFS-Guru met GPT geeft problemen met importeren...damned if do, damned if I don't

Is er met ZFS-Guru geen manier om via een shell met de hand de disken te formatteren met een GPT format die Nexenta wel begrijpt..?

[ Voor 8% gewijzigd door NIK0 op 19-07-2012 21:55 ]

[NIK0]

Oke quick en dirty
Ik maak een volume aan in mirror

Volume verwijder ik weer (disken zijn nog steeds formatted)

Ik boot zfs guru disken zien er zo uit

disken da3,4 en 5 zijn lid van een 3way mirror

Vervolgens pas ik het label aan vd disk en klik ik op UPDATE PARTITION


En wil ik een mirror aanmaken:
zpl versie heb ik op 4 laten staan en spa op 28 gezet maar niet zeker of dit klopt,
Wanneer ik dan klik op CREATE POOL

Geeft ZFSGuru de melding:
Warning: at least one disk selected is too small, minimum is 64 MiB

EDIT
Nog geprobeerd om "Apply Force" aan te klikken werkt ook niet

[ Voor 12% gewijzigd door NIK0 op 19-07-2012 23:21 ]

[NIK0]

Oke volume aanmaken ging nu wel !!!!

Boot terug naar nexenta, zie een volume 1 bovenaan en een "ghost" vol2 onderaan


Ik klik op import volume en dan zie ik dit:


Welke te importeren..? (de NON destroyed heeft de disken toegewezen maar wat doet dat lege mormel daaronder..? )

Zal ik anders in nexenta een temp volume aanmaken, deze weggooien en dan in zfsguru een vol3 aanmaken (die naam is nog nooit eerder gebruikt)

[ Voor 29% gewijzigd door NIK0 op 19-07-2012 23:35 ]

[Phasis]

Vreemd ik zag dat ik vergeten was me SASUC8I controller aan me VM te hangen.
Als ik dan boot zfsguru 0.2.0-beta4 krijg ik een hoop te zien maar het zfsguru venster niet.

Als ik vervolgens de 0.1.8 live cd boot werkt alles wel gewoon.

[NIK0]

@CiPHER
Inmiddels zijn we een weekje verder en is er weer het eea gebeurd.
De NFS services draaien prima als datastore voor m'n ESXi machine.
Het ISCSI verhaal is geheel anders gelopen.
De 2X2TB Seagate ST2000DM001 mirror zoals we die eerder hadden opgezet heb ik via iscsi doorgegeven aan een Windows VM.
Op zich prima totdat ik er data naartoe ging kopieren. Na 2 GB "hing" alles zo'n beetje tot op een punt dat ik de nexenta vm moest rebooten.

Zoeken op het Nexenta forum gaf als tip om in ESXi VAAI te disablen wat ik heb gedaan:
http://kb.vmware.com/kb/1033665

Daarna opnieuw de kopieeractie gestart van m'n fysieke nas naar m'n windows 2008 vm en dat ging op zich prima. 850 GB gekopieerd rond de 85/95 MB/s!

De volgende dag wilde ik vanaf mijn pc een .mkv kopieren en wederom verslikte nexenta zich. Door snel te cancellen bleef alles nu gelukkig wel op.
ESXi gaf lekkere warnings af:
2012-07-24T17:32:21.538Z cpu1:2049)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177139 microseconds to 3637169 microseconds.
2012-07-24T17:32:23.136Z cpu1:121479)ScsiDeviceIO: 1198: Device naa.600144f0c52383000000500928190001 performance has improved. I/O latency reduced from 3637169 microseconds to 722304 microseconds.
2012-07-24T17:32:26.562Z cpu0:2052)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177178 microseconds to 3881406 microseconds.
2012-07-24T17:32:43.797Z cpu2:121481)WARNING: ScsiDeviceIO: 1218: Device naa.600144f0c52383000000500928190001 performance has deteriorated. I/O latency increased from average value of 177271 microseconds to 8444857 microseconds.
2012-07-24T17:32:44.050Z cpu1:120958)ScsiDeviceIO: 1198: Device naa.600144f0c52383000000500928190001 performance has improved. I/O latency reduced from 8444857 microseconds to 1679669 microseconds.
2012-07-24T17:33:44.438Z cpu1:119821)WARNING: NMP: nmpDeviceTaskMgmt:2210:Attempt to issue lun reset on device naa.600144f0c52383000000500928190001. This will clear any SCSI-2 reservations on the device.
2012-07-24T17:33:46.930Z cpu3:2126)VSCSI: 2763: Retry 0 on handle 8209 still in progress after 2 seconds
Gehele log is hier te vinden:
http://pastebin.com/GRy9vA4n

Daarna nog de een setting speciaal voor sata disken geprobeerd in Nexenta (Syszfsvdevmaxpending = 1 default=10) kopieren ging wel maar ik ben het vertrouwen in iscsi een beetje kwijt.
Toen ben ik gaan kijken naar mogelijkheid om de CIFS server van Nexenta te gebruiken. Een beetje mee gespeeld en wat testen gedaan.

De zfsguru benchmark gaf dit:


In workgroup mode, een folder aangemaakt en daarna data gekopieerd
Vanaf mijn fysieke nas (HP ML110 G5 met OS op SSD een lokale Seagate 1TB drive)

Dus niet in de buurt van de 85-95 MB/s die ik had met iscsi

Vanaf mijn virtuele nas (welke staat op de NFS share bestaande uit een 3 way mirror kreeg ik deze resultaten


VRAGEN:
- Kloppen de writespeeds van 50 MB/s voor een 2x2 TB mirror met 7200rpm disks..?
- Is dit een limiet van nexenta, CIFS, netwerk, disken?

Ik zit er sterk over te denken om over te stappen naar een OI/Napp-IT combinatie maar ik blijf fan van de appliance mode van nexenta (ookal begint de lijst met zaken die zuigen in nexenta steeds meer te groeien )
Ben benieuwd of OI icm Napp-IT ook een redelijke appliance is of dat je elke week packages moet upgraden om de zaken aan de gang te houden. (ervaringen welkom) Ik ben puur op zoek naar een virtueel zfs san/nas

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 14:15:
[...]

Ik had ansich hetzelfde probleem. Uiteindelijk ben ik tot de conclusie gekomen dat dit een probleem is met de netwerkkaart. Deze valt iedere keer uit waardoor de max throughput wel gigabit is, maar de gemiddelden worden erg naar beneden getrokken.

Ook moet je goed kijken in de logs of de ACS mode goed ingesteld staat (writethrough dacht ik) en dat je systeem AIO ondersteund (dat doet Freebsd bijv niet standaard, en bij mij was het nog een probleem zelfs na het loaden van de kld)

VRAGEN:
- Kloppen de writespeeds van 50 MB/s voor een 2x2 TB mirror met 7200rpm disks..?
- Is dit een limiet van nexenta, CIFS, netwerk, disken?

Ik zit er sterk over te denken om over te stappen naar een OI/Napp-IT combinatie maar ik blijf fan van de appliance mode van nexenta (ookal begint de lijst met zaken die zuigen in nexenta steeds meer te groeien )
Ben benieuwd of OI icm Napp-IT ook een redelijke appliance is of dat je elke week packages moet upgraden om de zaken aan de gang te houden. (ervaringen welkom) Ik ben puur op zoek naar een virtueel zfs san/nas


Ik draai de nexenta doos op een virtuele machine dus uitvallen van nics zou gelogd moeten worden.

De properties van mijn share


Sync = ACS mode..?

Enig idee waar ik in Nexenta AIO support kan nakijken..? (geen idee waar dat voor is overigens but willing to learn)

[ Voor 26% gewijzigd door NIK0 op 26-07-2012 14:29 ]

[NIK0]

justice strike schreef op donderdag 26 juli 2012 @ 14:31:
[...]

sorry moet acl zijn niet acs. Met uitvallen van nics bedoel ik dat de driver crashed. Lijkt me niet dat je virtual machine dat merkt. Ik zie het niet eens in de freebsd logs van de machine waar dat het geval is.

(ik noem het een crash, maar het is een zichtbare dip in de throughput die herhaaldelijk voorkomt. Ik had begrepen dat freebsd in zo'n geval de driver opnieuw laad.

You might be on to something, kopieeractie gaat een tijd goed met 50MB/s en dan stort het in op het eind.


Je zei dat jij hetzelfde issue had. Heb je dat kunnen tackelen en zo ja hoe..?

[FireDrunk]

Ik vind dit toch wel een beetje zorgelijk...

CiPHER zou je toch kunnen kijken naar die CLANG kernel, want ik heb mijn VM gisteravond gesloopt.
Ik word er een beetje moedeloos van... overal staat dat je freebsd-update moet gebruiken om te updaten. Maar dat werkt niet...

Ik heb de CLANG fout kunnen omzeilen en vmxnet3.ko word netjes gecompiled nu, maar ik kan hem niet openen, dus ik gok dat deze met CLANG gecompiled is, en dat ik hem daarom niet kan laden (kldload vmxnet3.ko geeft een invalid exe format error).

Dus ik dacht, weet je wat, ik probeer open-vm-tools eens, die schijnen zelfs een PVSCSI driver te hebben.
pkg_add -r open-vm-tools-nox11.

open-vm-tools requires >glib 2.6.0

pkg_info | grep glib

glib1.2 installed....
glib2.28 installed...

[ Voor 102% gewijzigd door FireDrunk op 29-07-2012 19:01 ]

[FireDrunk]

HOPPA!!!!!!!!!!

[FireDrunk]

Je hebt nergens je specs vermeld, dus dat kunnen wij niet ruiken...
Overigens is er een knopje om je laatste post bij te werken mocht je nog iets willen zeggen.

[ Voor 59% gewijzigd door FireDrunk op 16-08-2012 23:22 ]

[0xygen]

Ik ben inmiddels weer het een en ander aan het proberen op het gebied zijn schrijfsnelheid en die hier een voor mij vreemde ontdekking:


RAIDZ2 zonder Cache:
ZFSguru 0.2.0-beta6 pool benchmark
Pool : Storage (7.06T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 263.7 MB/s = 251.5 MiB/s
Write throughput: 107.4 MB/s = 102.5 MiB/s

RAIDZ zonder Cache:
ZFSguru 0.2.0-beta6 pool benchmark
Pool : Storage (5.31T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 248.3 MB/s = 236.8 MiB/s
Write throughput: 201.2 MB/s = 191.9 MiB/s

Hoe kan RAIDZ met 3 disks sneller zijn dan RAIDZ2 met 4 disks?

En als ik ZFSguru als OS wil installeren, is het dan raadzaam om een losse netwerkkaart in mijn eerder genoemde setup? Als ik namelijk ZFSguru wil draaien als OS wordt mijn onboard netwerkkaart niet herkent...


EDIT: Ik schrijf momenteel vanaf mijn laptop een bestand naar de Storage pool dmv. SAMBA en mij valt op dat de processor daar vrij zwaar bij wordt belast.. dit terwijl compressie uit staat.. tevens is de snelheid ook niet optimaal zakt van 70 MB/s naar 28 MB/s. Als ik vervolgens dat bestand weer terug kopieer heb ik een snelheid van 60-70 MB/s.

Even 2 screenshots geknutseld:

[ Voor 22% gewijzigd door 0xygen op 17-08-2012 11:44 ]

[0xygen]

Verwijderd schreef op vrijdag 17 augustus 2012 @ 21:01:

Performance vind ik lastig te zetten; test zoveel als je kan inclusief je fysieke disks. Dat RAID-Z2 veel CPU-kracht vergt is niet zo; een Brazos kan prima een 6-disk RAID-Z2 met scores ver boven de gigabit aan. Jouw scores zijn wat teleurstellend.

Verder: als je netwerkthroughput terugvalt (check dit met task manager > network) is dit een probleem met ZFS transaction groups als je merkt dat de netwerktransfer af en toe stil staat, en later weer verder gaat. Gemiddeld kom je dan maar aan een lage score. In dit geval krijgt ZFS de data niet snel genoeg weggeschreven.

Test al je schijven ook even los met de simple disk benchmark, soms kan het zijn dat één schijf trager is dan de rest en een hele array/pool naar beneden trekt.

Maar, begin eens met een andere netwerkcontroller, dat kan het ook zijn. Een Intel PRO/1000 CT kaartje (PCIe x1) is een uitstekende koop voor iets meer dan twee tientjes. Als je een los kaartje koop; koop dan alleen Intel!

Inmiddels heb ik het PRO/1000 CT kaartje besteld, dus ik kan vanaf donderdag pas testen of dat veel uithaalt (ik ben van dinsdag tot donderdag een paar daagjes weg)

Verder heb ik benchmarks gemaakt van alle disks individueel waarbij ik geen grote verschillen waarneem in resultaat.


Ook heb ik even het netwerk gemonitord met dit resultaat:


Er zitten dus inderdaad van die dipjes in...
Ik ga nu de server rebooten en doe dan nog wat tests.


Wat mij aan de laatste test opvalt is dat hij eerst wel de volle snelheid haalt (ik denk dat hij dan naar de RAM toe schrijft??) waarna hij daarna invalt. Hierdoor lijkt het er op dat het probleem dus in ZFSguru zit en niet in de server of de PC of netwerkkaart.

[ Voor 9% gewijzigd door 0xygen op 18-08-2012 12:40 ]

[Megalith]

Ik heb vorige week twee nieuwe Intel 330 60GB ssd's besteld. Deze hangen nu in m'n norco case aangesloten op de SATA backplane maar de lifetime van deze twee dingen geeft wel hele abnormale waardes aan. De RAW value verhoogt om de seconde met enkele tientallen biljoenen.



Ook valt het me op dat er wel erg veel gespammed wordt. Vooral de da10 en da02 willen nog wel eens SCSI meldingen geven.