Het grote ZFS topic

[HyperBart]

jjust schreef op zondag 08 november 2015 @ 09:02:
Dat is een goede tip. Zal ik eens naar kijken.

Ze maken het wel heel makkelijk:

https://www.transip.nl/forum/post/prm/1819#1819

[CurlyMo]

Pantagruel schreef op dinsdag 10 november 2015 @ 10:45:
[...]


2 TB voor €10,- per maand staat op de site, als je meer wilt zul je ze moeten e-mailen voor een prijsopgave lijkt me. De enige echte beperking zal je upload snelheid zijn.

Inclusief 5 euro voor je VPS. Je krijgt geen directe toegang tot de Big Data service.

[Pantagruel]

CurlyMo schreef op dinsdag 10 november 2015 @ 11:57:
[...]

Inclusief 5 euro voor je VPS. Je krijgt geen directe toegang tot de Big Data service.

Klopt, ik had sec naar de kosten voor je data opslag gekeken, dat er een VPS-je bij kwam leek me voor de hand te liggen.

[staticint]

Hey allemaal,

Vannacht zat er dit in mijn daily security run:

code:

tiamat kernel log messages:
+++ /tmp/security.XJIZfzIH  2015-11-10 03:01:01.197323779 +0100
+(da4:mps0:0:4:0): WRITE(10). CDB: 2a 00 e2 f8 1d 28 00 00 18 00 
+(da4:mps0:0:4:0): CAM status: SCSI Status Error
+(da4:mps0:0:4:0): SCSI status: Check Condition
+(da4:mps0:0:4:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
+(da4:mps0:0:4:0): Info: 0xe2f81d28
+(da4:mps0:0:4:0): Error 22, Unretryable error

Mijn 'zpool status' geeft het volgende weer:

code:

  pool: zstorage
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 0 in 4h41m with 0 errors on Sun Nov  1 10:41:06 2015
config:

        NAME                                              STATE     READ WRITE CKSUM
        zstorage                                          ONLINE       0     0     0
          raidz2-0                                        ONLINE       0     0     0
            diskid/DISK-%20%20%20%20%20WD-WCC4N22A7AYVp1  ONLINE       0     0     0
            diskid/DISK-%20%20%20%20%20WD-WCC4N76L0NJ1p1  ONLINE       0     1     0
            diskid/DISK-%20%20%20%20%20WD-WCC4N76L0T3Tp1  ONLINE       0     0     0
            diskid/DISK-%20%20%20%20%20WD-WCC4NKNTZ35Rp1  ONLINE       0     0     0
            diskid/DISK-%20%20%20%20%20WD-WCC4NKNTZPDDp1  ONLINE       0     0     0
            diskid/DISK-%20%20%20%20%20WD-WMC4N0D566A3p1  ONLINE       0     0     0

Nu vraag ik mij de volgende dingen af:

• Die write error is dit iets wat ik uit moet gaan zoeken omdat het een voorbode is van een drive failure? Of zou dit iets eenmaligs zijn, en moet ik me pas zorgen gaan maken als er SMART errors tevoorschijn komen? (vooralsnog zijn de SMART-waardes prima)
• Kan ik ergens instellen dat ik direct een mail krijg als mijn zpool errors geeft? Ik weet dat er onder ZoL zoiets als de ZFS event daemon is. Is onder FreeBSD devd de gebruikelijke manier om dit op te lossen?

Ik had wel het volgende gevonden: http://lists.freebsd.org/pipermail/freebsd-scsi/2013-January/005752.html
Maar de TS is daar vertrokken zonder het antwoord te delen

[Verwijderd]

Logical block address out of range wil zeggen dat de host (ZFS) heeft geprobeerd iets te lezen of te schrijven (in jouw geval dit laatste) wat buiten de capaciteit valt van de schijf. Dus bijvoorbeeld schrijven naar positie 4.5TB terwijl het een 4TB schijf is. Dat is wel een vreemde error.

Ik vermoed dat het ligt aan je mps driver. Het kan komen omdat FreeNAS een oudere 9.x versie gebruikt en daarbij is de mps driver ook ouder. Ik zou me er niet veel van aantrekken. Hou wel de SMART goed in de gaten!

[F-Tim]

Om alvast wat ervaring met ZFS op te doen ben ik al bezig om een VM aan te maken zodat ik al een en ander kan testen. Of beter gezegd, 2 VM's... 1 met FreeNAS en 1 met ZFSGuru. Beide ondernemingen lopen echter niet van een leien dakje...

ZFSGuru 0.3.1, 1,5GB RAM, 6x2GB HD's, vanuit de webinterface 1 RAID Z2 vdev aangemaakt. User aangemaakt, en een Samba share met "Everyone" full control. (Alleen Guest heeft read-only), share is mooi via het netwerk te benaderen... echter alleen read-only? Ik krijg op geen enkele manier vanuit Windows een bestand op de share. Ongeacht of het nu wijzigingen zijn, een nieuwe map is of bestanden toevoegen. Zelfs het "read-only" van de gast uitschakelen loste het niet op. En ja, ik heb vanuit Windows met het juiste test account ingelogd.

Had in eerste instantie met 6x 250MB disks geprobeerd, maar toen werden ze niet eens herkend. Vergroten naar 6x 2GB verhielp dat probleem in ieder geval. Maar het read-only probleem kwam ik niet echt uit, terwijl ik toch wel de juiste settings heb voor m'n gevoel.

Toen dacht ik, weet je wat... ik ga eens een andere proberen en kijken hoe goed die bevalt; FreeNAS dus...

FreeNAS 9.3 stable, 2GB RAM toegekend, ook hier 6x 2GB HD's + 1x 8GB HD... wizard doorlopen waarbij ik ook een RAIDZ2 heb gekozen voor de 6x2 (hoefde nog geen HD's te kiezen) en de installatie op de 8GB gezet heb. Daarna zag ik bij Storage nog geen Volume's staan, dus ik probeer een Volume aan te maken, kies daarbij de 6 disks, maak een volume aan, en ga naar de Volume manager... en hij blijf staan op "No entry has been found", ongeacht hoe ik de wizard doorloop.

Ik was namelijk van plan om éérst een werkende 6 disk Z2 vdev te maken. Zodra dat lukte, én ik merk hoe eenvoudig het resilveren gaat. het daarna nogmaals te doen met een 4 disk + 2 memory disk (offline). Dan had ik de generale repetitie achter de rug, en dan wist ik dat ik mijn eigen data t.z.t. eenvoudig kon overzetten naar de NAS.

Ben ik nou nog te simpel om een VM aan te maken waar ik eenvoudig mee kan rotzooien? Of wie kan me hier eenvoudig mee 'op gang' helpen?

[Verwijderd]

F-Tim schreef op dinsdag 10 november 2015 @ 16:03:
ZFSGuru 0.3.1, 1,5GB RAM, 6x2GB HD's, vanuit de webinterface 1 RAID Z2 vdev aangemaakt. User aangemaakt, en een Samba share met "Everyone" full control. (Alleen Guest heeft read-only), share is mooi via het netwerk te benaderen... echter alleen read-only?

Heb je de 'share' filesystem gedeeld of heb je het 'hoofd' filesystem (zelfde naam als de pool) gedeeld? Want bij dat laatste krijg je een melding dat delen ervan niet is aanbevolen en dat standaard de permissies ervan niet goed staan. Bij het 'share' filesystem of andere filesystems die je aanmaakt hoort dat wel het geval te zijn.

Toen dacht ik, weet je wat... ik ga eens een andere proberen en kijken hoe goed die bevalt; FreeNAS dus...

Dat is nou het mooie van ZFS dat je altijd naar een ander platform kunt overstappen. Vrij uniek want ZFS draait op vrijwel alle operating systems behalve Windows. Mocht iets niet lekker werken op platform A dan kun je rustig overstappen naar platform B en vice versa.

FreeNAS 9.3 stable, 2GB RAM toegekend, ook hier 6x 2GB HD's + 1x 8GB HD... wizard doorlopen waarbij ik ook een RAIDZ2 heb gekozen voor de 6x2 (hoefde nog geen HD's te kiezen) en de installatie op de 8GB gezet heb. Daarna zag ik bij Storage nog geen Volume's staan, dus ik probeer een Volume aan te maken, kies daarbij de 6 disks, maak een volume aan, en ga naar de Volume manager... en hij blijf staan op "No entry has been found", ongeacht hoe ik de wizard doorloop.

Ik ken FreeNAS niet zo. Misschien dat iemand anders het weet of dat je op het FreeNAS forum je vraag kwijt kunt. Een screenshot is vaak nuttig.

Ik was namelijk van plan om éérst een werkende 6 disk Z2 vdev te maken. Zodra dat lukte, én ik merk hoe eenvoudig het resilveren gaat. het daarna nogmaals te doen met een 4 disk + 2 memory disk (offline). Dan had ik de generale repetitie achter de rug, en dan wist ik dat ik mijn eigen data t.z.t. eenvoudig kon overzetten naar de NAS.

Lijkt me een goed plan. Maar dan draai je dus wel double degraded in het begin. Daar moet je je wel van bewust zijn - je hebt géén redundancy totdat je minimaal één disk toevoegt - of eigenlijk de offline memory disk mee vervangt.

[FREAKJAM]

Als je al een pool hebt gemaakt in ZFSGuru moet je bij de wizard in FreeNAS simpelweg je huidige pool even importeren. Anders de wizard overslaan en handmatig importeren. De docs van FreeNAS zijn trouwens vrij duidelijk.

[F-Tim]

Verwijderd schreef op dinsdag 10 november 2015 @ 16:22:
Heb je de 'share' filesystem gedeeld of heb je het 'hoofd' filesystem (zelfde naam als de pool) gedeeld? Want bij dat laatste krijg je een melding dat delen ervan niet is aanbevolen en dat standaard de permissies ervan niet goed staan. Bij het 'share' filesystem of andere filesystems die je aanmaakt hoort dat wel het geval te zijn.

That's it! Ik had idd die "share" weggemikt en de "root" geshared.. met als gedachte "ik wil alle bestanden gewoon in de root dumpen en presto". Dan is dat dus een vervolgonderzoek kijken of dat überhaupt wel mogelijk is; 1 "root" map, die gewoon met user/password protecten en daarin direct alles. Hoewel t in praktijk weinig uitmaakt, want via het netwerk zie je toch alleen maar die ene share.

Lijkt me een goed plan. Maar dan draai je dus wel double degraded in het begin. Daar moet je je wel van bewust zijn - je hebt géén redundancy totdat je minimaal één disk toevoegt - of eigenlijk de offline memory disk mee vervangt.

Was idd de bedoeling, wellicht dat het slimmer is om met veel schuiven van data en wat externe disks roven dat ik nog wel 4TB data elders parkeren, dan zou ik wellicht met single-degraded kunnen starten. Dan is de kans op issues tijdens de resilver al een stuk kleiner. Kleine denkfout in mijn proces namelijk, op het moment dat ik resilver nummer 1 doe, heb ik de data al niet meer dubbel... dus k moet even een alternatief bekijken.

Het waren overigens beide losse VM's, met beiden een eigen pool. Had het nog niet met slechts 1 pool geprobeerd Eerst maar eens zorgen dat mijn basisbehoeften voorzien zijn; een goed stappenplan zodat zodra ik straks alle onderdelen ga kopen het geen weggegooid geld blijkt te zijn, of ik nog méér disks moet kopen en investeren.

[Edit]
Inmiddels letterlijk álle stappen vanuit de ZFSGuru web interface kunnen doen. Inclusief de generale repetitie van het aanmaken van de Z2 pool met 4 gewone en 2 memory disks, memdisks offline gooien, gewone disk aanknopen, resilver... repeat... en tussentijds draait alles nog gewoon vrolijk door!

Ik moet zeggen CiPHER... respect knap werk met ZFSGuru!

Enige wat nu nog rest is de hardware kopen, alles in elkaar schroeven, en van tevoren al ZFSGuru op een USB stick installeren.

[Edit 2]
Moet ik bij het aanmaken via de web interface van ZFSGuru ook nog rekening houden met het feit dat ik de pool over X tijd wil gaan expanden (d.m.v. disk replacement)? Of is dit automatisch al ingeschakeld? Dit kan ik nog niet zo snel terugvinden.... (dus geen vdevs toevoegen, maar enkele disks vervangen door disks met grotere capaciteit)

[ Voor 18% gewijzigd door F-Tim op 11-11-2015 10:55 ]

[Verwijderd]

Disks groter maken kan achteraf altijd. Moet je per disk replacen met een grotere disk en uiteindelijk autoexpand aanzetten. Daar hoef je dus vooraf niets voor te doen.

Overigens: je kunt direct op de disks installeren - een USB stick is niet nodig. ZFSguru heeft nog geen speciale USB modus die weinig naar de USB stick schrijft, zoals FreeNAS heeft. ZFSguru heeft dan wel weer Root-on-ZFS waardoor je direct van je ZFS pool boot. Beperking is wel dat je maar één vdev mag hebben. Dus één mirror of één RAID-Z2 van 10 disks dat kan allemaal, maar twee vdevs is niet meer bootable. Je kunt daarom ook partities maken zodat je een 'boot pool' maakt van 20GB ofzo en die in een mirror zet. De rest van de ruimte dus de grote partitie gebruik je dan voor je 'data pool'.

Wil je persé een USB stick dan dien je wel een goede te nemen of je performance en levensduur is enorm laag. Een goede USB stick is bijvoorbeeld Sandisk Extreme.

Succes!

[F-Tim]

Verwijderd schreef op woensdag 11 november 2015 @ 11:50:
Wil je persé een USB stick dan dien je wel een goede te nemen of je performance en levensduur is enorm laag. Een goede USB stick is bijvoorbeeld Sandisk Extreme.

Het idee was een Sandisk UltraFit 16GB, kost niks, is relatief onzichtbaar door z'n formaat, is USB3.0, en met een snelheid van 137(R)/84(W) adequaat genoeg? Of voldoet dit niet?

En waar ga ik het uiteindelijk in merken? NAS Boot time? Of Zpool performance?

[Gonadan]

Nou, grote blij. Enige tijd geleden heb ik met jullie hulp een ZFS-pool opgebouwd binnen mijn Ubuntu server. Toen ben ik niet van OS gewijzigd want dat had een hele inrichting betekend. Nu is echter het OS gesneuveld, iets met 'cannot locate boot device'. Moet nog uitzoeken wat er precies mis is, maar of het nu de schijf of partitie is, de kans is groot dat er veel tijd in gaat en een reïnstall nodig is.

Dus mooi moment om eens te kijken of ik het niet beter aan kan pakken. Als je toch een reïnstall moet doen waarom dat niet meteen een OS wat beter om kan gaan met ZFS? Ben ik gelijk van dat gelazer met die pool die af en toe 'kwijt' is af.

Daarbij komen bij mij twee vragen op. Kan ik de bestaande pool dan gewoon weer laden in een nieuw OS of wordt dat problematisch? Het was een pool van losse schijven, het OS draait op een eigen schijf.

Daarnaast, welk OS? FreeNAS klinkt erg makkelijk, maar ik ben bang dat je erg vast zit aan wat de makers vinden dat je nodig hebt. Ik had initieel juist voor Ubuntu gekozen in plaats van iets kant-en-klaars zodat ik altijd vrijheid had om dingen toe te voegen of anders te doen.

FreeBSD klinkt dan wel aantrekkelijk, kan je gewoon alles mee al weet ik nog niet hoe het zich verhoudt tot Ubuntu qua beschikbaarheid van binaries of packages. Daarnaast vind ik ZFSguru ook wel goed klinken, wat ik vanuit de TS en de websites begrijp zit die er wat tussen in? Wel volledige FreeBSD maar met iets meer richting op ZFS?

[syl765]

De bestaande pool kun je als het goed is gewoon importeren.

Welk OS is een persoonlijke smaak, als je jezelf absoluut niet thuisvoelt op het beste OS wat er is, dan zal het nooit jou OS worden. Het is belangrijk dat je het gevoel hebt in control te zijn met een OS.
Voor mij is dat FreeBSD, op mijn werk gebruiken we Ubuntu, maar wat een draak van een OS is dat in mijn ogen. Voor een ander zal het presies andersom zijn. En sommige kunnen prima overweg met beide.

Het mooie van ZFS is wel dat je later altijd de pool kan gebruiken onder een ander OS.

[Verwijderd]

Daarbij komen bij mij twee vragen op. Kan ik de bestaande pool dan gewoon weer laden in een nieuw OS of wordt dat problematisch?

Dat kan prima.

Daarnaast, welk OS? FreeNAS klinkt erg makkelijk, maar ik ben bang dat je erg vast zit aan wat de makers vinden dat je nodig hebt.

FreeNAS is ietwat Spartaans; op het forum moet je niet uit de pas lopen of je wordt hard gecorrigeerd. Je moet doen wat zij goed vinden, dan wordt je goed geholpen. Zolang je dus binnen de pas blijft heb je een uitstekend platform wat volwassen is en veel kan.

NAS4Free is ook een platform wat meningen heeft; zoals dat een NAS alleen als NAS gebruikt dient te worden en dat vind je terug in de beschikbare addons. Tenzij dit onlangs veranderd is? Ik heb er niet veel zicht op eigenlijk.

ZFSguru is veel minder volwassen - vooral de addons. Het zijn er wel meer en een aantal ervan werken aardig. Voordeel is ook dat je een volledige BSD distributie hebt, dus je kunt handmatig zelf prutsen.

Ubuntu is denk ik helemaal zo slecht niet voor jou als je reeds ervaring hebt met Ubuntu Linux en je goed overweg kunt met het platform zoals software installeren. Ook uitstekende community en er is veel te vinden met google / ubuntuforums. Nadeel is wel dat het allemaal iets minder volwassen is onder de motorkap op ZFS gebied. Dit hoeft geen groot probleem te zijn maar een BSD platform is voor wat betreft ZFS wel het beste.

Geen enkel platform is perfect. Je zult zelf moeten kijken welk platform het beste aansluit bij jouw wensen en vaardigheden. Virtualbox kun je gebruiken om ze allemaal eens uit te proberen. Ook kan het leren van een OS een reden zijn - bijvoorbeeld als je juist BSD wilt leren kennen. Wil je dat niet en wil je bij je comfortzone blijven, dan zou ik zelf eerder Ubuntu aanraden als je vanalles met je NAS/server wilt doen behalve ZFS zelf. Want dat kunnen alle ZFS platforms prima, afgezien van Linux misschien die geen specifieke ZFS web-interface heeft. Maar handmatig commando's via de shell gaat meestal best prima omdat ZFS best eenvoudige commando's kent.

[Gonadan]

Beheer doe ik bijna altijd via de commandline, dat werkt gewoon het fijnst op een server. Webinterfaces zet ik dan op voor bepaalde software die je dan op afstand kunt gebruiken. Waaronder maar niet beperkt tot: Owncoud, Syncthing, Transmission, back-up.

Het voordeel van een NAS-gerichte distro zal zijn dat je veel niet zelf hoeft op te zetten. Anderszijds ben ik inderdaad bang voor wat je schetst. Dat je ook niet veel meer kan dan dat zonder kunstgrepen te moeten uitvoeren en eventuele 'support' meteen te verliezen.

Daarom neig ik ook meer naar een keuze tussen FreeBSD (al dan niet met ZFSguru webinterface) en Ubuntu. Waarbij ik van de laatste weet dat welk softwarepakket je ook tegen komt waarschijnlijk via packages te installeren is. Voor één van mijn voorbeelden, Owncloud, heb je al meteen geen packages en moet je met de hand prutsen. Daarom twijfel ik een beetje. Enerzijds heb ik helemaal niet veel eisen en het meeste aan een stabiel server OS (FreeBSD), anderzijds is de vrijheid en ervaring met Ubuntu ook niet verkeerd. Het geneuzel is alleen dat die laatste niet echt vlekkeloos werkt met ZFS en dat stoort mij toch wel.

Het punt is een beetje dat ik de vorige keer redelijk vlot aan de slag ging en even later mijn pool kon herbouwen vanwege de adviezen die ik later pas tegen kwam. Dus nu probeer ik dat voor te zijn.

[ Voor 8% gewijzigd door Gonadan op 11-11-2015 16:23 ]

[Verwijderd]

Owncloud werkt op ZFSguru prima en volgens mij ook op andere ZFS platforms. Dat is best een populaire addon. Verder kun je veel dingen op BSD simpel met 'pkg' installeren. Vroeger moest je dat allemaal zelf compileren - wat ook niet heel ingewikkeld is met de portstree, maar toch een iets hogere drempel.

Het punt zit hem meer in het configureren. En dat kan allemaal net iets anders werken op BSD dan op Linux. Bijvoorbeeld omdat de paden net iets anders zijn of je netwerkkaart anders heet.

Het wordt wel lastiger als bepaalde software niet goed/makkelijk onder BSD draait. Sonarr bijvoorbeeld zal je makkelijker onder Linux werkend krijgen dan onder BSD. Overigens heeft ZFSguru daarvoor sinds kort wel een addon, maar ik heb nog geen bevestiging gekregen of die ook echt werkt. Sonarr zit namelijk niet in de portstree en wordt dus handmatig geïnstalleerd.

Ik denk dat het een keuze is tussen een experiment voor jezelf of je met BSD overweg kunt - met een beetje hulp van de web-interface. Of dat je je toch het fijnst voelt bij Ubuntu Linux met een vertrouwde interface maar dan misschien iets minder goede ZFS ondersteuning. Mooie is wel dat als het met BSD niet lukt, je altijd naar Linux kunt overstappen en vice versa. Dat vind ik echt een killer feature van ZFS en dat gaat voorlopig ook zo blijven want Btrfs (Linux) en ReFS (Microsoft) werken alleen op één platform en ik verwacht niet dat dit gaat veranderen.

[jjust]

Pantagruel schreef op dinsdag 10 november 2015 @ 10:45:
[...]


2 TB voor €10,- per maand staat op de site, als je meer wilt zul je ze moeten e-mailen voor een prijsopgave lijkt me. De enige echte beperking zal je upload snelheid zijn.

Ik denk dat het wel even gaat duren voordat ik de data heb geupload. Dan is het toch niet zo een goede optie. Het lijkt me trouwens wel een scherpe prijs voor storage.

Nu bedacht ik me dat ik nog 8 2tb schijven liggen uit een oude raid array. Daar ga ik een tijdelijke zfs z2 pool van maken om mijn data te stallen. Dan daarna overzetten naar een IBM 1015 met 6 * 3TB z2.

Ik vraag me alleen af of ik dan niet slimmer 8 * 3TB kan doen dan gebruik ik tenminste alle poorten. Een aantal posts terug was er discussie over de ruimte verlies bij een niet optimale schijf configuratie en de conclusie was dat dit wel mee valt. Misschien doe ik dan wel meteen 8* 3TB dan ben ik voorlopig weer klaar.

[Pantagruel]

jjust schreef op woensdag 11 november 2015 @ 19:11:
[...]


Ik denk dat het wel even gaat duren voordat ik de data heb geupload. Dan is het toch niet zo een goede optie. Het lijkt me trouwens wel een scherpe prijs voor storage.

Nu bedacht ik me dat ik nog 8 2tb schijven liggen uit een oude raid array. Daar ga ik een tijdelijke zfs z2 pool van maken om mijn data te stallen. Dan daarna overzetten naar een IBM 1015 met 6 * 3TB z2.

Dat is altijd sneller dan een storage VPS oplossing

Ik vraag me alleen af of ik dan niet slimmer 8 * 3TB kan doen dan gebruik ik tenminste alle poorten. Een aantal posts terug was er discussie over de ruimte verlies bij een niet optimale schijf configuratie en de conclusie was dat dit wel mee valt. Misschien doe ik dan wel meteen 8* 3TB dan ben ik voorlopig weer klaar.

Een optimale schijfconfiguratie houdt in dat, afhankelijk van t gekozen RAID level, het aantal data disks een n-macht van 2 (2^2, 2^3,etc) + pariteit(s) disk(s). Dit geeft de max performance, echter de verschillen met een sub-optimaal aantal disks (jouw wens: 8 in totaal, dus 6 voor data en 2 voor pariteit bij een RAIDZ2 array) zijn niet zo enorm dat je er wakker van ligt.
Mbt verlies ligt de zaak idd minder gunstig. Optimaal is 8 data disks en 2 parity disks, is 20% verlies aan capaciteit, bij 6 data disks en 2 parity disks is het dus 25% verlies, dus lever je 5% meer in t.o.v de 10 disk setup. (als je 6 vs 8 disks in totaal vergelijkt is het resp. 33% vs 25% verlies))
Maar bekijk t nuchter, als je maar 8 disks kwijt kunt (fysiek of ivm t aantal SATA poorten), waar heb je het dan over; 4x3TiB = 12 TiB data en 4 TiB parity, 6x3 TiB= 18 TiB en 4 TiB parity, ik wist het wel en ging voor de volle 8 disks.

[idef1x]

Verwijderd schreef op woensdag 11 november 2015 @ 15:54:
NAS4Free is ook een platform wat meningen heeft; zoals dat een NAS alleen als NAS gebruikt dient te worden en dat vind je terug in de beschikbare addons. Tenzij dit onlangs veranderd is? Ik heb er niet veel zicht op eigenlijk.

Als hun mening inderdaad is dat een NAS een NAS moet zijn en niets anders, dan moeten ze niet out of the box virtualbox geinstalleerd meeleveren. Maar ja dat is weer mijn mening

[Q]

Pantagruel schreef op woensdag 11 november 2015 @ 21:45:

Een optimale schijfconfiguratie houdt in dat, afhankelijk van t gekozen RAID level, het aantal data disks een n-macht van 2 (2^2, 2^3,etc) + pariteit(s) disk(s). Dit geeft de max performance, echter de verschillen met een sub-optimaal aantal disks (jouw wens: 8 in totaal, dus 6 voor data en 2 voor pariteit bij een RAIDZ2 array) zijn niet zo enorm dat je er wakker van ligt.
Mbt verlies ligt de zaak idd minder gunstig. Optimaal is 8 data disks en 2 parity disks, is 20% verlies aan capaciteit, bij 6 data disks en 2 parity disks is het dus 25% verlies, dus lever je 5% meer in t.o.v de 10 disk setup. (als je 6 vs 8 disks in totaal vergelijkt is het resp. 33% vs 25% verlies))
Maar bekijk t nuchter, als je maar 8 disks kwijt kunt (fysiek of ivm t aantal SATA poorten), waar heb je het dan over; 4x3TiB = 12 TiB data en 4 TiB parity, 6x3 TiB= 18 TiB en 4 TiB parity, ik wist het wel en ging voor de volle 8 disks.

Met Large_blocks support is dit alles AFAIK niet meer een issue dus die N macht regel is dan niet meer zo relevant, zeker niet voor thuis.

[Pantagruel]

Q schreef op donderdag 12 november 2015 @ 11:56:
[...]


Met Large_blocks support is dit alles AFAIK niet meer een issue dus die N macht regel is dan niet meer zo relevant, zeker niet voor thuis.

Klopt, als een zwerende vinger, voor de thuis situatie is t gros van de vuistregels (ZFS best practice guide) leuk maar een pietsie teveel van t goede

(dingen als: 1GB RAM per TiB storage, SSD caching tbv streaming media, etc)

[Verwijderd]

idef1x schreef op donderdag 12 november 2015 @ 09:29:
Als hun mening inderdaad is dat een NAS een NAS moet zijn en niets anders, dan moeten ze niet out of the box virtualbox geinstalleerd meeleveren. Maar ja dat is weer mijn mening

Op deze pagina staat toch heel iets anders: http://wiki.nas4free.org/...at_nas4free_is_and_is_not.

Weet je zeker dat Virtualbox out-of-the-box wordt meegeleverd? Er staat heel duidelijk op die pagina dat NAS4Free geen VM host is.

Among the things that NAS4Free is not, and should not ever be are the following items, which make up a non-complete list.

Virtual Machine Host - Again, the processing power and ram of the NAS are supposed to be used for moving hard drive data to/from the network. Wasting your CPU time or memory on running virtual machines means that those resources are unavailable to other more important tasks, like making sure the data can get to/from the network in an expedient manner. In particular, if your NAS only had the recommended quantity of ram for the size of your ZFS storage to begin with, it is especially unwise to take any of that ram away. Even the setup, configuration, and especially troubleshooting of jails (which are virtual-machine-like), which are an included technology, are totally unsupported. So, when users set up a jail, and then break anything, no help will be provided for fixing the mess.

[FREAKJAM]

Hij is denk ik in de war met FreeNAS. Die levert sinds versie 9.2.1.6 out of the box ondersteuning voor Virtualbox op basis van een template die beschikbaar is.

For 9.2.1.6 nightly dated 5/24/2014 and newer you can setup a virtualbox jail with only minimal configuration required! This will install Virtualbox 4.3.10. This is not "official" as it is still being tested, but should be reliable enough for you to be able to use it(with appropriate hardware) and should be able to migrate your VMs to the "official" jail if/when that happens.

[ Voor 124% gewijzigd door FREAKJAM op 12-11-2015 14:07 ]

[Q]

http://blog.nordeus.com/d...ure-testing-with-ssds.htm

Hier doen ze wat power failure tests op een paar SSDs. Kan mogelijk interessant zijn voor het publiek hier.

[Pantagruel]

Q schreef op donderdag 12 november 2015 @ 16:36:
http://blog.nordeus.com/d...ure-testing-with-ssds.htm

Hier doen ze wat power failure tests op een paar SSDs. Kan mogelijk interessant zijn voor het publiek hier.

Pfew, vooral zorgelijk dat een controller met BBU niet automagisch betekend dat je beter zit bij een power failure. [UPS dan toch maar ]

Het feit dat je voor ZFS juist geen RAID controller met BBU wilt gebruiken maakt dan dat je zult kiezen voor een SSD met een SuperCap om een power failure op te vangen en een cache flush naar ssd mogelijk te maken. De Intel 520 heeft dat maar laat vlgs hun tests duidelijk het stokje vallen. Wat dus overblijft is een echte servergrade ssd a la de S3500 en consorten. Sparen of de Sint of kerstman lief aankijken

[FireDrunk]

Leuke post! Mijn 840 Pro's zouden daarmee dus geschikt zijn voor SLOG en L2ARC. Ze honoreren bij Samsung blijkbaar ondanks de grote DRAM caches, goed de fsyncs.

[Verwijderd]

Ik heb daar toch mijn twijfels bij. Ik moet de test nog goed doorlezen, maar ik heb de indruk dat er bij de database test vooral consistency wordt getest. Dat werkt inderdaad bij de Samsungs omdat die journalling toepassen en dus terug in de tijd gaan na een power failure. Dan ga je inderdaad terug naar een moment dat consistent was, maar het eerbiedigt niet de flush commando's in die zin dat het zeker is dat die data op de disk staat. Het zorgt wel voor dat de volgorde van de writes niet wordt omgedraaid. En dat wat je in bijna alle gevallen wilt. Behalve dus voor een ZFS sLOG disk. Daar draait het juist allemaal om de laatste writes, en wil je een ECHTE flush/sync en geen nepflush waarbij enkel de volgorde wordt gehonoreerd.

De fsync test is wel interessant, maar het is mij onduidelijk of daarbij inderdaad alle sync gehonoreerd worden als de write cache uit gaat. Zo heel expliciet staat dat niet in de test. Wat er wel staat is dat in de standaard configuratie met write cache ingeschakeld, de 840 Pro de test faalt. Onduidelijk ook weer wat dat precies betekent.

Uiteindelijk maar zelf uitvoeren die test, of je eigen test maken. Ik zou niet heel snel de conclusie trekken dat dit betekent dat je Samsung als sLOG kunt gebruiken. Al helemaal niet met write caching en misschien zelfs niet zonder write caching.

@Pantagruel: wat bedoel je met capacitors? De Intel 330, 520 hebben geen caps hoor, alleen de 320 en bij de S3500 zelfs enkel voldoende voor de lopende write dus geen volledige bescherming van de DRAM write-back.

[FireDrunk]

Hoewel ik het verhaal vaker gehoord heb, kan ik weinig vinden over hoe Samsung journalling gebruikt in zijn firmware. Ik zie ook niet in hoe dat anders is dan andere fabrikanten.
Intel doet het volgens mij ook, en we roepen allemaal termen als Mapping Tables...

Wat je al zei: Het belangrijkste is, als het systeem om een harde fsync vraagt, wordt dan de fsync alleen in de journal op de SSD gezet, of wordt de hele DRAM cache geflushed en de write echt op NAND gecommit voordat het signaal terug gaat naar de applicatie.

[Verwijderd]

Bij een abrupte stroomonderbreking zonder capacitor-bescherming zijn de mapping tables niet consistent met de data. Dan heb je dus corruptie. Om dit te voorkomen maak je gebruik van een soort CoW-design waarbij recente data niet zomaar wordt overschreven. Hierdoor kun je een oudere versie van de mapping tables gebruiken die WEL consistent met de data is. Eigenlijk dus een soort snapshots dus; alleen de laatste 'snapshot' wordt niet gebruikt omdat deze niet consistent is. Dat is althans hoe ik het begrijp...

De data wordt dus niet in de journal gezet, maar de mapping tables. Het continu naar disk schrijven van de mapping tables bij elke datamutatie zou erg kostbaar (lees: traag) zijn. Dus worden de mapping tables in DRAM gecached en periodiek naar disk geschreven. Alleen de laatste versie die consistent is met de data zal een stroomonderbreking overleven.

Als deze lezing klopt, is Samsung absoluut niet geschikt als sLOG disk, in elk geval niet in default configuratie met device write caching ingeschakeld. Als deze feature wordt uigeschakeld misschien, maar besef dan wel dat je enorm trage performance krijgt. Bij hardeschijven zakt de snelheid in van 200MB/s naar 1MB/s. Bij SSDs hoeft dat minder te zijn, ware het niet dat ook de mapping tables bij elke write moet worden bijgewerkt. De prestaties zouden ernstig kunnen inkakken. Capacitor-bescherming is dus wel zeer wenselijk zodat je én consistentie én performance blijft behouden.

Dat gezegd, hoe het allemaal precies en exact werkt, weet ik niet. Ik heb geen gedetailleerde papers gezien hierover. Wel eentje van Sandisk. Daarbij wordt de suggestie gewekt dat omdat het om SLC writes gaat, de window-of-opportunity voor corruptie maar zeer gering zou zijn, en in de praktijk nauwelijks voorkomt. Maar of dat nou wenselijk is.

Ik denk ook niet dat fabrikanten aan de grote klok willen hangen hoe zij consistentie bewaren zonder een ernstige impact te maken op de prestaties. Veel van die dingen zijn bedrijfsgeheim die je enkel met een NDA kunt inzien. Je kunt wel testjes doen dat met write caching uitgeschakeld de sync performance enorm inzakt, bijvoorbeeld. Daar kun je wellicht wel conclusies uit trekken. En een beetje theory-crafting vind ik ook wel leuk.

[FireDrunk]

Wat stel je voor als test? Ik heb een sloot aan ssds liggen en vakantie, dus kan best iets testen

Heb nog liggen: 840 Pro, MX100, Sandisk 32GB Cache, en als het moet een verdwaalde Intel 320.

[Verwijderd]

Een hardwarematige opstelling zou het beste zijn waarbij enkel de SSD stroom verliest. Dan een paar seconde later weer stroom krijgt en dan wordt gekeken welke data de SSD nog heeft. De data die geschreven zou moeten worden zou async writes moeten zijn en sync writes (met FLUSH CACHE commando). En met instellingen van device write-back (write cache) ingeschakeld en uitgeschakeld.

Bij de Intel 320 zou je moeten zien dat ook async writes het overleven omdat de volledige 256KiB SRAM buffercache is beveiligd door capacitors. Bij andere SSDs zoals Crucial M500/M550/MX100/MX200 zou je moeten zien dat enkel sync writes het overleven. Bij Samsung zou je moeten zien dat alleen writes in het verleden het overleven, maar wel in de juiste volgorde (dankzij de journalling).

[FireDrunk]

Volgens mij klopt dat niet, dat zou betekenen dat alle writes die een database doet synced moeten zijn.

Volgens mij schrijven databases niet 100% synced, maar alleen (net als ZFS) als er cruciale pointers verzet worden.

Het lijkt mij van belang dat bij een synced write alles wat voor de synced write gestuurd is ook gecommit wordt anders zouden we veel meer corruptie zien. ZFS kan hele megabytes async doen, en pas bij de commit fase de pointer synced verzette n. Dat zou betekenen, dat hele transactiongroups corrupt zijn en ZFS een hele transactie terug moet. Dat kan ik me nog wel voorstellen.

Datzelfde geld dan voor databases, die zouden dan ook grootschalig corrupt moeten raken.

Dat heb ik persoonlijk nog nooit gezien of van gehoord, jij wel?

[ Voor 9% gewijzigd door FireDrunk op 13-11-2015 08:01 ]

[Verwijderd]

Databases doen veelal hun eigen logfiles en vertrouwen dus niet op het filesystem. InnoDB volgens mij ook. Maar MariaDB en MyISAM weet ik niet. Dat zou echter wel betekenen dat ze veel sync writes doen. Volgens mij is dat zeker wel zo.

ZFS is overigens niet heel anders dan SSDs die ook sync writes (FLUSH CACHE commando's) niet strict opvolgen. Dat wil zeggen: ZFS bewaakt de volgorde van writes dus async writes bestaan niet als de voorgaande sync write ook niet bestaat, en vice versa. Dus de volgorde wordt bewaakt. Maar een sync write zorgt er niet voor dat er direct gecommit wordt - net als bij SSDs.

Ik hoor Jeff Bonwick nog zeggen in een videostream: "95% of the time, this is what you want". De overige 5% van een sync write zou dan zijn dat je wél wilt dat er direct gecommit wordt ipv enkel de volgorde van de writes bepalen.

[FireDrunk]

Maar iets in userspace KAN niet anders dan op POSIX calls en filesystems vertrouwen? Een applicatie kan namelijk nooit garanderen dat iets gecommit is naar disk via een andere interface?

Ik heb denk ik iets belangrijks gevonden:
POSIX Fsync() beschrijving.

fsync() transfers ("flushes") all modified in-core data of (i.e.,
       modified buffer cache pages for) the file referred to by the [b]file
       descriptor[/b] fd to the disk device (or other permanent storage device)
       so that all changed information can be retrieved even after the
       system crashed or was rebooted.  This includes writing through or
       flushing a disk cache if present.  The call blocks until the device
       reports that the transfer has completed.  It also flushes metadata
       information associated with the file (see stat(2)).

De belangrijkste term hier is dus File Descriptor. In de POSIX standaard staat dus samengevat:
Na een synced write mag je er vanuit gaan dat al je async writes naar dezelfde file descriptor ook gedaan zijn. In het kader van databases is het in dat geval dus belangrijk, dat als je Tabel A update met info uit Tabel B, en die beide tabellen zitten in verschillende files, dat je even netjes fsync calls doet in de goede volgorde. Dat zelfde geld voor Transactie Logs.

Als ditzelfde principe in SSDs toegepast wordt, heb je natuurlijk het verschil dat een SSD geen flauw benul heeft van file descriptors, en je filesystem dus niet tegen een SSD kan zeggen wat hij wel en niet moet flushen...

[ Voor 8% gewijzigd door FireDrunk op 13-11-2015 08:24 ]

[Verwijderd]

De SSD ziet alleen LBA - logisch. Maar het ziet wel verschil tussen sync writes en async writes. Zo ook je filesystem.

Wat daar staat is eigenlijk niet meer van toepassing op SSDs en ook op filesystems als ZFS. Write-through bestaat bijna niet meer, om performance redenen. Wat wel bestaat is wat jij zegt: dat als een sync write het overleeft, ook alle voorgaande async writes het overleven. Kortom de volgorde wordt bewaakt, maar een sync write die wordt voltooid betekent niet meer dat zeker is dat die write definitief is weggeschreven.

[FireDrunk]

Ik kan me echt slecht voorstellen dat alle buffer flushes genegeerd worden in SSDs... Dat zou echt fataal zijn in veel gevallen... Dat zou echt betekenen dat iedereen die zijn PC hard uitzet, af en toe reset omdat er iets vastgelopen is, of wat dan ook, al vrij snel echt veel corruptie zou moeten zijn... Ik kan dat slecht geloven

_{niet omdat ik jou niet geloof, meer omdat ik het zelf ook vaak zat gedaan heb, en nog nooit iets gezien heb dat op merkbare corruptie lijkt in deze gevallen. En ik gebruik al SSDs vanaf de Intel x25-M 80GB... Best lang dus.}

Goede test in dit geval zou dus zijn:

Schrijf parallel naar 4 files, fsync op willekeurige momenten naar een van de files hoe ver je bent met schrijven naar de andere files.

Daarna sloop je de stroom weg, en kijk je wat er in de nieuwste file staat over de andere files, dan kan je zien hoe ver je zou *moeten* zijn...

Zoiets?

[ Voor 46% gewijzigd door FireDrunk op 13-11-2015 08:36 ]

[idef1x]

FREAKJAM schreef op donderdag 12 november 2015 @ 14:01:
Hij is denk ik in de war met FreeNAS. Die levert sinds versie 9.2.1.6 out of the box ondersteuning voor Virtualbox op basis van een template die beschikbaar is.


[...]

Een template noem ik niet out of the box, want met de template moet wel eerst virtualbox geinstalleerd worden.

Door Cipher's quote ga ik toch weer twijfelen of het inderdaad Nas4Free was...Zal hem nog eens in een VM installeren dan.
Wellicht dat het ZFSGuru was, maar of ik word gek of er was een kant en klare NAS met virtualbox voorgeinstalleerd...

edit: Net even de liveCD van NAS4Free gestart en zelfs bij de liveCD hoef je alleen in de advanced settings de service virtualbox te enablen en een pad op te geven voor je virtual machines. Dus ja dat zie ik als voor geinstalleerd....niet geactiveerd by default, maar toch....ZFSGuru had dat volgens mij ook en alleen bij FreeNAS kon je het makkelijk d.m.v. een template installeren in een jail...

[ Voor 21% gewijzigd door idef1x op 13-11-2015 09:03 . Reden: nas4free nog eens getest ]

[Pantagruel]

Verwijderd schreef op donderdag 12 november 2015 @ 21:33:
snipz

@Pantagruel: wat bedoel je met capacitors? De Intel 330, 520 hebben geen caps hoor, alleen de 320 en bij de S3500 zelfs enkel voldoende voor de lopende write dus geen volledige bescherming van de DRAM write-back.

Vlgs de spec's hier op T.net heeft de 520:

code:

Intel 520 240GB specificaties
HDD/SSD-aansluitin  SATA
SSD-type    Multi Level Cell
SSD-controller  SandForce SF2281
SSD eigenschappen   Stroomverliesbescherming
Hardeschijf bus (intern)    SATA-600

etc..

Ik heb niet bij Intel gecontroleerd of dat klopt (klaarblijkelijk dus niet ) en dan heb ik t mbt de 520 idd bij t foute end.

FireDrunk schreef op vrijdag 13 november 2015 @ 08:34:
Ik kan me echt slecht voorstellen dat alle buffer flushes genegeerd worden in SSDs... Dat zou echt fataal zijn in veel gevallen... Dat zou echt betekenen dat iedereen die zijn PC hard uitzet, af en toe reset omdat er iets vastgelopen is, of wat dan ook, al vrij snel echt veel corruptie zou moeten zijn... Ik kan dat slecht geloven

_{niet omdat ik jou niet geloof, meer omdat ik het zelf ook vaak zat gedaan heb, en nog nooit iets gezien heb dat op merkbare corruptie lijkt in deze gevallen. En ik gebruik al SSDs vanaf de Intel x25-M 80GB... Best lang dus.}

Dat zou idd heel snel 'oefening over' betekenen voor de consistentie van je fs.
Het is niet dat het dagelijks gebeurd maar de hier aanwezige ssd's (Intel x25-M 80 GB, Crucial M4 128 GB, Samsung 830/840 256 GB) hebben tot nu toe 'onvrijwillig' stroom verlies zonder ogenschijnlijke schade doorstaan).
De Intel x25-M 80 GB huisvest een aantal ESXi vm's waaronder 2 db servertjes (MySQL) en na de laatste twee 'ongelukjes' was er niets aan de hand. Dit kan natuurlijk ook dom geluk zijn, dat sluit ik niet uit.

[ Voor 45% gewijzigd door Pantagruel op 13-11-2015 09:21 ]

[BCC]

Pantagruel schreef op dinsdag 10 november 2015 @ 10:45:
[...]
2 TB voor €10,- per maand staat op de site, als je meer wilt zul je ze moeten e-mailen voor een prijsopgave lijkt me. De enige echte beperking zal je upload snelheid zijn.

Elke 2TB meer is weer een 10tje extra. Dit kun je gewoon in de webinterface invullen. Er zal vast een maximum aanzitten en het zal ook vast goedkoper worden als je heel veel afneemt

[yamahabest]

We zijn bezig met een setup met een ZFS server voor de storage en een ESXi server voor de virtualisatie.
We willen de ZFS server puur voor storage gebruiken, en deze via VMs beschikbaar maken.
Dit omdat we bijvoorbeeld meerdere Samba instanties moeten draaien met verschillende gebruikers, die fysiek van elkaar gescheiden moeten zijn.

Wat is hier nu verstandig vanuit ZFS oogpunt?
Je kan via NFS/ISCSI een blok ruimte beschikbaar maken, die dan als datastorage aan ESXi toegevoegd kan worden. Hierop kan je dan de VMs zetten, en mogelijk extra virtuele disks maken om de ruimte te verdelen tussen de VMs. Ik lees op internet dat dit aangeraden wordt, ZFS buiten beschouwing latende.
Je zou ook vanuit de VMs rechtstreeks naar de NFS/ISCSI "shares" kunnen connecten om zo de data kwijt te kunnen.

Bij de eerste oplossing werk je natuurlijk met een "eigen" filesysteem in de virtuele disks, wat misschien minder handig is.
Bij de tweede oplossing schrijf je wel rechtstreeks op het ZFS filesysteem.

[ Voor 4% gewijzigd door yamahabest op 13-11-2015 16:04 ]

[FireDrunk]

Het eigen filesystem (VMFS) van ESXi gebruiken of de Virtuele Machines extra VMDK's geven op NFS heeft als grote voordeel dat je snapshots kan maken van de hele VM.

Als je in de VM iSCSI doet, kan dat sowieso niet (via ESXi) meer. Ook is een nadeel dat je veel meer connecties gaat maken naar je storage. Als je 20 VM's op 1 host zet, en ze allemaal een iSCSI LUN geeft, ga je potentieel een hoop connecties maken die niet nodig zijn. Als je ESXi dat allemaal laat afhandelen gaat dat een stuk efficienter.

ESXi via NFS of iSCSI op ZFS gaat overigens prima hoor. Als je op een BSD platform gaat draaien zou ik iSCSI aanraden (omdat NFS zonder hele goede tuning en dure SLOG devices erg traag kan zijn), en iSCSI out of the box gewoon iets sneller presteert.

Gebruik je een Linux platform kan ik je NFS 4.1 aanraden. Daar ben ik de laatste tijd mee aan de slag, en dat werkt verrassend snel.

[FREAKJAM]

Wellicht interessant stukje over ZIL & SLOG.

[ Voor 23% gewijzigd door FREAKJAM op 13-11-2015 18:20 ]

[FireDrunk]

Ik heb een stukje C++ geschreven (moest toch een goede reden hebben om die roestige kennis weer eens bij te poetsen ) om de ASYNC/SYNC SSD test te proberen:

https://github.com/FireDr...lob/master/fsync_test.cpp

Mocht iemand het willen proberen: compiler aansturen gaat met:

g++ -std=c++11 fsync_test.cpp -o fsynctest

Daarna heb je een app fsynctest die je kan uitvoeren. Even een directory tmp aanmaken, daar schrijft de applicatie in.

Geen idee of er mensen zijn die goed C++ kunnen hier, maar misschien dat er iemand is die de strekking van de applicatie kan volgen.

Het idee is: Ik heb x files tegelijk open, ik schrijf asynchroon naar de ene, en ik schrijf synchroon naar de andere dat ik naar de eerste asynchroon heb geschreven.

Dit doe je met vrij veel files tegelijkertijd, waarna je de power van de SSD los trekt.

Daarna kijk je wat er in de files staat. Staat er in file B dat er async naar file A geschreven is, en missen deze writes, zijn er dus async writes verloren gegaan.

Als de test wat uitgebreider is ( het is nu maar een paar K, dus veel te kort om je SSD los te trekken) kan ik hem wel op verschillende Filesystems testen.

Misschien ook eens grappig om het direct op een SSD te testen zonder filesystem (de daadwerkelijke regels naar specifieke LBA nummers schrijven, en gewoon keihard teruglezen. Dan heb je geen filesystem nodig )

[ Voor 31% gewijzigd door FireDrunk op 14-11-2015 15:58 ]

[Bigs]

yamahabest schreef op vrijdag 13 november 2015 @ 16:01:
We zijn bezig met een setup met een ZFS server voor de storage en een ESXi server voor de virtualisatie.
We willen de ZFS server puur voor storage gebruiken, en deze via VMs beschikbaar maken.
Dit omdat we bijvoorbeeld meerdere Samba instanties moeten draaien met verschillende gebruikers, die fysiek van elkaar gescheiden moeten zijn.

Wat is hier nu verstandig vanuit ZFS oogpunt?
Je kan via NFS/ISCSI een blok ruimte beschikbaar maken, die dan als datastorage aan ESXi toegevoegd kan worden. Hierop kan je dan de VMs zetten, en mogelijk extra virtuele disks maken om de ruimte te verdelen tussen de VMs. Ik lees op internet dat dit aangeraden wordt, ZFS buiten beschouwing latende.
Je zou ook vanuit de VMs rechtstreeks naar de NFS/ISCSI "shares" kunnen connecten om zo de data kwijt te kunnen.

Bij de eerste oplossing werk je natuurlijk met een "eigen" filesysteem in de virtuele disks, wat misschien minder handig is.
Bij de tweede oplossing schrijf je wel rechtstreeks op het ZFS filesysteem.

De tussenweg waar ik voor zou kiezen is vanuit ZFS iSCSI volumes exporteren en die als RDM in virtual mode toevoegen an je VM. Dan profiteer je van snapshots op VMware niveau en thin provisioning aan de ZFS zijde. Je kunt zo'n iSCSI volume zelfs aan meerdere VM's koppelen als je een cluster FS gebruikt en zo een HA oplossing inrichten.

[Q]

The Birth of ZFS by Jeff Bonwick
YouTube: The Birth of ZFS by Jeff Bonwick

[yamahabest]

FireDrunk schreef op vrijdag 13 november 2015 @ 17:21:
Het eigen filesystem (VMFS) van ESXi gebruiken of de Virtuele Machines extra VMDK's geven op NFS heeft als grote voordeel dat je snapshots kan maken van de hele VM.

Als je in de VM iSCSI doet, kan dat sowieso niet (via ESXi) meer.

Ok, duidelijk.

FireDrunk schreef op vrijdag 13 november 2015 @ 17:21:
Ook is een nadeel dat je veel meer connecties gaat maken naar je storage. Als je 20 VM's op 1 host zet, en ze allemaal een iSCSI LUN geeft, ga je potentieel een hoop connecties maken die niet nodig zijn. Als je ESXi dat allemaal laat afhandelen gaat dat een stuk efficienter.

Ook duidelijk.

FireDrunk schreef op vrijdag 13 november 2015 @ 17:21:
ESXi via NFS of iSCSI op ZFS gaat overigens prima hoor. Als je op een BSD platform gaat draaien zou ik iSCSI aanraden (omdat NFS zonder hele goede tuning en dure SLOG devices erg traag kan zijn), en iSCSI out of the box gewoon iets sneller presteert.

Gebruik je een Linux platform kan ik je NFS 4.1 aanraden. Daar ben ik de laatste tijd mee aan de slag, en dat werkt verrassend snel.

We gebruiken een BSD platform inderdaad, maar wel met een SLOG en L2ARC.

We zijn oorspronkelijk begonnen met een aantal NFS shares, omdat je daarbij geen grootte op hoeft te geven.

Omdat je bij de ISCSI LUNs de grootte op moet geven, lijkt het mij lastig werken met wisselende groottes.
Maar ook dat valt natuurlijk op te lossen door 1 grote LUN te maken.

[Q]

Je kunt met iSCSI prima luns resizen, mogelijk niet online, dat is het enige lastige.
Resize je zvol en restart je iscsi target.

[FireDrunk]

Kan allemaal online zelfs. ZFS ZVOL vergroten en daarna je iSCSI service reloaden.

[yamahabest]

Vergroten zal inderdaad niet zo'n probleem zijn, verkleinen lijkt mij uitdagender.

Daarom denk ik dat het handiger is om maar 1 grote ZVOL te maken, daarbinnen kunnen de verschillende zaken dan ten opzichte van elkaar groeien en krimpen.

[FireDrunk]

Krimpen is ook simpel, gewoon een nieuw kleiner volume maken en alles migreren, daarna oude weggooien.

[Keiichi]

FireDrunk schreef op woensdag 18 november 2015 @ 12:20:
Krimpen is ook simpel, gewoon een nieuw kleiner volume maken en alles migreren, daarna oude weggooien.

Dat is niet krimpen, dat is gewoon copieeren naar een nieuwe en die gaan gebruiken

[FireDrunk]

Effectief geeft het hetzelfde resultaat

[Guzman5]

Ok bedankt voor de feedback en sorry voor de vervuiling.

[ Voor 94% gewijzigd door Guzman5 op 25-11-2015 13:15 ]

[Dutch2007]

Guzman5 schreef op woensdag 25 november 2015 @ 11:49:
Hoi, ik heb een probleem dat het maar niet lukt om met niet-windows clients te verbinden met een share met username/password (0.3.1 / 10.3.004). Ik krijg altijd de melding dat de username/password incorrect is.

Met Linux/TV/iPAd kan ik alleen met de share zonder username/password verbinden. Dat heeft iets te maken met NTLM? Kan ik dit ergens in ZFSguru aanpassen? Ik wil username/password heel graag aanhouden.

Ik had nog smb.conf aangepast, lanman auth=yes / client ntlmv2 auth=no maar blijf problemen houden (lanman password not permitted for user of no lanman password set for user).

Ik zag eerder iets staan over lanman/ntmlssp en dat ik dat op de client zou moeten aanpassen maar ik zou niet weten of dat lukt op de TV dus wil het graag op de server aanpassen?

maak even je eigen topic hiervoor aan...


Dit is het ZFS >>> OPSLAG <<< topic..
niet het ZFS >>> GURU << help ik heb een issue topic


oh en her en der (op de juiste plek) een enter plaatsen maakt het NET wat leesbaarder

[ Voor 4% gewijzigd door Dutch2007 op 25-11-2015 12:26 ]

[Compizfox]

Dutch2007 schreef op woensdag 25 november 2015 @ 12:22:
[...]
Dit is het ZFS >>> OPSLAG <<< topic..
niet het ZFS >>> GURU << help ik heb een issue topic

Toch wordt dit topic al tijden gebruikt voor discussies over en support voor ZFSGuru. Nee, het hoort eigenlijk niet, maar er is geen dedicated topic voor (en ook geen algemeen BSD-topic) dus komt het hier terecht.

Maar het heeft eigenlijk niets te maken met ZFSGuru, het is een vraag over Samba...

[ Voor 9% gewijzigd door Compizfox op 25-11-2015 13:55 ]

[Dutch2007]

Compizfox schreef op woensdag 25 november 2015 @ 13:54:
[...]

Toch wordt dit topic al tijden gebruikt voor discussies over en support voor ZFSGuru. Nee, het hoort eigenlijk niet, maar er is geen dedicated topic voor (en ook geen algemeen BSD-topic) dus komt het hier terecht.

Maar het heeft eigenlijk niets te maken met ZFSGuru, het is een vraag over Samba...

D'r is wel een ZFS guru topic, en ansich een los topic leek mij wat handiger *(heb geen nieuwe topic overigens meer gezien )

Anyways vraagje over m'n ZFS...

heb nu een 6disk 2TB server waar de storage (free) rond 100GB zit

HP gen8 mini server 4 disk is besteld zal over paar dagen binnen komen...

huidige array is zowel 512byte alsook 4K hdd's...

dus in de array krijg ik die melding als ik zpool list invul dat de invulling niet ok is...

Asich wil ik gewoon een 6 drive pool RaidZ1 behouden, met ik dacht zelfs een 50/50 qua normale en advanced format disk's

maakt het wat uit qua performance als ik die RaidZ1 overzet naar 2k format?

[narotic]

Dutch2007 schreef op woensdag 25 november 2015 @ 16:42:
[...]
huidige array is zowel 512byte alsook 4K hdd's...

Maar je pool is of 512byte of 4k. Wat geeft zpool get ashift poolnaam en/of zdb? (reminder: ashift=9 betekent 512 byte, ashift=12 betekent 4kbyte). Als je vanaf het creeren van de pool al een mix van 512 en 4k schijven had, dan vermoed ik dat je pool al op ashift=12 draait.

Dutch2007 schreef op woensdag 25 november 2015 @ 16:42:
maakt het wat uit qua performance als ik die RaidZ1 overzet naar 2k format?

Veel schijven gebruiken intern 4k, zelfs als ze aan het OS een 512b sector size opgeven. Zelf draai ik al mijn pools sinds jaren op 4k ongeacht wat de schijven zeggen, omdat je voor zover ik weet een stuk erger af bent met een 4k schijf in een 512 byte pool dan omgekeerd. Het nadeel van ashift=12 is niet zozeer het risico op lagere performance, maar dat je meer ruimte verspild als je veel kleine files hebt.

[ Voor 22% gewijzigd door narotic op 25-11-2015 22:55 ]

[Dutch2007]

ashift is nu 9

vdev_tree:
type: 'root'
id: 0
guid: 240286815228339527
children[0]:
type: 'raidz'
id: 0
guid: 435775978962242106
nparity: 1
metaslab_array: 30
metaslab_shift: 36
ashift: 9
asize: 12002352168960
is_log: 0
create_txg: 4
children[0]:

[narotic]

Dutch2007 schreef op donderdag 26 november 2015 @ 01:32:
ashift is nu 9
[...]

Als je de mogelijkheid hebt dan zou ik in jouw situatie de pool opnieuw opzetten met ashift=12. Op FreeBSD kan dat met de zogenaamde "nop trick", terwijl je met ZoL ashift als optie kunt opgeven bij het creeren van de pool.

Strict gesproken zul je een paar procent opslag capaciteit verliezen door de RAID-Z1 met 5 data schijven en 1 parity schijf en zoals gezegd zal de pool minder efficient omgaan met kleine files. Maar de throughput zal er zeker niet op achteruit gaan en wellicht zelfs verbeteren als je nu geemuleerde 512b schijven in je pool hebt. Sowieso zal het steeds moeilijker worden om echte 512byte schijven te vinden, dus vroeg of laat loop je met een ashift=9 pool toch tegen de lamp als je een schijf moet vervangen.

[Dutch2007]

narotic schreef op donderdag 26 november 2015 @ 10:21:
[...]


Als je de mogelijkheid hebt dan zou ik in jouw situatie de pool opnieuw opzetten met ashift=12. Op FreeBSD kan dat met de zogenaamde "nop trick", terwijl je met ZoL ashift als optie kunt opgeven bij het creeren van de pool.

Strict gesproken zul je een paar procent opslag capaciteit verliezen door de RAID-Z1 met 5 data schijven en 1 parity schijf en zoals gezegd zal de pool minder efficient omgaan met kleine files. Maar de throughput zal er zeker niet op achteruit gaan en wellicht zelfs verbeteren als je nu geemuleerde 512b schijven in je pool hebt. Sowieso zal het steeds moeilijker worden om echte 512byte schijven te vinden, dus vroeg of laat loop je met een ashift=9 pool toch tegen de lamp als je een schijf moet vervangen.

Dus toch op m'n FreeBSD 10.1 install de data transferen van oud naar nieuw *eeks* ((kan wel ff duren ^^), en daarna dat met dat commando doen om ashift=12 te krijgen

heb nu 3 disk's "oldskool" en 3 die advanced format... dacht dat het 2k was, maar is inderdaad 4k...

Denk dat ik dan m'n films weg "smijt" en de series op de nieuwe nas zet...

Kan ik daarna m'n 200Mbit ziggo lijntje weer laten "smelten"

[renedis]

Ik heb L2ARC en ZIL op een SSD maar merk echt totaal geen verbetering in de performance.

2TB + 3TB = Mirror van 2TB --> 25GB L2ARC/6GB ZIL
4TB + 4TB = Stripe van 8TB --> 25GB L2ARC/6GB ZIL

Kan het zijn dat de L2ARC/ZIL alleen werkt met een echte ZFS configuratie in plaats van een mirror/stripe?

Transfer snelheden met 10GB bestand:
Mirror:


Stripe:


FreeNAS (VM met M1015 in PCI-passthrough) configuratie:
4 CPU
8GB mem (ook geprobeerd met 16GB mem, maakte niets uit)


Ligt het aan mij of zijn deze snelheden te laag? Of verwacht ik gewoon te veel?

[Verwijderd]

narotic schreef op donderdag 26 november 2015 @ 10:21:
Als je de mogelijkheid hebt dan zou ik in jouw situatie de pool opnieuw opzetten met ashift=12. Op FreeBSD kan dat met de zogenaamde "nop trick"

Dat is verouderd. Modern FreeBSD werkt met automatische detectie van sectorsize en zal ook automatisch optimaliseren voor de juiste ashift instelling. Je kunt dit desgewenst beïnvloeden met de volgende sysctl's:

# sysctl -a | grep ashift
vfs.zfs.min_auto_ashift: 9
vfs.zfs.max_auto_ashift: 13

Wil je minimaal ashift=12 en werkt de sectorsize detectie niet goed, dan kun je overrulen met:

sysctl vfs.zfs.min_auto_ashift=12

Daarna je pool aanmaken met zpool create commando.

Alleen oudere BSD releases ondersteunen dit niet. Mogelijk geldt dit ook voor FreeNAS aangezien zij wat achterlopen met versie 9.x ipv 10.x en 11-CURRENT.

[narotic]

Verwijderd schreef op donderdag 26 november 2015 @ 16:48:
[...]

Dat is verouderd. Modern FreeBSD werkt met automatische detectie van sectorsize en zal ook automatisch optimaliseren voor de juiste ashift instelling. Je kunt dit desgewenst beïnvloeden met de volgende sysctl's:

# sysctl -a | grep ashift
vfs.zfs.min_auto_ashift: 9
vfs.zfs.max_auto_ashift: 13

Wil je minimaal ashift=12 en werkt de sectorsize detectie niet goed, dan kun je overrulen met:

sysctl vfs.zfs.min_auto_ashift=12

Daarna je pool aanmaken met zpool create commando.

Alleen oudere BSD releases ondersteunen dit niet. Mogelijk geldt dit ook voor FreeNAS aangezien zij wat achterlopen met versie 9.x ipv 10.x en 11-CURRENT.

Dank je, is mijn kennis ook weer up to date.

[InflatableMouse]

renedis schreef op donderdag 26 november 2015 @ 16:25:
Ik heb L2ARC en ZIL op een SSD maar merk echt totaal geen verbetering in de performance.

2TB + 3TB = Mirror van 2TB --> 25GB L2ARC/6GB ZIL
4TB + 4TB = Stripe van 8TB --> 25GB L2ARC/6GB ZIL

Kan het zijn dat de L2ARC/ZIL alleen werkt met een echte ZFS configuratie in plaats van een mirror/stripe?

Transfer snelheden met 10GB bestand:
Mirror:
[afbeelding]

Stripe:
[afbeelding]

FreeNAS (VM met M1015 in PCI-passthrough) configuratie:
4 CPU
8GB mem (ook geprobeerd met 16GB mem, maakte niets uit)


Ligt het aan mij of zijn deze snelheden te laag? Of verwacht ik gewoon te veel?

Nu ben ik niet de expert op dit gebied hoor, maar ....

Punt 1: Je kopieert over een netwerk (of via netwerk stack iig) naar een VM en verwacht maximale snelheden?

Punt 2: Je kopieert 10GB bestand terwijl je ZIL 6GB is ...

Punt 3: Heb je je cache en log op aparte dedicated SSD's via de passthrough staan, of zijn dat virtual disks op een gedeelde disk met andere dingen er nog bij?

Open op je terminal eens een zpool iostat -v 1 en kijk welke disks I/O laten zien (en hoeveel).

Benchmark es vanaf de terminal met groottes die in je log passen (of maak de log groter), door bv een tmpfs van 4GB aan te maken (ramdisk) en met dd if=/dev/urandom of=/mnt/ramdisk/dd.tmp bs=1M count=8192 (dit is je temp bestand met random data wat niet/moeilijk te comprimeren is). Geef na elke dd opdracht effe sync. Gebruik vervolgens dd om dat bestand met blocksize 8k naar een dir op je ZFS volume te kopieren. Monitor vervolgens zpool iostat -v 1. Ik denk dat dat al een veel representatiever beeld geeft van de performance en impact van cache en log.

[FireDrunk]

@ Hierboven (x2)

ZIL/SLOG is *geen* Cache zoals jullie doen vermoeden. ZIL zorgt er voor dat je harddisks sequentieel kunnen schrijven, waar ze anders random over de fysieke disk zouden moeten racen door sync writes die tussendoor komen.

In ZFS wordt de ZIL altijd gebruikt (tenzij je deze hard uitzet uiteraard), ook als je geen SSD hebt. Het enige verschil is, dat de ZIL dan op DISK staat in plaats van op een SSD.

Vandaar ook de (beter) term SLOG (Seperate LOG device). Dit betekend dat je die "offloading" van tussenkomende SYNC writes op een SSD doet, die veel sneller is dan een harddisk.

Roepen dat een 6GB ZIL te klein is voor de transfer van 10GB is dus compleet de plank misslaan over hoe ZIL/SLOG werkt.

Over de snelheden:
118MB/s over lokaal netwerk naar een mirror van 2 disks is toch perfect? Je satureert de complete 1Gb bandbreedte? Of heb je overal 10Gb paravirtuele controllers?

[ Voor 10% gewijzigd door FireDrunk op 30-11-2015 09:59 ]

[InflatableMouse]

FireDrunk schreef op maandag 30 november 2015 @ 09:58:

Roepen dat een 6GB ZIL te klein is voor de transfer van 10GB is dus compleet de plank misslaan over hoe ZIL/SLOG werkt.

Genoteerd .

Daarom riep ik al dat ik geen expert ben, ik baseerde m'n uitspraak op de Oracle documentatie waarin ze adviseren dat de ZIL grootte ongeveer ter grootte moet zijn van 10 seconde burst van je array moet kunnen bevatten, waaruit ik dan weer afleidde dat het als een soort cache fungeert. Vandaar de verkeerde conclusie van 10GB in 6GB ... etc ... je snapt wel waar de verwarring vandaan komt.

Over de netwerk snelheid, als je lokaal zit (van host naar guest lokaal of vice versa) gaat het welliswaar over de netwerk stack maar zijn 1Gbit netwerk limitaties niet direct van toepassing. Daarom haalt zijn tweede screenshot wel 180MB/s. Het is echter geen goeie manier vind ik, vandaar dat ik adviseerde om het op de VM zelf te testen.

[renedis]

FireDrunk schreef op maandag 30 november 2015 @ 09:58:
@ Hierboven (x2)

ZIL/SLOG is *geen* Cache zoals jullie doen vermoeden. ZIL zorgt er voor dat je harddisks sequentieel kunnen schrijven, waar ze anders random over de fysieke disk zouden moeten racen door sync writes die tussendoor komen.

In ZFS wordt de ZIL altijd gebruikt (tenzij je deze hard uitzet uiteraard), ook als je geen SSD hebt. Het enige verschil is, dat de ZIL dan op DISK staat in plaats van op een SSD.

Vandaar ook de (beter) term SLOG (Seperate LOG device). Dit betekend dat je die "offloading" van tussenkomende SYNC writes op een SSD doet, die veel sneller is dan een harddisk.

Roepen dat een 6GB ZIL te klein is voor de transfer van 10GB is dus compleet de plank misslaan over hoe ZIL/SLOG werkt.

Over de snelheden:
118MB/s over lokaal netwerk naar een mirror van 2 disks is toch perfect? Je satureert de complete 1Gb bandbreedte? Of heb je overal 10Gb paravirtuele controllers?

Het is een 10Gb paravirtuele controller idd waar dit vanaf is getest.
ZIL/SLOG staat op een dedicated gepartitioneerde Fusion IO SSD 320 GB PCI-E kaart.

Vandaar mijn verwachting dat het hoger zou zijn.

InflatableMouse schreef op maandag 30 november 2015 @ 10:09:
[...]


Genoteerd .

Daarom riep ik al dat ik geen expert ben, ik baseerde m'n uitspraak op de Oracle documentatie waarin ze adviseren dat de ZIL grootte ongeveer een 10 seconde burst van je array moet kunnen bevatten, waaruit ik dan weer afleidde dat het als een soort cache fungeert. Vandaar de verkeerde conclusie van 10GB in 6GB ... etc ... je snapt wel waar de verwarring vandaan komt.

Over de netwerk snelheid, als je lokaal zit (van host naar guest lokaal of vice versa) gaat het welliswaar over de netwerk stack maar zijn 1Gbit netwerk limitaties niet direct van toepassing. Daarom haalt zijn tweede screenshot wel 180MB/s. Het is echter geen goeie manier vind ik, vandaar dat ik adviseerde om het op de VM zelf te testen.

Het gaat om een 10Gbit netwerk intern. De schrijf acties lijken dus om de max schrijf snelheid van de HDD's te gaan.


Het lijkt mij dus niet nutvol voor mij om de ZIL.SLOG op SSD te zetten gezien ik meestal 10GB bestanden heb en zeldzaam bestanden onder de grofweg gezegd 100 mb.

Als deze cijfers daadwerkelijk de max zijn van mijn setup heeft het zetten op SSD van de ZIL/SLOG in mijn ogen weinig zin gezien ik daarmee misschien 0.01 seconden aan tijd win.

Hoe testen jullie je snelheden?
En zou het kunnen zijn dat het aanschaffen van 2x 4TB om in totaal 4x 4TB te hebben in ZRAID1 (12TB opslag) in plaats van de huidige mirror + stripe setup?

Excuses, maar ik ben gewoon geen expert op dit gebied.

[FireDrunk]

Wat is het *doel* van het systeem? Want als je het alleen hebt over 10GB files verplaatsen heeft ZIL/SLOG geen enkele zin. SLOG/ZIL is leuk voor het draaien van Virtual Machines die veel Random IOPS genereren.

Voor gewone sequentiele transfers (van bijvoorbeeld films, tv series, of andere archieven) heeft het uitzetten van SYNC writes (niet altijd verstandig!) meer zin.

[InflatableMouse]

Je zou es kunnen kijken naar de test methode die ik uitlegde. Daarmee haal je een laag weg die roet in het eten kan gooien maar wat je nu niet weet omdat je er niets van ziet.

Ik heb toevallig van het weekend een nieuwe PC voor mezelf in elkaar geschroefd en toen had ik een 256GB SSD over (SATA-600). Ik heb die voor de gein opgedeeld in 64GB en 186GB voor ZIL en L2ARC. Gewoon voor de gein, omdat het kan.

Mijn 3 x 4TB in RAIDZ1 gebruik ik bijna exclusief lokaal voor VM's en backups. Als ik nu lees en schrijf tests doe, zie ik dat continue de cache wel gebruikt wordt (ook met schrijven) maar de ZIL zie ik nooit gebruikt worden.

geen idee verder hoe dat zit .

[FireDrunk]

Kijk eens naar IOMeter, of Bonnie++. In beide kan je vrij specifieke patronen maken waarmee je kan testen.

[Bigs]

De beste tool voor serverbelastingen vind ik nog steeds fio. Voorbeeld voor 75% random read/write mix met 4k block size en een test bestand van 512MB:

code:

fio --randrepeat=1 --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=512M --readwrite=randrw --rwmixread=75

Overigens vind ik 118MB/s naar een mirror van SATA schijven een normale snelheid. Het toevoegen van een extra vdev zal hier naar mijn idee weinig verbetering bieden omdat het maar om één enkele sequentiële schrijfactie gaat.

[renedis]

Bedankt voor de suggesties allemaal.

Mijn VM's staan ook op een aparte SSD, de 2TB mirror en 8TB stripe zijn dus voor andere doeleinden.
Mirror voor mijn kritieke data zoals familie foto's die ik graag wil bewaren en de stripe voor minder belangrijke data zoals films e.d.

Ik ga mij eens verdiepen in SYNC writes.
En misschien had ik te veel verwachtingen van het systeem..

[Paul]

renedis schreef op maandag 30 november 2015 @ 12:25:
En misschien had ik te veel verwachtingen van het systeem..

Als ik het goed heb begrepen is je ZIL is in zoverre een soort 'cache' dat alles wat binnen twee transaction groups (één actieve en eentje die momenteel gecommit wordt) weggeschreven kan worden net zo snel gaat als wat je SLOG aan kan, heb je meer dan wacht ZFS tot de commit klaar is voordat het een nieuwe writes accepteert.

Je bestanden zijn te groot voor je 'cache', en dus ga je niet boven je sustained snelheid uitkomen Één optie is meer vdevs in je pool plaatsen zodat je sneller wegschrijft, of eventueel (maar daarvoor zou ik een uitspraak van iemand die meer van ZFS afweet dan ik afwachten ) gaan spelen met advanced instellingen zoals de lengte van je transaction group zodat je hele bestand erin past.

[FireDrunk]

Weer dezelfde denkfout. Je transactie wordt niet *in* je SLOG gezet, die blijft gewoon in RAM.
Het enige wat ZFS doet is uit die transactiegroep de sync writes ook naar ZIL/SLOG schrijven.

Er wordt nooit van ZIL/SLOG gelezen, *tenzij* je een power failure hebt gehad (om precies te zijn, bij het importeren/mounten van de pool).

Let op dat dat dus RAM is wat naast ARC gebruikt wordt.

[ Voor 10% gewijzigd door FireDrunk op 30-11-2015 13:38 ]

[Paul]

FireDrunk schreef op maandag 30 november 2015 @ 13:37:
Weer dezelfde denkfout

Nee, een andere Maar ik zie dat ik niet heb opgeschreven wat ik precies bedoelde

Klopt het wel dat de transaction group je writecache is? En daarmee de 'aanname' dat je kunt bursten ter grootte van 2 TXG's waarna je beperkt wordt door de achterliggende storage?

[Bigs]

Paul schreef op maandag 30 november 2015 @ 14:02:
[...]
Nee, een andere Maar ik zie dat ik niet heb opgeschreven wat ik precies bedoelde

Klopt het wel dat de transaction group je writecache is? En daarmee de 'aanname' dat je kunt bursten ter grootte van 2 TXG's waarna je beperkt wordt door de achterliggende storage?

Je kunt gewoon niet sneller schrijven dan je achterliggende schijven want er is geen schrijfcache in ZFS. Ik zou er verder niet te veel over nadenken

[Paul]

Waar dient dan de TXG voor? Zowel https://pthree.org/2013/0...izing-the-zfs-intent-log/ als http://louwrentius.com/th...n-building-a-zfs-nas.html geven aan dat dat de writes wel degelijk eerst naar memory gaan en daarna pas naar disk...

[Bigs]

Paul schreef op maandag 30 november 2015 @ 14:16:
Waar dient dan de TXG voor? Zowel https://pthree.org/2013/0...izing-the-zfs-intent-log/ als http://louwrentius.com/th...n-building-a-zfs-nas.html geven aan dat dat de writes wel degelijk eerst naar memory gaan en daarna pas naar disk...

Dat is niet anders dan bij andere filesystems.. met de O_SYNC flag geef je vanuit de software aan dat writes direct naar de disk moeten worden weggeschreven (of RAID controller cache of wat dan ook), de rest blijft hangen tot een flush of een volle buffer. Bij ZFS werkt dat complexer in de vorm van transaction groups, maar het effect is hetzelfde.

_{In het verleden was het zo dat ZFS writes naar de open txg vertraagde tijdens het synchroniseren van de voorgaande txg. De txg grootte werd afgestemd op de hoeveelheid die in 5 seconden weggeschreven kon worden. Ik verwacht dat dit inmiddels nog wel wat verder ontwikkeld is.}

[ Voor 22% gewijzigd door Bigs op 30-11-2015 14:22 ]

[Paul]

Bigs schreef op maandag 30 november 2015 @ 14:19:
de rest blijft hangen tot een flush of een volle buffer.

...dat is toch een write cache of ben ik nu gek?

[InflatableMouse]

Uit een van de linkjes hierboven:

SLOG Performance
Because the SLOG is fast disk, what sort of performance can I expect to see out of my application or system? Well, you will see improved disk latencies, disk utilization and system load. What you won't see is improved throughput. Remember that the SLOG device is still flushing data to platter every 5 seconds. As a result, benchmarking disk after adding a SLOG device doesn't make much sense, unless the goal of the benchmark is to test synchronous disk write latencies. So, I don't have those numbers for you to gravel over. What I do have, however, are a few graphs.

Ben me er ook iets meer aan het verdiepen nu omdat ik dus ook behoorlijk wat misopvattingen had over ZIL. het lijkt me dus meer zoiets als een SQL transaction log, da's ook geen cache.

[ Voor 4% gewijzigd door InflatableMouse op 30-11-2015 14:24 ]

[Bigs]

Paul schreef op maandag 30 november 2015 @ 14:21:
[...]
...dat is toch een write cache of ben ik nu gek?

Zie aanvulling. Het is niet te vergelijken met cache op je RAID controller of in je SAN. Elk bestandssysteem werkt op deze manier en het txg systeem van ZFS is niet sneller dan dat van andere bestandssystemen (al hebben txg's + CoW natuurlijk wel andere voordelen).

[Paul]

Bigs schreef op maandag 30 november 2015 @ 14:24:
Het is niet te vergelijken met cache op je RAID controller of in je SAN.

Waarom niet? Die krijgen ook een write aangeboden en 'liegen' tegen de client dat het is weggeschreven zodat deze verder kan. Dat is wat ZFS bij een niet-synchrone write ook doet...

Elk bestandssysteem werkt op deze manier en het txg systeem van ZFS is niet sneller dan dat van andere bestandssystemen (al hebben txg's + CoW natuurlijk wel andere voordelen).

Niet sneller in de zin MB/sec (theoretisch 12800 MB/sec voor DDR3-1600 waardoor je dus tegen andere limieten aan gaat lopen), maar wel eentje met meer knopjes en schuifjes• waardoor je dus bijvoorbeeld in kunt stellen hoe lang je een TXG open houdt (waardoor er meer MB's in passen) oftewel hoe groot deze is.

Ik ging inderdaad ook uit van "de hoeveelheid data die de achterliggende storage in 5 seconde wegschrijft", als je dat op 6 seconde of 10 seconde zet dan past er dus 20% of 100% meer in je TXG.

*: Dan veel andere

[ Voor 4% gewijzigd door Paul op 30-11-2015 14:57 ]

[Bigs]

Paul schreef op maandag 30 november 2015 @ 14:35:
[...]
Waarom niet? Die krijgen ook een write aangeboden en 'liegen' tegen de client dat het is weggeschreven zodat deze verder kan. Dat is wat ZFS bij een niet-synchrone write ook doet...
[...]
Niet sneller in de zin MB/sec (theoretisch 12800 MB/sec voor DDR3-1600 waardoor je dus tegen andere limieten aan gaat lopen), maar wel eentje met meer knopjes en schuifjes waardoor je dus bijvoorbeeld in kunt stellen hoe lang je een TXG open houdt (waardoor er meer MB's in passen) oftewel hoe groot deze is.

Ik ging inderdaad ook uit van "de hoeveelheid data die de achterliggende storage in 5 seconde wegschrijft", als je dat op 6 seconde of 10 seconde zet dan past er dus 20% of 100% meer in je TXG.

Je kunt het inderdaad verhogen, maar zodra een applicatie een fsync doet worden alle writes weggeschreven en sta je dus toch weer te wachten. Overigens kun je bv. bij ext4 de commit interval ook gewoon aanpassen met een mount optie, dus again: ZFS wijkt hier niet af van de norm

[Paul]

Bigs schreef op maandag 30 november 2015 @ 14:44:
Je kunt het inderdaad verhogen, maar zodra een applicatie een fsync doet worden alle writes weggeschreven en sta je dus toch weer te wachten.

De vraag is hoe vaak dat voorkomt bij renedis

dus again:

Dat weerleg ik ook niet

[FireDrunk]

ZFS kent uiteraard wel een in-memory write cache (dat is inderdaad gewoon je TXG), maar ZIL/SLOG is *geen* write cache. Niet in de meest geaccepteerde betekenis van het woord. Namelijk dat alle writes eerst naar het cache gaan, en daar dan weer uit gelezen worden (wat in RAID controllers het geval is).

Er word (zoals ik boven al zei) nooit van ZIL/SLOG gelezen, tenzij er iets fout gegaan is.

Dat is het fundamentele verschil met RAID controller caches.

ZFS kan dus wel degelijk sneller schrijven dan je disks aan kunnen als je:

A ) ASYNC schrijft.
B ) Je compressie aan hebt staan.
C ) Je dedup aan hebt staan.

[ Voor 4% gewijzigd door FireDrunk op 30-11-2015 15:14 ]

[InflatableMouse]

Het verschil is bizar. Ik heb geen mooie grafiekjes of getalletjes maar heb het twee keer geprobeerd.

Ik heb de log aangemaakt op 4GB op m'n nieuwe SSD en de oude volledig als cache ingezet.

Voorheen als ik meer dan 4 VM's gelijktijdig opstartte ging het stroperig worden, muis soms stotteren en soms zelfs hangen voor meerdere seconden. De disks stonden dan volop koffie te malen. Duurde een eeuwigheid voordat ze gestart waren en responsiveness was vercshrikkelijk. Ik er nu 8 starten, er gaat dan 800MB naar swap ongeveer, ARC_MIN staat op 4GB trouwens. Alles blijft gewoon werken, duurt nog steeds wel effe voordat ze opgestart zijn maar het is sneller, disks zijn hoorbaar minder actief en ze reageren redelijk normaal.

[FireDrunk]

Pas op met zo'n grote L2ARC, dat kan vrij veel geheugen innemen.

Re: [zfs-discuss] ZFS ZIL + L2ARC SSD Setup
http://www.mail-archive.c...solaris.org/msg34674.html

Approximately 200 bytes per record. I use the following example:
Suppose we use a Seagate LP 2 TByte disk for the L2ARC
+ Disk has 3,907,029,168 512 byte sectors, guaranteed
+ Workload uses 8 kByte fixed record size
RAM needed for arc_buf_hdr entries
+ Need = ~(3,907,029,168 - 9,232) * 200 / 16 = ~48 GBytes

200GB is dus 1/10e dus 4.8GB RAM.

[ Voor 81% gewijzigd door FireDrunk op 01-12-2015 08:33 ]

[InflatableMouse]

Daarom heb ik hem 4GB min gegeven, ik zit met 128k record size dus volgens mij heb je dan een stuk minder nodig dan dat voorbeeld.

Dat klopt toch of niet?

[InflatableMouse]

Ik lees nu overigens ook dat de default helemaal niet zo handig is voor random IO workloads. Ik zou denk ik beter naar 8 of 16k kunnen gaan.

Las al dat het "gewoon" is aan te passen met 'zfs set recordsize', maar wat gebeurd er met bestaande data, gaat tie dat dan ook omzetten of hoe werkt dat?

[FireDrunk]

Recordsize mag je alleen zetten bij het aanmaken van een filesystem, daarna is het een readonly property voor zover ik weet.

8K en 16K is inderdaad beter voor VM's, maar de L2ARC geheugen load gaat idd omhoog.

_{Dat geldt ook voor Deduplicatie, daar is 8/16K ook veel beter omdat de kans op een dubbel block hoger is, maar de geheugen footprint gaat wel extreem omhoog}

[InflatableMouse]

Gek genoeg kan je het dus gewoon aanpassen. Het staat nu op 16K. IK ga er dan maar vanuit dat huidige data op 128K staat en alleen nieuwe dingen op 16. Zal er nog es op googlen. Of mischien dat tie het aanpast met en scrub?

Dedup gebruik ik niet met dat als voornaamste reden.

[FireDrunk]

Nee, dan zal het alleen voor nieuwe data gelden. Ik heb een los filesystem voor VMs met een kleinere recordsize.

Als je wil migreren kan dat vrij makkelijk. Gewoon nieuw tijdelijk FS aanmaken en de data heen en weer kopieren.

[InflatableMouse]

Kan ik het niet per bestand checken? Want het zegt nu echt 16K, ook op een filesystem.

[ Voor 22% gewijzigd door InflatableMouse op 01-12-2015 19:59 ]

[FireDrunk]

http://open-zfs.org/wiki/...tuning#Dataset_recordsize

[jacovn]

Freebsd en zfs zijn best wel snel, ik zag met zfs send en receive tussen 2 servers via 10GE ongeveer de scrub snelheid van de pool ook over netwerk gaan.
Daar was niets mis mee

[FireDrunk]

Heb je diezelfde test ook al eens tussen ZFS-on-Linux machines gedaan?

[DRAFTER86]

Misschien bijna offtopic, maar hebben mensen hier ervaring met ZFS VPS'en? Ik zoek een hoster waar ik een paar domeinnamen (LAMP / Mail) kan onderbrengen, maar ik wil ook graag een server waar ik wat mee kan spelen (ZFS target, syncthing, owncloud, dat soort spul).
Transip draait ZFS, maar vraagt al 5,- per snapshot per maand, dat lijkt me nogal overdreven?
Benieuwd wat jullie ervaringen hiermee zijn.

[idef1x]

Je VPS op ZFS zelf installeren misschien? Niet ideaal, maar je kunt dan wel je eigen filesystem snapshotten en lijkt me wel voldoende voor wat je wilt?

jacovn schreef op woensdag 02 december 2015 @ 08:15:
Freebsd en zfs zijn best wel snel, ik zag met zfs send en receive tussen 2 servers via 10GE ongeveer de scrub snelheid van de pool ook over netwerk gaan.
Daar was niets mis mee

Kaal Freebsd of of versie a la ZFSguru, freenas, nas4free?

[ Voor 54% gewijzigd door idef1x op 02-12-2015 08:46 ]

[Compizfox]

DRAFTER86 schreef op woensdag 02 december 2015 @ 08:41:
Transip draait ZFS, maar vraagt al 5,- per snapshot per maand, dat lijkt me nogal overdreven?

Huh, hoe werkt dat dan? Ik zie dat niet echt voor me. Gaan zijn dan in jouw VPS kijken hoeveel snapshots jij hebt gemaakt?

[FireDrunk]

Jouw VM draait *op* ZFS. *in* je VM draai je gewoon je eigen filesystem in je VM.

Zij snapshotten gewoon het filesystem of zvol waar jouw VM op staat.