Het grote ZFS topic

[FireDrunk]

En gewoon history?

history | grep zpool

[Verwijderd]

FireDrunk schreef op maandag 05 oktober 2015 @ 09:18:
Daar heeft het weer weinig mee te maken.
Device tasting geld alleen voor herkenning van wat er daadwerkelijk op de disk staat. Als er geen enkele partitie op staat, valt er weinig te herkennen.

Euh?!

Wat versta jij onder Device Tasting dan?

En geef eens antwoord op de vraag waarom hij dan corrupt data te zien krijgt? Dat is toch precies om de reden dat ZFS een disk voor zijn snufferd krijgt waar de verkeerde data op staat? Dat is iets van het OS; die levert de disk configuratie aan. Bij BSD werkt dat anders dan onder Solaris en Linux. Bij BSD geldt er device tasting.

En ik weet niet wat jij daaronder verstaat, maar ik versta daaronder dat tijdens elke boot, er gekeken wordt naar elke device node - raw disk, partitie, encryptielaag, software RAID laag, HAST laag.... alle GEOM nodes dus. Door te kijken wat er op de device node zelf staat, worden de disks herkend (tasting) en wordt zodoende de ZFS pool configuratie met de juiste disks gepopuleerd. Dan heb je dus geen probleem meer van 'corrupt data' omdat ZFS de verkeerde disk of in de verkeerde volgorde krijgt. En dat is precies wat hier wel aan de hand is.

Dat device tasting alleen voor partities zou gelden, is pure onzin. Probeer hetzelfde maar eens onder BSD. Gewoon wat kabels omwisselen tijdens shutdown en dan weer booten. Pakt BSD prima.

Fijn dat jullie tegenwoordig Linux gebruiken, maar dat neemt niet weg dat BSD zeker wel de superieure ZFS implementatie heeft. En op dit soort gebieden wordt dat maar eens pijnlijk duidelijk. Want je zou als ZoL-gebruiker maar denken dat je pool corrupt is, en dat dit niet meer te herstellen is. Terwijl Linux gewoon een domme static disk configuratie gebruikt waarbij als de volgorde van de disks om één of andere reden verandert - wat zoiets simpels kan zijn als dat je BIOS of HBA firmware dit opnieuw herschikt - je pool opeens UNAVAIL wordt en je CORRUPT DATA te zien krijgt. Gewoon een alpha-kwaliteit implementatie op dit gebied, wat FreeBSD ten tijde van 7.0-CURRENT had waarbij bij elke boot je erop werd gewezen dat ZFS onder FreeBSD nog een experimentele feature was.

WARNING: ZFS is considered to be an experimental feature in FreeBSD.

Maar nee onder Linux is het no production ready hoor! Gaan met die banaan! Net als Ext4 ten tijde van de 'production ready' introductie nog tig corruptiebugs bevatte. Beetje corruptie moet kunnen.

[maomanna]

ik denk dat de hoeveelheid disks atm iets teveel was...

Heb nu

code:

root@centraalpunt:/# zpool status ZFSBulk
  pool: ZFSBulk
 state: UNAVAIL
status: One or more devices could not be used because the label is missing
        or invalid.  There are insufficient replicas for the pool to continue
        functioning.
action: Destroy and re-create the pool from
        a backup source.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        ZFSBulk     UNAVAIL      0     0     0  insufficient replicas
          raidz1-0  UNAVAIL      0     0     0  insufficient replicas
            sdb     UNAVAIL      0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdg     UNAVAIL      0     0     0  corrupted data
            sdh     UNAVAIL      0     0     0  corrupted data

Dat is al wat beter.

Echter heb ik met export het volgende:

code:

root@centraalpunt:/# zpool export ZFSBulk
cannot export 'ZFSBulk': invalid argument for this pool operation

de zpool export datapool werkt wel prima.

Ja hoor, super vaag. Dit bovenstaande is gedaan met SSH.
Het werkte niet kreeg die melding.

Boot ik hem met mijn usb stick alleen ingeplugged, dus zonder daar vanaf te starten, en hij heeft mn ZFSbulk dus toch geexporteerd.
Het simpele commando van importeren en alles is weer online...

Schiet mij maar lek.

[ Voor 11% gewijzigd door maomanna op 05-10-2015 22:03 ]

[dcm360]

Verwijderd schreef op maandag 05 oktober 2015 @ 21:03:
[...]
Dat device tasting alleen voor partities zou gelden, is pure onzin. Probeer hetzelfde maar eens onder BSD. Gewoon wat kabels omwisselen tijdens shutdown en dan weer booten. Pakt BSD prima.

Mijn Linux systeem doet het ook nog prima als ik wat (virtuele) kabels omprik. Moet je natuurlijk niet geprutst hebben met de oorspronkelijke configuratie, als je bij BSD tijdens de configuratie hard genoeg prutst kan je het vast ook wel stuk krijgen bij het omprikken van kabels.

[Verwijderd]

dcm360 schreef op maandag 05 oktober 2015 @ 22:22:
Mijn Linux systeem doet het ook nog prima als ik wat (virtuele) kabels omprik. Moet je natuurlijk niet geprutst hebben met de oorspronkelijke configuratie

Wat bedoel je met 'prutsen met de oorspronkelijke configuratie' ?

En verklaar dan waarom er 'corrupt data' te zien is? Zullen we wedden dat als hij die pool onder BSD boot, hij gewoon een goede pool te zien krijgt? Zo ja, heeft het toch alles mee te maken dat BSD wél tijdens elke boot elke device proeft om te kijken in welke volgorde hij bij welke pool hoort, en dat dit bij Linux niet gebeurt?!

als je bij BSD tijdens de configuratie hard genoeg prutst kan je het vast ook wel stuk krijgen bij het omprikken van kabels.

Mijn punt is dus dat dat niet zou kunnen. Dat was alleen het geval in de begindagen van ZFS op FreeBSD, waarbij ZFS nog een experimentele feature was en nog alpha-kwaliteit. Diezelfde kwaliteit wordt op Linux afgedaan als productie-kwaliteit, wat mijns inziens gewoon een leugen is.

Prima als mensen voor Linux kiezen omdat ze daar goede argumenten voor hebben. Maar ZFS is eigenlijk alleen production ready op BSD en op commerciële Solaris distributies. Zelfs op OpenSolaris (SmartOS) is het kielekiele - laatst de L2ARC corruptiebug is niet alleen in stabiele releases terecht gekomen, maar zelfs in LongTermRelease versies. Komop zeg! Bij BSD is die alleen bij -CURRENT gekomen en niet de rolling release -STABLE en ook geen gewone releases -RELEASE en al helemaal geen long term releases (extended support). Dat zijn gewoon verschillen. ZFS heeft onder BSD heel veel liefde gekregen en is al geruime tijd volwassen geworden; dat proces is bij Linux nog in volle gang.

Bovendien heeft BSD de beschikking over GEOM en dat werpt gewoon zijn vruchten af.

[dcm360]

Verwijderd schreef op maandag 05 oktober 2015 @ 23:03:
[...]

Wat bedoel je met 'prutsen met de oorspronkelijke configuratie' ?

En verklaar dan waarom er 'corrupt data' te zien is? Zullen we wedden dat als hij die pool onder BSD boot, hij gewoon een goede pool te zien krijgt? Zo ja, heeft het toch alles mee te maken dat BSD wél tijdens elke boot elke device proeft om te kijken in welke volgorde hij bij welke pool hoort, en dat dit bij Linux niet gebeurt?!

'Prutsen met de oorspronkelijke configuratie' als in een configuratie maken die niet aanbevolen wordt door de documentatie van ZoL. En zoals ik al zei, op mijn Linux-systeem maakt de volgorde van de schijven niet uit, dus het zou prima kunnen dat als je zijn schijven aan een vergelijkbaar systeem als de mijne hangt en de pool importeert dat het dan ook gaat werken. Je wint de weddenschap pas als dat niet zou werken en BSD wel.

Overigens denk ik dat ZoL een leuke tussenstap is, maar dat het over enkele jaren achterhaald geraakt is door het volwassen worden van BTRFS. Voor thuisgebruikers bevat ZFS enkele ernstige beperkingen die BTRFS niet heeft, en voor simpele configuraties is die laatste onderhand al stabiel genoeg (fun fact: mijn installaties met ZoL booten al van BTRFS).

Daarnaast begint er bij mij steeds hardnekkiger de indruk te ontstaan dat jouw kennis van ZoL en Linux enigszins beperkt is, waardoor er naar mijn idee te vaak Linux versus BSD discussies ontstaan

[Verwijderd]

dcm360 schreef op maandag 05 oktober 2015 @ 23:36:
'Prutsen met de oorspronkelijke configuratie' als in een configuratie maken die niet aanbevolen wordt door de documentatie van ZoL.

Kortom, je moet de ZFS pool maken op de manier waarbij deze voor ZoL de minste beperkingen of hiaten heeft. Dat doet af aan het feit dat ZFS een cross-platform filesystem is - juist één van de grootste voordelen van dit filesystem wat Btrfs en ReFS nooit zullen krijgen.

En zoals ik al zei, op mijn Linux-systeem maakt de volgorde van de schijven niet uit

Wat heb je exact getest dan?

Overigens denk ik dat ZoL een leuke tussenstap is, maar dat het over enkele jaren achterhaald geraakt is door het volwassen worden van BTRFS. Voor thuisgebruikers bevat ZFS enkele ernstige beperkingen die BTRFS niet heeft

Dan gaat het om het kunnen uitbreiden van bestaande RAID-Z1/2/3 vdevs neem ik aan, zoals bij ZFS al wel kan met stripe en mirrors, maar niet met parity vdevs. Dat is inderdaad een 'voordeel' van Btrfs - alhoewel ik heb gewaarschuwd voor de complexiteit om zo'n feature veilig uit te voeren en dat bij het tegenkomen van bad sectors of andere ongein tijdens zo'n omspit-procedure er nog leuke bugs uit kunnen rollen.

Maar Btrfs zal ook beperkingen hebben die waarschijnlijk nooit meer weggaan. Zo is door de GPL-licentie het porten van dit filesystem naar andere platforms zoals Solaris, BSD, Apple OSX, en Microsoft zeer waarschijnlijk geen optie. Of het moet ook houtje touwtje via FUSE wat gewoon onwenselijk is. Dus krijgen we straks de situatie dat ieder platform zijn eigen filesystem heeft, en alleen filesystems uit de prehistorie zoals FAT echt goed cross-platform werken; want zelfs bij het immens populaire NTFS is dit thans niet het geval.

Voorts verwacht ik dat het 'volwassen raken' van Btrfs ongeveer op dezelfde manier zal gaan als Ext4: het gewoon gewoon default gemaakt en gezegd 'jongens het is stabiel!' en dus gaan mensen het gebruiken. Vervolgens blijkt dat het allemaal helemaal niet zo superstabiel is en er ernstige (corruptie-)bugs in worden gevonden. Maar ach geen probleem, we fixen dat snel even met updates. Ondertussen zijn je bestanden op het zogenaamd superveilige next-gen filesystem wel corrupt geraakt; maar daar praat straks niemand meer over, toch?

en voor simpele configuraties is die laatste onderhand al stabiel genoeg

Ja dat was ZFS versie 1 ook al. En tel eens even de corruptiebugs die er sindsdien zijn geweest. Ik weet niet of die überhaupt door iemand worden bijgehouden, maar ik kan je verzekeren dat onder BSD die pas vanaf versie 6 begon en pas bij versie 14 als stabiel kenmerkte, het er flink wat zijn geweest. Inderdaad, sommige zijn zeer obscuur. Maar anderen weer niet. Dat de L2ARC corruptiebug hele pools heeft verwoest op SmartOS en dan nog wel de extra stabiele LTS releases - enkele maanden geleden - is jullie vast ontgaan. 'Stabiel genoeg' is een enorm rekbaar begrip.

Daarnaast begint er bij mij steeds hardnekkiger de indruk te ontstaan dat jouw kennis van ZoL en Linux enigszins beperkt is

Dat is zeker zo. Neemt niet weg dat mijn argument dat de verschillen tussen ZFS op BSD en ZFS op Linux in mijn ogen gebagatelliseerd worden, best wel eens waar zou kunnen zijn.

[dcm360]

Verwijderd schreef op dinsdag 06 oktober 2015 @ 00:18:
[...]

Kortom, je moet de ZFS pool maken op de manier waarbij deze voor ZoL de minste beperkingen of hiaten heeft. Dat doet af aan het feit dat ZFS een cross-platform filesystem is - juist één van de grootste voordelen van dit filesystem wat Btrfs en ReFS nooit zullen krijgen.

Is het raar om een filesystem in te richten zodat het optimaal werkt voor een platform? Ik vind van niet - zo goed als alle schijven die ik heb krijgen een bestandsysteem dat past bij het systeem waar deze in gaat, ingericht zodat het systeem er het maximale uit kan halen (of: de minste beperkingen of hiaten heeft als je het graag negatief verwoord). Daarbij is ZFS bij lange na niet geheel cross-platform (en zal het ook niet worden): ik acht de kans klein dat als ik een externe HDD met ZFS inricht dat ik die ooit fatsoenlijk ga kunnen openen op een Windows-systeem.

Naar mijn idee is een echt cross-platform filesystem ook niet noodzakelijk: je kiest voor de storage een geschikt bestandsysteem, en vervolgens kan je met SMB, NFS of iSCSI er bij vanaf een systeem naar keuze. Het is tot op zekere hoogte irrelevant of daar dan FAT, NTFS, ZFS, BRTFS, Ext, ReiserFS of wat anders onder ligt.

Wat heb je exact getest dan?

Bij het plaatsen van enkele nieuwe schijven heb ik de disk-configuratie in de hypervisor aangepast, wat als gevolg had dat de OS-disk nu ineens /dev/sdf is in plaats van sda, en een schijf uit mijn al bestaande pool had sda gekregen. Uiteraard geen issue vanwege het gebruik van /dev/disk/by-id/ bij het aanmaken van de pool.

Dan gaat het om het kunnen uitbreiden van bestaande RAID-Z1/2/3 vdevs neem ik aan, zoals bij ZFS al wel kan met stripe en mirrors, maar niet met parity vdevs. Dat is inderdaad een 'voordeel' van Btrfs - alhoewel ik heb gewaarschuwd voor de complexiteit om zo'n feature veilig uit te voeren en dat bij het tegenkomen van bad sectors of andere ongein tijdens zo'n omspit-procedure er nog leuke bugs uit kunnen rollen.

Bijvoorbeeld ja. Beetje geval lood om oud ijzer - 'het kan niet' versus 'er zitten risico's aan'.

Maar Btrfs zal ook beperkingen hebben die waarschijnlijk nooit meer weggaan. Zo is door de GPL-licentie het porten van dit filesystem naar andere platforms zoals Solaris, BSD, Apple OSX, en Microsoft zeer waarschijnlijk geen optie. Of het moet ook houtje touwtje via FUSE wat gewoon onwenselijk is. Dus krijgen we straks de situatie dat ieder platform zijn eigen filesystem heeft, en alleen filesystems uit de prehistorie zoals FAT echt goed cross-platform werken; want zelfs bij het immens populaire NTFS is dit thans niet het geval.

Ik denk dan ook dat cross-platform filesystems niet nodig zijn, misschien met UDF als uitzondering. Zie ook eerder in deze reactie

Voorts verwacht ik dat het 'volwassen raken' van Btrfs ongeveer op dezelfde manier zal gaan als Ext4: het gewoon gewoon default gemaakt en gezegd 'jongens het is stabiel!' en dus gaan mensen het gebruiken. Vervolgens blijkt dat het allemaal helemaal niet zo superstabiel is en er ernstige (corruptie-)bugs in worden gevonden. Maar ach geen probleem, we fixen dat snel even met updates. Ondertussen zijn je bestanden op het zogenaamd superveilige next-gen filesystem wel corrupt geraakt; maar daar praat straks niemand meer over, toch?

En ondertussen raakt data op ZFS niet meer corrupt natuurlijk

Dat is zeker zo. Neemt niet weg dat mijn argument dat de verschillen tussen ZFS op BSD en ZFS op Linux in mijn ogen gebagatelliseerd worden, best wel eens waar zou kunnen zijn.

Verschillen zal ik niet kunnen ontkennen - immers is BSD nu eenmaal anders dan Linux. Bij de een zullen keuzes gemaakt worden die voor de ander buiten discussie staan. Dat is dan ook precies de reden waarom ik denk dat BTRFS op termijn de betere keuze gaat zijn voor Linux-systemen: de filosofie sluit beter aan.
Mijn eigenlijke punt was echter meer dat ik vind dat je iets te snel zegt dat BSD het probleem oplost (naar mijn idee vaak gevolgd door een tekst waar op wikipedia zo af en toe een [citation needed] in thuis zou horen).

[Verwijderd]

dcm360 schreef op dinsdag 06 oktober 2015 @ 01:21:
Is het raar om een filesystem in te richten zodat het optimaal werkt voor een platform?

Ik vind het inderdaad wel raar dat een ZFS pool die op bepaalde devices nodes (wel of geen partities) gemaakt is, niet meer lekker werkt op het andere platform. Dat doet af aan het op één na grootste voordeel wat ZFS heeft: cross-platform. En nee, cross-platform betekent niet dat het op alle operating systems sinds het stenen tijdperk draait, maar dat het op meerdere platforms draait. ReFS zal alleen op Microsoft draaien, Btrfs alleen op Linux maar ZFS draait op alle grote platforms behalve Microsoft. Dat is een enorm groot voordeel wat door deze beperking enigszins wordt gemarginaliseerd. Dat is jammer.

Bovendien wordt het hier veelal ontkent dat dit nadeel of deze beperking er is. Device tasting is iets wat ik vaker heb genoemd, maar wordt veelal ontkent dat dit onder Linux niet zo werkt als onder BSD, en dan zeg ik het nog voorzichtig. Een hele pool als corrupt aanmerken is niet iets wat je als gebruiker wilt zien. Bedenk dat er gebruikers zijn die denken dat hun pool naar zijn grootje is en de pool helemaal opnieuw aanmaakt. Iets wat achteraf dus onnodig lijkt te zijn. Overigens had ik bij FreeBSD in de begindagen exact hetzelfde en ook ik heb de pool maar opnieuw aangemaakt. Zal wel een foutje in ZFS zitten want immers: het is nog lang niet stabiel en 'experimenteel' - was zelfs in de tijd dat het nog niet in 7-CURRENT was opgenomen en je met patches moest werken. Toen was er dus ook geen device tasting en werd alles static uit een zpool.cache file getrokken. Datzelfde lijkt - lijkt want ik weet niks zeker - het geval te zijn bij Linux. Daar wilde ik even op wijzen. Dat lijkt me relevant voor deze draad.

Naar mijn idee is een echt cross-platform filesystem ook niet noodzakelijk: je kiest voor de storage een geschikt bestandsysteem, en vervolgens kan je met SMB, NFS

Dat je filesystem kunt delen over het netwerk is hier niet de issue. Het gaat erom dat je bij ZFS keuze hebt. Als je bij Solaris een probleem hebt met hardware compatibiliteit, kun je uitwijken naar andere platforms. Als je bij Linux tegen problemen aanloopt - zoals het door mij aangestipte probleem - kun je naar BSD uitwijken al is het maar om je pool weer op orde te krijgen zodat deze weer in ZoL werkt. Die keuzevrijheid is een belangrijk goed vind ik. Juist met OpenZFS is getracht die cross-platform functionaliteit te behouden en niet zoals Oracle doet zijn eigen weg in te gaan met closed source functionaliteit zodat een Oracle ZFS niet meer compatible is met een distributie die op OpenZFS is gebaseerd.

Met hetzelfde argument dat jij geeft kunnen we ZFS en Btrfs wel afschaffen omdat je Microsoft ReFS ook kunt delen over het netwerk en dus Linux/BSD allemaal ReFS laten gebruiken. Dat is natuurlijk geen steekhoudend argument.

Bij het plaatsen van enkele nieuwe schijven heb ik de disk-configuratie in de hypervisor aangepast, wat als gevolg had dat de OS-disk nu ineens /dev/sdf is in plaats van sda, en een schijf uit mijn al bestaande pool had sda gekregen. Uiteraard geen issue vanwege het gebruik van /dev/disk/by-id/ bij het aanmaken van de pool.

Dus, de informatie in de zpool.cache (disk/by-id) is ongewijzigd gebleven, dus dat betekent dat het punt dat ik probeer te maken hoogstwaarschijnlijk gewoon klopt. Als de devicenode wijzigt - zoals ZFS die onthouden heeft - heb je onder Linux een corrupte pool. Althans, die melding krijg je. Lekker dan.

En ondertussen raakt data op ZFS niet meer corrupt natuurlijk

Nee, niet in de praktijk onder BSD. Althans ik heb er geen/nauwelijks berichten over gezien in de mailinglists die ik bijhoud. Een enkele keer een paar jaar geleden las je nog wel iets over mensen die hun ZFS op Areca hardware RAID draaide met onveilige write-back. Dan gaat ZFS op zijn bek. Maar dat is geen bug en dat gaat ook nooit opgelost worden.

Het punt is natuurlijk dat ZFS op BSD platform al jarenlang volwassen geworden is en een veel langer traject heeft afgelegd dan ZoL. ZFS onder Linux moet diezelfde lange weg nog afleggen en tegen de tijd dat dat is voltooid en ZoL ongeveer op het niveau is als ZFS onder BSD nu, dan zijn we al zoveel verder dat Btrfs het stokje over zal nemen. En dan keren we terug naar het donkere tijdperk waarbij je als het ware een vendor lock-in hebt omdat ieder platform zijn eigen oplossing pusht. ZFS onder Linux zal dan veel minder aandacht krijgen omdat de massa inmiddels over is naar Btrfs, en zo zullen wij gebruikers min of meer gedwongen worden om te blijven bij een bepaald platform (Microsoft - Linux - BSD) zonder gemakkelijk te kunnen switchen met behoud van je storage pool. Dat acht ik als zeer onwenselijk maar is desondanks zeer waarschijnlijk wat gaat gebeuren.

Mijn eigenlijke punt was echter meer dat ik vind dat je iets te snel zegt dat BSD het probleem oplost (naar mijn idee vaak gevolgd door een tekst waar op wikipedia zo af en toe een [citation needed] in thuis zou horen).

Ja maar een forum is geen encyclopedie. Wat ik zeg zijn ook geen feiten van het Orakel - pun intended.

Dit forum dient ervoor om kennis en inzichten uit te wisselen. Dat geldt ook voor mijzelf; het is geen eenrichtingsverkeer. Ik leer ook van jullie.

[dcm360]

Verwijderd schreef op dinsdag 06 oktober 2015 @ 01:45:
[...]

Ik vind het inderdaad wel raar dat een ZFS pool die op bepaalde devices nodes (wel of geen partities) gemaakt is, niet meer lekker werkt op het andere platform.

Volgens mij is dit geen verschil die de verandering van OS onhandig maakt? Ik dacht dat het verschil hierin met name bij het aanmaken van de pool zat en verder niet uitmaakte. Corrigeer me gerust als ik dit verkeerd blijk te denken

Dat je filesystem kunt delen over het netwerk is hier niet de issue. Het gaat erom dat je bij ZFS keuze hebt. Als je bij Solaris een probleem hebt met hardware compatibiliteit, kun je uitwijken naar andere platforms. Als je bij Linux tegen problemen aanloopt - zoals het door mij aangestipte probleem - kun je naar BSD uitwijken al is het maar om je pool weer op orde te krijgen zodat deze weer in ZoL werkt. Die keuzevrijheid is een belangrijk goed vind ik. Juist met OpenZFS is getracht die cross-platform functionaliteit te behouden en niet zoals Oracle doet zijn eigen weg in te gaan met closed source functionaliteit zodat een Oracle ZFS niet meer compatible is met een distributie die op OpenZFS is gebaseerd.

Voor mij weegt dat dan wat minder zwaar dan voor jou. Ik zou zelfs meer de richting uit gaan dat een ander platform gaan gebruiken om problemen op te lossen ook problemen kan introduceren vanwege implementatieverschillen, en het daarom waar mogelijk afraden. Hangt er ook maar net van af wat je zwaarder vind wegen.

Met hetzelfde argument dat jij geeft kunnen we ZFS en Btrfs wel afschaffen omdat je Microsoft ReFS ook kunt delen over het netwerk en dus Linux/BSD allemaal ReFS laten gebruiken. Dat is natuurlijk geen steekhoudend argument.

Dit is dan ook een verdraaiing van mijn argument. Ik vind niet dat er 1 filesystem moet zijn, ik vind dat er per platform een (modern) filesystem beschikbaar moet zijn welke aansluit bij de filosofie van het platform. Het sluit niet per se uit dat een filesystem beschikbaar is op meerdere platformen. Meerdere filesystems biedt juist de vrijheid om te kiezen voor een filesystem/platform-combinatie die het beste aansluit bij jouw eisen en wensen, en vervolgens kan er middels een abstractielaag bovenop de storage ook gekozen worden voor het platform dat het beste aansluit bij de eisen en wensen voor een client. Combineer en heers

[...]

Dus, de informatie in de zpool.cache (disk/by-id) is ongewijzigd gebleven, dus dat betekent dat het punt dat ik probeer te maken hoogstwaarschijnlijk gewoon klopt. Als de devicenode wijzigt - zoals ZFS die onthouden heeft - heb je onder Linux een corrupte pool. Althans, die melding krijg je. Lekker dan.

Dat zou inderdaad het geval kunnen zijn, maar aangezien ik de aanbevolen methode voor het aanmaken van mijn pool heb gebruikt is het geen issue. Oftewel: lees de documentatie en maak aan de hand daarvan een keuze. De aanbevolen methode zorgt er voor dat ik zonder problemen mijn schijven kan wisselen tussen controllers en poorten daarop. Het gebruiken van een afgeraden methode kan inderdaad wat meer issues opleveren, die waarschijnlijk wel te verhelpen zijn met een beetje moeite.

[...]

Nee, niet in de praktijk onder BSD. Althans ik heb er geen/nauwelijks berichten over gezien in de mailinglists die ik bijhoud. Een enkele keer een paar jaar geleden las je nog wel iets over mensen die hun ZFS op Areca hardware RAID draaide met onveilige write-back. Dan gaat ZFS op zijn bek. Maar dat is geen bug en dat gaat ook nooit opgelost worden.

Het punt is natuurlijk dat ZFS op BSD platform al jarenlang volwassen geworden is en een veel langer traject heeft afgelegd dan ZoL. ZFS onder Linux moet diezelfde lange weg nog afleggen en tegen de tijd dat dat is voltooid en ZoL ongeveer op het niveau is als ZFS onder BSD nu, dan zijn we al zoveel verder dat Btrfs het stokje over zal nemen. En dan keren we terug naar het donkere tijdperk waarbij je als het ware een vendor lock-in hebt omdat ieder platform zijn eigen oplossing pusht. ZFS onder Linux zal dan veel minder aandacht krijgen omdat de massa inmiddels over is naar Btrfs, en zo zullen wij gebruikers min of meer gedwongen worden om te blijven bij een bepaald platform (Microsoft - Linux - BSD) zonder gemakkelijk te kunnen switchen met behoud van je storage pool. Dat acht ik als zeer onwenselijk maar is desondanks zeer waarschijnlijk wat gaat gebeuren.

Ik zit er niet zo mee dat ik mijn storage pool niet mee kan nemen naar een ander platform. Waar ik meer mee zit is dat het lastig is om van filesystem te veranderen zonder daarbij informatie te verliezen. Ik acht de kans namelijk vrij klein dat ik de keuze ga maken om mijn storage op BSD te gaan draaien, maar ik zie het wel gebeuren dat ik binnen enkele jaren ZFS wil vervangen met BTRFS. Of ik vind over enkele jaren dat ik er nu helemaal naast zit, dat kan ook nog natuurlijk... Dat sluit wel weer mooi aan bij het einde van jouw post:

[...]

Ja maar een forum is geen encyclopedie. Wat ik zeg zijn ook geen feiten van het Orakel - pun intended.

Dit forum dient ervoor om kennis en inzichten uit te wisselen. Dat geldt ook voor mijzelf; het is geen eenrichtingsverkeer. Ik leer ook van jullie.

[maomanna]

Kan iemand mijn ervaring verklaren? of heeft iemand een soort gelijk iets meegemaakt?

Ik blijf het namelijk wel vreemd vinden.

[Q]

Verwijderd schreef op maandag 05 oktober 2015 @ 21:03:
Fijn dat jullie tegenwoordig Linux gebruiken, maar dat neemt niet weg dat BSD zeker wel de superieure ZFS implementatie heeft. En op dit soort gebieden wordt dat maar eens pijnlijk duidelijk. Want je zou als ZoL-gebruiker maar denken dat je pool corrupt is, en dat dit niet meer te herstellen is. Terwijl Linux gewoon een domme static disk configuratie gebruikt waarbij als de volgorde van de disks om één of andere reden verandert - wat zoiets simpels kan zijn als dat je BIOS of HBA firmware dit opnieuw herschikt - je pool opeens UNAVAIL wordt en je CORRUPT DATA te zien krijgt. Gewoon een alpha-kwaliteit implementatie op dit gebied, wat FreeBSD ten tijde van 7.0-CURRENT had waarbij bij elke boot je erop werd gewezen dat ZFS onder FreeBSD nog een experimentele feature was.

WARNING: ZFS is considered to be an experimental feature in FreeBSD.

Maar nee onder Linux is het no production ready hoor! Gaan met die banaan! Net als Ext4 ten tijde van de 'production ready' introductie nog tig corruptiebugs bevatte. Beetje corruptie moet kunnen.

Het enige probleem is hier dat mensen de ZoL instructies niet volgen. Dat je geen /dev/sd? moet gebruiken voor je devices in de pool staat er glashelder in, de waarschuwing is duidelijk.

Deze rant jegens Linux vs FreeBSD vind ik overdreven. Heeft niets met alpha-kwaliteit te maken.

Onder linux is het altijd zo geweest dat /dev/sdx niet gegarandeerd naar het zelfde device wijst en daarom werk je ook met bijvoorbeeld uuid's of labels. Ik gebruik zelf /dev/disk/by-id/wwn*

Het kan best zijn dat FreeBSD de 'betere' ZFS-implementatie heeft, maar ZoL is goed genoeg. Er is geen reden om denigrerend te doen over ZoL in mijn optiek.

[DXaroth]

Overigens vind Ubuntu ZoL al mature genoeg om meegescheept te gaan worden:

https://lists.ubuntu.com/.../2015-October/000370.html

[Bigs]

DXaroth schreef op woensdag 07 oktober 2015 @ 10:50:
Overigens vind Ubuntu ZoL al mature genoeg om meegescheept te gaan worden:

https://lists.ubuntu.com/.../2015-October/000370.html

'in due course' betekent volgens mij 'op termijn'. Het is dus nog niet zo ver.

[FireDrunk]

Zojuist mijn eerste testje op BSD gedaan met het wisselen van 'kabels' (virtueel gedaan, maar zelfde effect)...

Voorlopige conclusie:

BSD blijft inderdaad keurig werken. Als je een pool aanmaakt via /dev/ada1 /dev/ada2 en je verwisselt daarna disks van plek met bijvoorbeeld een /dev/ada3 blijft het geheel werken.

Waarom? BSD valt terug op /dev/diskid/. De /boot/zfs/zpool.cache file wordt bij de eerstvolgende reboot gewoon genegeerd. BSD kijkt zelf welke disk een pool vormen uit alle mogelijke kanalen.

Ik kan helaas niet in BSD de /dev/diskid/ labels uitzetten, maar mijn verwachting is dat BSD de pool nooit corrupt zou importeren zoals Linux dus wel doet.

De root-cause is (denk ik) dat BSD de zpoo.cache file negeert, en het zelf (terecht) 'beter weet'.
Linux gaat stricter om met die file, en probeert de pool te mounten met de devices die daar in staan, en laat daarna zelf ZFS beslissen of de pool intact is.

Ik zal eens kijken welke code ZFSonLinux hiervoor gebruikt, en misschien eens voorstellen om het gedrag van BSD hierin te volgen.

[begintmeta]

FireDrunk schreef op woensdag 07 oktober 2015 @ 13:57:
... Ik kan helaas niet in BSD de /dev/diskid/ labels uitzetten...

Is daar geen 'kern.geom.label.*.enable' variabele voor? (b.v. 'kern.geom.label.disk_ident.enable')

[ Voor 74% gewijzigd door begintmeta op 07-10-2015 14:13 ]

[FireDrunk]

Ja, al geprobeerd, gpt.enable="0" en gptid.enable="0" heb ik geloof ik.

[begintmeta]

Als je 10 draait misschien ook nog eens *.disk_ident.enable proberen te zetten.

[FireDrunk]

Die werkt inderdaad wel, maar BSD blijft keurig de goede disks importeren. Precies het gedrag wat je zou willen

Kudo's voor BSD!

Heb een issue aangemaakt @ZFSonLinux Github

De code waar het om gaat in ZFS on Linux:

code:

char *
zpool_default_import_path[DEFAULT_IMPORT_PATH_SIZE] = {
    "/dev/disk/by-vdev",    /* Custom rules, use first if they exist */
    "/dev/mapper",      /* Use multipath devices before components */
    "/dev/disk/by-uuid",    /* Single unique entry and persistent */
    "/dev/disk/by-id",  /* May be multiple entries and persistent */
    "/dev/disk/by-path",    /* Encodes physical location and persistent */
    "/dev/disk/by-label",   /* Custom persistent labels */
    "/dev"          /* UNSAFE device names will change */
};

Misschien eens voorstellen om /dev helemaal te schrappen.

[ Voor 78% gewijzigd door FireDrunk op 07-10-2015 15:45 ]

[Blazer Coke]

Hoi Allen,

Ik heb momenteel een 2GB NAS in mirror mode (RAID 1), maar deze begint nu bijna vol te raken.
Ik ben dan ook op zoek naar een nieuwe NAS server.

Al browsende op tweakers kwam ik het topic over ZFS tegen.
Het idee achter ZFS, met self-healing data, snapshots en alle andere voordelen spreekt me erg aan.

Ik ben echter geen hardcore tweaker meer en vraag me dan ook af of een zfs server me niet teveel werk/gedoe wordt. Ik kan zelf mijn systemen bouwen/assembleren/installeren. Ik gebruik linux op mijn laptop en speel wat met een pi, maar veel stelt het allemaal niet voor.

Het voordeel van een NAS is dat je er zeer weinig aandacht aan hoeft te besteden. Af en toe de firmware/software updaten en that's it. De rest kun je gemakkelijk regelen in de grafische NAS-software.
Het nadeel is dan dat ik graag sommige functies zou willen gebruiken die op mijn huidige NAS niet zitten. Het is echter een vrij goedkope NAS (een of andere internetdeal geloof ik), dus een geavanceerdere NAS zou wellicht al veel kunnen helpen hiervoor.

Het gebruikersgemak, eenvoud en weinig werk eraan hebben zijn voor mij erg belangrijk.
Ik wil dan ook (voor het overgrote deel) in een grafische omgeving werken.
Prijs is wat van ondergeschikt belang, maar ik heb niet het idee dat een ZFS server duurder is dan een goede NAS..
Wat ik echter wel zeer belangrijk vind zijn betrouwbaarheid en stabiliteit. Snelheid ed intereseert me niet zo.
Als ik het eenmaal geinstalleerd en geconfigureerd heb, wil ik er echter wel mee klaar zijn (op wat kleine updates na).

Ik zou dan bijv 4x4GB in ZFS2/RAID6 willen draaien, waardoor ik 8 GB heb, wat voor de komende jaren ruim genoeg moet zijn.
Het is vooral voor de opslag van personlijke zaken, foto's, video's, muziek, software ed.
Verder zou ik wel een kleine server willen draaien voor FTP bijvoorbeeld.
Handige tools voor downloaden en allerlei management tools kan ik altijd erg waarderen.

Ik vraag me nu af of een ZFS server als NAS voor mij wel geschikt is.

Is het te doen om een ZFS server te laten draaien met weinig moeite/onderhoud?
Zijn er softwarepakketten die volledig grafisch zijn en zeer gebruiksvriendelijk en zeer betrouwbaar/stabiel zijn?
Of raden jullie aan om toch maar een (geavanceerde) NAS aan te schaffen?
Zit er qua functionaliteit nog veel verschil in de diverse OS-en voor mijn eisen?

Ik hoor graag jullie mening/advies.

[Verwijderd]

@Blazer Coke

Een ZFS NAS biedt je heel veel voordelen. Behalve de betrouwbaarheid en zekerheid die je je data geeft, die min of meer het beste ter wereld is op dit ogenblik, heb je ook voordelen op andere gebieden. Zo geeft ZFS je juist datgene wat jij noemt: weinig omkijken naar. ZFS repareert zichzelf en je hoeft er niets aan te doen. Geen disk checks, geen mount problemen, geen gezeik. ZFS regelt zichzelf. Uiteraard moet je wel ingrijpen als een disk uitvalt, daar kan geen enkel filesystem je volledig automatisch bij helpen. Je kunt wel hot spares gebruiken maar voor een thuisgebruiker is dat veelal overkill. Zo vaak komt het niet voor. Bad sectors en dergelijke heb je eigenlijk geen omkijken meer naar - het kan hooguit je NAS een keer vertragen maar dat is dan tijdelijk.

Dus dat Als ik het eenmaal geinstalleerd en geconfigureerd heb, wil ik er echter wel mee klaar zijn gaat wel goed komen denk ik. Mits je de ZFS NAS niet benaderbaar maakt voor kwaadwillenden (lees: het internet) - want dan zou je regelmatig en zelfs bijna dagelijks met security updates moeten werken en dat verandert de zaak. Daarvoor zou je dan beter een ander systeem kunnen nemen.

4 disks in RAID-Z2 kan prima, maar ik neem aan dat je 4TB bedoelt en niet 4GB.

Je aanname dat een ZFS NAS duurder is dan een goede kant-en-klare NAS is onterecht - het is juist precies andersom. Een ZFS NAS kost je maar de helft en daarvoor krijg je nog 2x zo betere hardware voor terug. Dus qua prijs/prestatie/kwaliteit-verhouding zou je een factor 4 kunnen rekenen. Kant en klare NAS systemen gebruiken bijna altijd ARM chips die zeg maar ook op je SmartPhone en SmartWatch draaien - dat zijn enorm simpele chips en daar betaal je dan de hoofdprijs voor. Je betaalt dan ook vooral voor het merk en de software en niet zozeer voor de hardware daar maken de NAS bouwers juist enorm veel marge op. Bij ZFS investeer je meer tijd en moeite in het bouwen van het systeem, maar zit de winst hem erin dat je veel geld bespaart en veel geavanceerdere technologie kunt benutten die jouw data enterprise-class bescherming (errorcorrectie) en zekerheid (errordetectie) kunnen geven.

De specifieke NAS distributies verschillen behoorlijk in features en toegankelijkheid. FreeNAS heeft veel enterprise/zakelijke features maar wordt door niet iedereen als gebruiksvriendelijk ervaren. Aan de andere kant van het spectrum is ZFSguru nog onvolwassen en niet uitontwikkeld en mist het veel features die FreeNAS wel heeft, maar is het wel veel laagdrempeliger, vereist het minder kennis en is de interface eenvoudiger in opzet wat juist nieuwe gebruikers kan aanspreken. Mijn advies is om de NAS distributies, inclusies NAS4Free wat er tussenin zit, uit te proberen in een Virtualbox instance. Zo kun je zelf ervaren wat voor jou het fijnste werkt.

Let wel, je hebt het over grafische interface. Behalve ZFSguru bieden geen van de NAS distributies dit. Bijna alles is web-interface. Maar ik neem aan dat dit ook min of meer is wat je bedoelt. De web-interface kun je gewoon vanaf je browser of zelfs smartphone bedienen. Zo hoef je niet op de command line/shell te werken wat voor beginners een te grote drempel is.

Zo lang je geen extra dingen wilt zoals addon software, kunnen alle NAS distributies wat je wilt: gewoon netwerkopslag die op ZFS draait en via Windows/Apple/Linux/whatever te benaderen is. Dus wat jij wilt kan allemaal heel simpel Het wordt iets kritischer welk pakket je neemt indien je extra programma's wilt draaien. Dan zijn de verschillen tussen de beschikbare ZFS distributies veel groter.

Succes!

[Blazer Coke]

@ Cipher

Bedankt voor je snelle reactie.

Wat bedoel je met niet benaderbaar voor het internet?
Ik wil de server wel gebruiken om mijn bestanden via het internet te gebruiken.
Daarnaast wil ik ook een FTP draaien om bekenden bestanden te laten downloaden en te laten uploaden.
Ik wil hier echter geen openbare http server of ftp server oid op draaien, daar gebruik ik wel een derde partij voor.
Met mijn NAS heb ik dit altijd kunnen doen met inlogcodes.
Is een ZFS server hiervoor veilig genoeg? Of vereist dat toch extra werk?

Uhm ja, 4x4 TB
Ik zat ook nog te denken aan een 6-disk config van 2 of 3 TB schijven. Is dat beter dan 4x4TB?
Als een schijf uitvalt is de benodigde hersteltijd korter, maar hoe meer schijven, hoe groter de kans dat er een uitvalt. Waar ligt in zo een geval het optimum?

Qua kosten verwacht ik geen problemen. Ik wil het max rond de 1000 euro houden en volgens mij moet dat wel lukken. De uiteindelijek config ga ik uitzoeken als ik definitief ga voor ZFS.
Is het voor mij nodig om een SSD te gebruiken voor L2ARC en SLOG?

Qua OS
Is Nexenta ook een optie? Tot 18 TB (is dit totale of de bruikbare HD capaciteit?) is het immers gratis.
Wat is een VM instance?
Veiligheid, betrouwbaarheid en stabiliteit zijn voor mij het belangrijkst.
Ik wil me daar best wat dagen voor inspannen voor een config.

Een webinterface is prima. Ik bedoelde idd dat ik niet alles via de commandline hoef te doen. Dat gaat het hoop ergernis schelen.

Wat voor programma's doel je op?
Ik heb volgens mij niet heel veel eisen, ik ben nogal noob.
Mijn huidige simpele NAS kan het meeste wat ik wil al, dus ik verwacht niet heel veel problemen op dat gebied met ZFS OS-en.
Ik wil via internet bij mijn bestanden kunnen.
FTP en eventueel xbmc/torrent/usenet, maar dit doe ik nu via een pi en dat werkt ook goed.
Het is mij vooral te doen om veilige opslag.

[Compizfox]

Blazer Coke schreef op woensdag 07 oktober 2015 @ 23:53:
Wat bedoel je met niet benaderbaar voor het internet?
Ik wil de server wel gebruiken om mijn bestanden via het internet te gebruiken.
Daarnaast wil ik ook een FTP draaien om bekenden bestanden te laten downloaden en te laten uploaden.
Ik wil hier echter geen openbare http server of ftp server oid op draaien, daar gebruik ik wel een derde partij voor.
Met mijn NAS heb ik dit altijd kunnen doen met inlogcodes.
Is een ZFS server hiervoor veilig genoeg? Of vereist dat toch extra werk?

Ik denk dat CiPHER vooral bedoelde dat als je een server direct aan het internet hangt (zonder firewall, of in het DMZ bijvoorbeeld), je je erg bewust moet zijn van security. Dat betekent dat je moet weten waar je mee bezig bent (dat je niet per ongeluk dingen door eigen schuld slecht beveiligt), en dat je regelmatig security updates zult moeten bijhouden. Dat is niet bijzonders, ook kant-en-klaar-NASen hebben lekken en dus ook security updates.

Alleen FTP naar buiten openzetten kan niet zoveel kwaad, mits je het goed beveiligt natuurlijk.

Uhm ja, 4x4 TB
Ik zat ook nog te denken aan een 6-disk config van 2 of 3 TB schijven. Is dat beter dan 4x4TB?
Als een schijf uitvalt is de benodigde hersteltijd korter, maar hoe meer schijven, hoe groter de kans dat er een uitvalt. Waar ligt in zo een geval het optimum?

Dat is een trade-off tussen performance en redundantie. Uiteraard heb je met 6 disks in RAID-Z2 relatief minder redundantie dan met 4 disks in RAID-Z2 (slechts 1/3 in plaats van 1/2). De performance gaat echter wel hoger zijn, aangezien je meer disks hebt.

Qua kosten verwacht ik geen problemen. Ik wil het max rond de 1000 euro houden en volgens mij moet dat wel lukken. De uiteindelijek config ga ik uitzoeken als ik definitief ga voor ZFS.

Dat lijkt me zelfs een beetje overkill als storage de enige taak zal zijn voor dat systeem. Ik denk dat je met veel minder afkunt.

Is het voor mij nodig om een SSD te gebruiken voor L2ARC en SLOG?

Het is niet nodig, het versnelt de boel wel.

Qua OS
Is Nexenta ook een optie? Tot 18 TB (is dit totale of de bruikbare HD capaciteit?) is het immers gratis.
Wat is een VM instance?
Veiligheid, betrouwbaarheid en stabiliteit zijn voor mij het belangrijkst.
Ik wil me daar best wat dagen voor inspannen voor een config.

Een webinterface is prima. Ik bedoelde idd dat ik niet alles via de commandline hoef te doen. Dat gaat het hoop ergernis schelen.

Wat voor programma's doel je op?
Ik heb volgens mij niet heel veel eisen, ik ben nogal noob.
Mijn huidige simpele NAS kan het meeste wat ik wil al, dus ik verwacht niet heel veel problemen op dat gebied met ZFS OS-en.
Ik wil via internet bij mijn bestanden kunnen.
FTP en eventueel xbmc/torrent/usenet, maar dit doe ik nu via een pi en dat werkt ook goed.

Linux is populairder dan FreeBSD (in het algemeen, niet voor ZFS) en heeft dus over het algemeen meer software die ermee werkt. Een torrentclient (Transmission bijvoorbeeld) en software voor usenet (sabnzbd, sickbeard, couchpotato doel je op denk ik) zijn prima werkend te krijgen onder FreeBSD.

Bij Nexenta is dit nog een stapje erger omdat dat een nog minder populair OS is.

Wat betreft het "via internet bij je bestanden kunnen", bedoel je dan via de browser? In dat geval kan ik OwnCloud aanraden als software daarvoor. Hiermee kun je via de browser bij je bestanden via een interface die een beetje lijkt op die van bijvoorbeeld Dropbox, maar dan met als verschil dat de bestanden op je eigen NAS zijn opgeslagen. Er zijn ook apps en Windows/Linux clients voor beschikbaar (handig voor sync).

Het is mij vooral te doen om veilige opslag.

Dan zit je met ZFS goed in elk geval

[ Voor 5% gewijzigd door Compizfox op 08-10-2015 00:56 ]

[Fermion]

Wil het volgende even kwijt.
Voor iedereen die ZFS weet het al, wat een fantastisch RAID oplossing.

Momenteel hik ik tegen een harddisk (Seagate ST4000DM000-1F2168 4TB) dat abrupt niet meer is te benaderen, alleen na een power off/on wordt de drive door de controller weer gezien (Intel Panther Point AHCI SATA controller, Q77 chipset) totdat het weer zover is. De harddisk van controller gewisseld om een probleem met de SATA controller uit te sluiten. Hetzelfde harddisk begeeft het op een andere controller.

Hoe heerlijk is dat ZFS, het maakt het systeem niet uit wanneer de harddisks van controller is verwisselt, ZFS pakt het gewoon weer op.

Ook het weer in synchroon brengen van de RAID, initieert het systeem zelf het Resilver process.

De defecte harddisk aangemeld, kan hem gelukkig omruilen.

[HyperBart]

CurlyMo schreef op dinsdag 02 december 2014 @ 20:12:
Dit is wat ik heb geschreven voor dit doeleind. Als je het via SSH wil doen, dan plak je dit commando voor al je commando's die je op je offsite backup pool wilt doen.

CurlyMo, een tijdje geleden gaf je bovenstaande tip. Vandaag de dag ben ik zover dat ik dit in een bepaalde vorm wil gan implementeren. Kan je even concreet aangeven welke commando's of wat er dan moet aangepast worden als je bv. via SSH een send/receive wilt doen naar een destination?

[CurlyMo]

code:

SSH="ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null $IP";
zfs send -RI $F@$LASTDESTSNAP $F@$LASTORISNAP | pv | $SSH zfs receive -dvu $DESTROOT$RENAME

Zoiets. Gewoon dat SSH commando voor je externe commando's plakken.

[Bigs]

Met dat commando schakel je wel een van de essentiële beveiligingsmiddelen van SSH uit. Waarom zou je dat doen?

[CurlyMo]

Bigs schreef op vrijdag 09 oktober 2015 @ 17:05:
Met dat commando schakel je wel een van de essentiële beveiligingsmiddelen van SSH uit. Waarom zou je dat doen?

Bigs schreef op woensdag 03 december 2014 @ 11:04:
Vanwaar het advies om host key checking volledig uit te schakelen, CurlyMo?

FireDrunk schreef op woensdag 03 december 2014 @ 11:31:
Hostkey is toch alleen maar voor man-in-the-middle?

CurlyMo schreef op woensdag 03 december 2014 @ 12:01:
Ik wil het risico niet lopen dat mijn backups falen op een veranderde hostkey.

Bigs schreef op woensdag 03 december 2014 @ 13:45:
Ok wij gebruiken wel hostkeys zodat we juist opmerken als er onverwacht iets wijzigt, bijvoorbeeld dat je door een DNS wijziging ineens de verkeerde server aan het backuppen bent. Backups worden gemonitored via Zabbix dus als er een niet lukt dan weten we dat gelijk.

[Bigs]

Haha oprecht vergeten

[Beninho]

Vanavond na een reboot een issue, geen zfs modules meer. Zie hieronder

ubuntun 14.04 64 bit ZFS on linux.

code:

beninho@Jaguar:~$ sudo zpool status
The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.
beninho@Jaguar:~$ sudo su
root@Jaguar:/home/beninho# /sbin/modprobe zfs
modprobe: FATAL: Module zfs not found.
root@Jaguar:/home/beninho# dmesg | grep ZFS
root@Jaguar:/home/beninho# apt-get install ubuntu-zfs
Reading package lists... Done
Building dependency tree       
Reading state information... Done
ubuntu-zfs is already the newest version.

Heb dus geprobeerd om te herladen, maar krijg de melding dat de ZFS module niet gevonden is. Opnieuw installeren van ZFS is ook geen optie, want dat staat allemaal klaar.

dkms status geeft het volgende;

spl, 0.6.5.2, 3.13.0-63-generic, x86_64: installed
spl, 0.6.5.2, 3.13.0-65-generic, x86_64: installed
zfs, 0.6.5.2: added

Ik ben niet echt een expert, kan iemand me iets verder helpen?

-edit-
Heb iets gevonden,hier. Ik ben nu het volgende aan het proberen:

sudo dkms remove -m zfs -v 0.6.5.2 --all
sudo dkms add -m zfs -v 0.6.5.2
sudo dkms install -m zfs -v 0.6.5.2

duurt lang, die laatste stap, veel verhaal, maar lijkt nu aan bouwen. als dit werkt, laat ik het weten.

-edit2-
alleen nog even handmatig '/sbin/modprobe zfs' en vervolgens zpool import. Het werkt weer.

[ Voor 26% gewijzigd door Beninho op 13-10-2015 21:19 ]

[FireDrunk]

Dat is een bekende issue, daar loopt al langer een draadje over op GitHub.
Tijdens het installeren van nieuwe kernels wordt er niet altijd netjes een trigger gegeven aan ZFS DKMS om een rebuild van de module te doen. Ik heb het zelf ook ervaren met CentOS en Fedora.

[Beninho]

Ik las het, het draadje dat ik vond was al twee jaar oud, blijkbaar lastig om dat probleem definitief de deur te wijzen. Gelukkig niet heel lastig op te lossen.

[narotic]

Beninho schreef op dinsdag 13 oktober 2015 @ 20:59:
Opnieuw installeren van ZFS is ook geen optie, want dat staat allemaal klaar.

In plaats van de module handmatig via DKMS opnieuw te compileren zou het ook moeten werken om de package te herinstalleren:

code:

apt-get install --reinstall zfs-dkms

Resultaat is als het goed is hetzelfde, maar dit commando is net iets makkelijker te onthouden.

[Beninho]

Helemaal goed, ik zet het erbij, mocht het weer gebeuren. Mooi compact

[maomanna]

tijdje geleden heb ik een raidZ2 pool (3x 1tb) gemaakt, welke opzich prima functioneert.
Alleen is deze na het delen via samba zo tergend traag (zeg 3Mbit/s), dat je er liever niet aan komt.

De RaidZ1 pool gaat vliegensvlug (1Gbit/s)

Ligt dat aan samba of aan de soort pool?

[FireDrunk]

3 schijven in RAIDZ2? Dan heb je maar 1 data schijf... Dan kan je beter naar een 3-way mirror gaan...

Maar als je lokale benchmarks op de pool draait, waar kom je dan op uit op de RAIDZ2 Pool?

[maomanna]

Hoe bedoel je 3way mirror? Een mirror van een mirror? Dat is toch hetzelfde? De data die op die schijf staat, wil ik dusdanig bewaren dat als 1 disk uit valt te riskant is. Nu mogen toch 2 disks uitvallen?! Voordat de data weg is?

Een aantal mappen op die schijf backup ik naar een rpi2 met een usbhdd (erg traag, maar wel zuinig qua energie en had de pi nog liggen).

Welke benchmark moet ik draaien? Met welk commando?

[CurlyMo]

Een simpele representatie:

Een twee-weg mirror.

code:

|  |

Een drie-weg mirror.

code:

|  |  |

Dus gewoon een derde schijf met exact dezelfde informatie als de andere twee. Je hebt dus drie schijven met de bruikbare ruimte van 1. Twee schijven mogen falen voordat je je data kwijt bent.

RAIDZ2 met 3 schijven betekent ook de bruikbare ruimte van 1 schijf. Twee schijven mogen falen voordat je je data kwijt bent. Echter vergt het maken van parity in RAIDZ2 aanzienlijk meer performance dan een simpele 1-op-1 kopie maken zoals in de 3-weg mirror.

Een RAIDZ2 met 3 schijven is dus zinloos.

[maomanna]

Ah duidelijk. Dat kan ook de traagheid verklaren.

Hoe maak je die?

Zpool create mirror /dev/disk/by-id.....

Dat levert me een 2weg mirror. Hoe doe ik dan die 3weg? Drie disks toevoegen?

Had er tot vandaag nog niet van gehoord

[ Voor 5% gewijzigd door maomanna op 14-10-2015 22:22 ]

[CurlyMo]

Modbreak:

*knip* LMGTFY-linkjes mogen niet op Tweakers

Al prefereer ik zelf startpage.

PS. theoretisch kan je ook gewoon een 100-way mirror maken. Omdat het kan.

[ Voor 67% gewijzigd door Verwijderd op 14-10-2015 22:47 ]

[Verwijderd]

Zo maak je een 3-way mirror, dus gewoon drie disks opgeven ipv twee na het 'mirror' keyword.
zpool create tank mirror <disk1> <disk2> <disk3>

3-way mirror heeft 3 keer de IOps performance van een enkele disk, en schaalt dus op dit gebied vrijwel hetzelfde als RAID0. Qua sequential I/O iets trager, qua random IOps zelfs iets sneller (omdat bij RAID0 de verdeling van de I/O over de disks nooit perfect is).

RAID-Z1/2/3 heeft altijd de IOps performance van een enkele disk, voor read en write. Twee vdevs van RAID-Z2 hebben dus dezelfde IOps performance als een 2-disk RAID0 (read+write) of een enkele 2-disk mirror (alleen read).

[maomanna]

inderdaad wat ik dacht. Dan ga ik die data die erop staat mooi over hevelen en een 3way mirror maken.

Lees net trouwens dat het wel mogelijk is om in een pool een disk te vervangen EN dus te vergroten.

Well, you actually can upgrade that original RAIDZ2 of 1TB drives – what you have to do is fail one disk out of the vdev and remove it, then replace it with one of your 4TB drives. Wait for the resilvering to complete, then fail a second one, and replace it. Lather, rinse, repeat until you’ve replaced all six drives, and resilvered the vdev six separate times – and after the sixth and last resilvering finishes, you have a 24TB raw / 16TB usable vdev in place of the original 6TB/4TB one. Question is, how long did it take to do all that resilvering? Well, if that 6TB raw vdev was nearly full, it’s not unreasonable to expect each resilvering to take twelve to sixteen hours… even if you’re doing absolutely nothing else with the system. The more you’re trying to actually do in the meantime, the slower the resilvering goes. You might manage to get six resilvers done in six full days, replacing one disk per day. But it might take twice that long or worse, depending on how willing to hover over the system you are, and how heavily loaded it is in the meantime.

http://jrs-s.net/2015/02/...e-mirror-vdevs-not-raidz/

[Verwijderd]

Ja dat kan. Je kunt ook dingen doen zoals een degraded RAID-Z2 aanmaken met één of twee schijven missende, zodat je later nog kunt 'uitbreiden' in de zin dat je de redundancy kunt upgraden. Dus je begint met RAID-Z en je kunt later nog uitbreiden naar RAID-Z2.

Overigens, je RAID-Z2 zal niet de oorzaak zijn van je lage performance. Zelfs de traagste processors van 10 jaar terug kunnen dit prima aan. Op mijn J1900 heb ik nu ook een double degraded RAID-Z2 draaien en dat gaat tegen maximale snelheid en kost maar een paar procent CPU usage.

Dus de oorzaak van je lage performance moet je elders zoeken. Maar het zou prima kunnen dat je door het opnieuw aanmaken een andere factor verandert waardoor je dan opeens wel goede prestaties krijgt. Dus wees voorzichtig met conclusies trekken; zoals altijd geldt het principe van ceteris paribus. Oftewel: je kunt pas conclusies trekken in wetenschappelijk verband als alle andere factoren gelijk blijven. Dan pas kun je een goede A/B-vergelijking doen.

[FireDrunk]

@Maomanna:

Makkelijkste manier van benchmarken is Bonnie++ of iozone.

Onder een non-root account.

bonnie++ -d /pool/<test_directory>

http://www.textuality.com/bonnie/advice.html
Hier staat onder het kopje Bonnie Results hoe je de resultaten moet lezen.

[ Voor 28% gewijzigd door FireDrunk op 15-10-2015 07:27 ]

[CurlyMo]

@Modbreak, weer wat geleerd.

[maomanna]

Verwijderd schreef op woensdag 14 oktober 2015 @ 23:12:
Overigens, je RAID-Z2 zal niet de oorzaak zijn van je lage performance. Zelfs de traagste processors van 10 jaar terug kunnen dit prima aan. Op mijn J1900 heb ik nu ook een double degraded RAID-Z2 draaien en dat gaat tegen maximale snelheid en kost maar een paar procent CPU usage.

Dus de oorzaak van je lage performance moet je elders zoeken. Maar het zou prima kunnen dat je door het opnieuw aanmaken een andere factor verandert waardoor je dan opeens wel goede prestaties krijgt. Dus wees voorzichtig met conclusies trekken; zoals altijd geldt het principe van ceteris paribus. Oftewel: je kunt pas conclusies trekken in wetenschappelijk verband als alle andere factoren gelijk blijven. Dan pas kun je een goede A/B-vergelijking doen.

Begrijpelijk wat je zegt. Maar opzich heb ik al een ceteris paribus, namelijk mijn raidz1 pool. Zelfde machine, zelfde hba, zelfde sambasettings, zelfde cpu, ram, nic, routerpoort etc.
Enigste verschil is het type schijf. de Z1 = 5x 4TB seagate, de Z2 is 3x Samsung F1 1TB.

Eerst bonnie maar laten lopen. Kijken wat daar uit komt.

Edit: de resultaten van de Z2 pool.

code:

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
centraalpunt    31G   116  71 74347  11 39546   5   373  68 81062   3 110.5   3
Latency               112ms   81761us    2647ms     366ms     856ms    1300ms
Version  1.97       ------Sequential Create------ --------Random Create--------
centraalpunt        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 16293  50 +++++ +++ 20577  68 18272  70 +++++ +++ 20074  70
Latency               102ms    7313us    8379us   46297us    6969us   39934us

Nu de Z1 pool nog.

[ Voor 28% gewijzigd door maomanna op 15-10-2015 09:08 ]

[FireDrunk]

75MB/s / 81MB/s

Dat zijn middelmatige scores. De schijven zouden theoretisch gezien iets sneller moeten kunnen, maar op zich zijn ze acceptabel icm ZFS denk ik.

*zucht*

Zit ik mijn eigen array eens met DD te testen, haal ik structureel 3GB/s.... Zelfs met een test size van 160GB...

Nu maar met 500GB testen...

[root@NAS tmp]# dd if=/dev/zero of=test.000 bs=16M count=40024
40024+0 records in
40024+0 records out
671491293184 bytes (671 GB) copied, 214.163 s, 3.1 GB/s

Zucht... Misschien moet ik Compressie eens uitzetten

[ Voor 58% gewijzigd door FireDrunk op 15-10-2015 09:20 ]

[maomanna]

De Z1 pool

code:

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
centraalpunt    31G   121  70 394284  40 198154  26   406  75 481515  20  96.9   3
Latency               101ms     123ms    1369ms   86599us     199ms     428ms
Version  1.97       ------Sequential Create------ --------Random Create--------
centraalpunt        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 24211  74 +++++ +++ 20850  68 15774  68 +++++ +++  5689  46
Latency             21265us    7496us    8064us   43412us    3146us   12333us

Beduidend sneller met haar 394MB/s en 481MB/s


Als de Z2 pool een snelheid levert van ~75MB/s, dan is dat de bottleneck en niet het netwerk. Het lezen en openen van bestanden gaat zo traag (foto van 1MB duurt 30+ sec, en een .html bestand van 3Kb opent soms nog langer..)

Ik denk dat ik toch naar de threeway mirror ga. Ook al heeft de schijf +- 100Mb/s aan snelheid. Hopelijk is de toegankelijkheid dan beter.

[FireDrunk]

30 seconden over een foto van 1MB is wel heel extreem... Dat ligt denk ik niet aan ZFS?
Is je netwerk zelf wel stabiel? Zit je niet via WiFi te werken ofzo?

[maomanna]

Nee heb geen wifi op die machine. alles loopt via gbit via een Mikrotik CRS125
Heb verder nergens problemen mee, alleen de shares die vanaf die pool komen.
Het openen van mappen gaat wel vlot, alleen zodra er losse files in staan wordt het dramatisch.

[FireDrunk]

Heb je nog enige vorm van ZFS tuning gedaan? (ARC ofzo?)

[Keiichi]

Op FreeBSD 10.2 probeer ik een snapshot van een zvol te mouten (ik hou hier even vast aan voorbeelden uit https://wiki.freebsd.org/ZFSQuickStartGuide)

In /dev/zvol/tank/ zie ik dan alle zvol plus gemaakte snapshots. Als ik 'mount -r /dev/zvol/tank/ufs /ufs' doe werkt het. Als ik 'mount -r /dev/zvol/tank/ufs@20070406 /ufs20070406' dan krijg ik 'mount: /dev/zvol/tank/ufs@20070406: No such file or directory' te horen.


Doe ik hier zelf ergens iets fout?

[maomanna]

FireDrunk schreef op donderdag 15 oktober 2015 @ 09:41:
Heb je nog enige vorm van ZFS tuning gedaan? (ARC ofzo?)

op de Z2 pool zit geen L2ARC of sLOG

[CurlyMo]

Keiichi schreef op donderdag 15 oktober 2015 @ 09:43:
Doe ik hier zelf ergens iets fout?

Is die UFS zvol ook een UFS?

[Keiichi]

CurlyMo schreef op donderdag 15 oktober 2015 @ 09:46:
[...]

Is die UFS zvol ook een UFS?

De niet-snapshot mount wel gewoon.

[CurlyMo]

Dat was geen antwoord op mijn vraag

[Keiichi]

Volgens mij wel. Hij is zo gemaakt: zfs create -s -o volblocksize=128K -V 100G tank/hosting_images/%name%

Heb wel een copy paste fout gemaakt. In de fout staat een extra /dev/zvol die er niet is.

[ Voor 30% gewijzigd door Keiichi op 15-10-2015 10:02 ]

[CurlyMo]

Dat zegt echter niks over het bestandssysteem van je zvol. Heb je wel deze stap gedaan:

code:

newfs /dev/zvol/tank/ufs

?

[FireDrunk]

Uh, is het standaard mount commando wel aware van zfs snapshots?

Kan je niet gewoon doen:

zfs mount tank@snapshot /tank_snapshot

?

[Keiichi]

CurlyMo schreef op donderdag 15 oktober 2015 @ 10:04:
Dat zegt echter niks over het bestandssysteem van je zvol. Heb je wel deze stap gedaan:

code:

newfs /dev/zvol/tank/ufs

?

Ja. Daarna is ook een snapshot gemaakt.

FireDrunk schreef op donderdag 15 oktober 2015 @ 10:10:
Uh, is het standaard mount commando wel aware van zfs snapshots?

Kan je niet gewoon doen:

zfs mount tank@snapshot /tank_snapshot

?

Dat kan misschien als het een filesystem is

[ Voor 35% gewijzigd door Keiichi op 15-10-2015 10:14 ]

[FireDrunk]

Oh wacht, je moet met UFS het snapshot van je ZVOL mounten... Dat is lastig inderdaad.
Is het niet makkelijker om het snapshot te promoten tot een clone. Dan krijg je een nieuwe device node in /dev/zvol/[naamvanjeclone]

Daarna kan je doen:

mount /dev/zvol/[naamvanjeclone] /snapshot

[Keiichi]

FireDrunk schreef op donderdag 15 oktober 2015 @ 10:17:
Oh wacht, je moet met UFS het snapshot van je ZVOL mounten... Dat is lastig inderdaad.
Is het niet makkelijker om het snapshot te promoten tot een clone. Dan krijg je een nieuwe device node in /dev/zvol/[naamvanjeclone]

Daarna kan je doen:

mount /dev/zvol/[naamvanjeclone] /snapshot

Ik neem aan dat een snapshot gewoon de volle mep aan ruimte op de pool in gebruik neemt daarna? Heb me nog niet verdiept in clones

[FireDrunk]

Nope, hij wordt alleen writeable.

[rens78]

Hallo ZFS tweakers,

Misschien een beetje off-topic betreft jullie discussie. Heeft er iemand hier enige ervaring met het tweaken van ZFS? Kijkend naar de datapool en ZFS zelf.

In de map:

/sys/module/zfs/parameters/

Zijn er vele opties beschikbaar om ZFS naar wens aan te passen.

Mijn Use Case is een Supermicro server(met Proxmox) om meerdere VPSen op te hosten.

Specs:

C600/X79 series chipset
24 x Intel® Xeon® CPU E5-2620 v2 @ 2.10GHz (2 Sockets)
LSI 9207-8i hba card
11 x 2TB SAS 7.200
3 x INTEL SSDSC2BB12
128 GB memory 1600 MHz

Op de datapool heb ik een aparte SSD schijf voor logs(SLOG) en L2ARC gebruikt(2 partities).

Hebben jullie enig idee hoe er voor deze Use Case nog meer winst is te behalen betreft ZFS? Ik heb trouwens in de extra opties zfs_arc_min op 1 GB en zfs_arc_max op 12 GB gezet omdat ik verwacht dat de Virtuele Machines veel geheugen zullen consumeren. Is dat verstandig?

Groetjes,

[FireDrunk]

Je kan de L2ARC instellingen aanpassen, om hem wat sneller te laten vullen.
Je kan ook de vdev_min en vdev_max pending proberen wat bij te stellen. Hoe meer geheugen er vrij is, hoe groter je transactiegroepen theoretisch gezien kunnen zijn.
Als ze alleen zo groot groeien dat ze niet snel naar disk geflushed worden, krijg je het bekende "stalling" (hoge write performance, maar lange tussenposes tussen transacties).

[rens78]

Hoi,

Met vdev_min en vdev_max bedoel je de asynchronous en synchronous writes????(zfs_vdev_async_read_max/read_min/write_max/write_min)
en visa versa voor de synchronous writes...

Want de vdev opties slaan op de Virtual Devices(dus members van de datapool) en de value die je aan de bovengenoemde opties geeft slaan op de uhhmm waiting time? totdat het pakketje uit het geheugen naar de disk wordt geschreven?

FireDrunk schreef op donderdag 15 oktober 2015 @ 10:51:
Als ze alleen zo groot groeien dat ze niet snel naar disk geflushed worden, krijg je het bekende "stalling" (hoge write performance, maar lange tussenposes tussen transacties).

Dit begrijp ik nog niet helemaal, heeft dit te maken met die ARC tactiek die bij ZFS anders is dan bij andere bestandssystemen? Check:

http://www.c0t0d0s0.org/a...he-of-ZFS-or-The-ARC.html

[FireDrunk]

Transaction groups leven buiten ARC.

[rens78]

Ik heb een aparte ZIL schijf.... ik neem aan dat de transactie groepen daarop worden gezet totdat het daadwerkelijk veilig weggeschreven is?

FireDrunk schreef op donderdag 15 oktober 2015 @ 10:51:
Hoe meer geheugen er vrij is, hoe groter je transactiegroepen theoretisch gezien kunnen zijn.

[ Voor 43% gewijzigd door rens78 op 15-10-2015 11:23 ]

[rens78]

Ik heb trouwens een datapool met raidz3, specs:

pool: datapool
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
datapool ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxx ONLINE 0 0 0
scsi-xxxxxxc ONLINE 0 0 0
logs
scsi-SATA_INTEL_SSDSC2BBxx-part2 ONLINE 0 0 0
cache
scsi-SATA_INTEL_SSDSC2BBxx-part2 ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-INTEL_SSDSC2BB120G6_xxxx-part2 ONLINE 0 0 0
ata-INTEL_SSDSC2BB120G6_xxxx-part2 ONLINE 0 0 0

errors: No known data errors

[FireDrunk]

Nee, ZIL is geen write cache. ZIL is alleen voor de garantie van de transactie volgorde.

Voorbeeld van writes:

A -> D -> B -> C -> E als volgorde van operaties. Waar D een sync write is. Dan moet D voor B.
Als je een ZIL hebt, wordt die inhoud in memory netjes weggeschreven, en de volgorde van de transacties op ZIL gezet. Volgens mij zet ZFS ook de Sync write op ZIL, maar niet de complete transaction group.

ZFS kan intussen (omdat het de volgorde in Memory en op ZIL heeft) fysiek gewoon A->B->C->D->E op je schijven doen, waardoor de performance extreem omhoog gaat. Bovendien kan ZFS al een signaaltje teruggeven aan de applicatie dat de SYNC write klaar is, omdat het kan garanderen dat het systeem zelfs na een powerfailure diezelfde data terug kan halen.

Mocht je systeem dus gewoon online blijven, wordt er nooit gelezen van ZIL, want de hele transactiegroep komt nog steeds uit RAM.

Alleen als je systeem gecrasht is, en ZFS ziet bij het mounten dat de transacitielog van de ZIL verder is dan die van de pool, wordt de transactielog van de ZIL alsnog uitgevoerd.
Alle asynchrone writes NA je sync write, ben je nog steeds kwijt!

[rens78]

Ahh oke... doordat de volgorde --> A->B->C->D->E is kan zfs het sneller wegschrijven... dat is dan toch synchronious? Dus de performance winst komt voort uit de aparte ZIL schijf omdat ZFS daarover zijn hoofd niet hoeft te breken.

Een ZIL schijf heb ik! Zijn er nog meer Tweaks, TIPS oid toe te passen?

[FireDrunk]

Synchronous is niet hetzelfde als Seqential Maar je begrijpt het wel ja.
Bovendien zijn sync writes vanuit het perspectief van de applicatie snel klaar. Daar zit het grootste gedeelte van de winst.

Als je echt geavanceerd wil tunen, zul je precies het gedrag van je schijven moeten monitoren. Kijk hoe lang transacties duren, monitor hoe groot de verhouding is tussen reads en writes.

Pas dan kan je zinnige tuning toepassen.

[rens78]

Ahh oke, nog tips voor een aantal benchmarking tools? Je zou die invloed ook kunnen uitvoeren door de recordsize(nu 128k) aan te passen. Er is nog een waarde die meespeelt die default op 8 staat(kan er ff niet opkomen).

[FireDrunk]

recordsize is vooral leuk icm ZVOL's. Als je die weer shared over iSCSI is een recordsize van 8k icm Jumbo Frames erg leuk. Dan kan je heel wat meer IOPS uit je systeem persen.
In Windows VM's kan je ook nog weer de NTFS sector size op 4 of 8K zetten, daarnaast nog een goede partitie alignment, en het gaat als de brandweer

[rens78]

Hmm oke, ik probeer het nu te benchmarken met iostat.

Hieronder zie je daar een output van. Klopt het dat de initial writes en re writes te maken heeft met de arc.

De eerste vier results(initial write, Re-write, Read en Re-read) dat slaat dan op sequentiële writes en het laatste blok(Random Read en Random Write) op de random iops...

Ik kan de link van de sequentiële/random wrutes naar de zfs async en sync alleen niet leggen .

Children see throughput for 1 initial writers = 1179939.62 KB/sec
Parent sees throughput for 1 initial writers = 1101630.32 KB/sec
Min throughput per process = 1179939.62 KB/sec
Max throughput per process = 1179939.62 KB/sec
Avg throughput per process = 1179939.62 KB/sec
Min xfer = 12582912.00 KB

Children see throughput for 1 rewriters = 2294194.75 KB/sec
Parent sees throughput for 1 rewriters = 1965787.28 KB/sec
Min throughput per process = 2294194.75 KB/sec
Max throughput per process = 2294194.75 KB/sec
Avg throughput per process = 2294194.75 KB/sec
Min xfer = 12582912.00 KB

Children see throughput for 1 readers = 4700720.50 KB/sec
Parent sees throughput for 1 readers = 4699586.13 KB/sec
Min throughput per process = 4700720.50 KB/sec
Max throughput per process = 4700720.50 KB/sec
Avg throughput per process = 4700720.50 KB/sec
Min xfer = 12582912.00 KB

Children see throughput for 1 re-readers = 4915424.50 KB/sec
Parent sees throughput for 1 re-readers = 4914142.53 KB/sec
Min throughput per process = 4915424.50 KB/sec
Max throughput per process = 4915424.50 KB/sec
Avg throughput per process = 4915424.50 KB/sec
Min xfer = 12582912.00 KB

Children see throughput for 1 random readers = 4765464.00 KB/sec
Parent sees throughput for 1 random readers = 4764255.02 KB/sec
Min throughput per process = 4765464.00 KB/sec
Max throughput per process = 4765464.00 KB/sec
Avg throughput per process = 4765464.00 KB/sec
Min xfer = 12582912.00 KB

Children see throughput for 1 random writers = 2363265.00 KB/sec
Parent sees throughput for 1 random writers = 2049557.50 KB/sec
Min throughput per process = 2363265.00 KB/sec
Max throughput per process = 2363265.00 KB/sec
Avg throughput per process = 2363265.00 KB/sec
Min xfer = 12582912.00 KB

[FireDrunk]

ARC is een read cache, geen write cache. Transaction Groups zijn een soort write cache.

Je zit nu vooral in RAM te krassen inderdaad. Als je dat wil overslaan, zul je een _gigantische_ test size moeten gebruiken, omdat je op een server zit met een extreme hoeveelheid geheugen

Vuistregel van CiPHER was geloof ik 5 * je RAM, maar in dit geval zal het verschil nog steeds flink zijn denk ik.

Je zit eerder aan een testsize van 2-3 TB ofzo...

[ Voor 23% gewijzigd door FireDrunk op 15-10-2015 14:17 ]

[rens78]

Ahh yes, dus jij suggereert dat ik dan pas zinnige testresultaten krijg.. wanneer ik de tweaks toepas dan..

Net had ik wel een opvallend resultaat...

Had met een recordsize van 128(dat is default toch?), zfs_arc_max(10GB, omdat we ZFS niet al het geheugen willen laten consumeren i.v.m. de VM's) een iozone test uitgevoerd voor een testsize van 90GB.

Initial Write: 1,9 GB/s
Re-write: 2,07 GB/s

Read: 2,65 GB/s
Re-read: 2,30 GB/s

Random Read: 42,32 MB/s(AHH daarom duurde de test zo ontiegelijk lang)
Random Wirte: 1,9 GB/s

Ik ben nu een test aan het uitvoeren(zonder de zfs_max_arc size optie, dus gewoon 0) voor 155 GB testsize. Waarom 155 GB? omdat het totale geheugen nu 31 GB is, ik heb na jouw opmerking toch even gewacht met het bij prikken van geheugen .

Zou het ook zinnig zijn om vanaf een VM(bijv Debian) de iozone benchmarks uit te voeren? om vervolgens vanuit daar de performance resultaten te bekijken wanneer ik iets op de host(Proxmox) in ZFS wat aanpas? Ik ken dan wel een realistisch scenario toe, en ik wijs slechts 4GB aan de betreffende VM toe... maar ik denk dat dan de testsize zoz te klein is?

Wat een vragen weer...

[rens78]

Oja en jij hebt het over een testsize(wat je in iozone opgeeft) waarop is dat gebaseerd? is dat een constante stroom van data wat na 90GB(afhankelijk van je testsize) dan stopt, dus varieerde groottes. Of is het één block bestand wat in één keer wordt weggeschreven(dat zou natuurlijk niet realistisch zijn).

[aadje93]

Heren der ZFS kunde,

voor mijn nieuwe build (wat uiteindelijk 24x4TB, 4x z2 a 6 schijven per vdev) heb ik vraag omtrent geheugen, De machine zal hoofdzakelijk voor opslag van media en backups gaan dienen, maar word ook de opslag (via nfs shares) voor mijn ESXI labje.

Nu vraag ik mij af hoeveel geheugen ik het beste kan nemen,

de hardware lijst die ik op het oog heb:

#	Product	Prijs	Subtotaal
1	Intel Xeon E5-1620 v3 Boxed	€ 308,90	€ 308,90
1	Supermicro X10SRL-F (Retail Pack)	€ 305,25	€ 305,25
24	WD Red SATA 6 Gb/s WD40EFRX, 4TB	€ 161,50	€ 3.876,-
4	Crucial CT16G4RFD4213	€ 120,25	€ 481,-
Bekijk collectie Importeer producten		Totaal	€ 4.971,15

Nu zit ik te twijfelen tussen 16GB modules en 32GB modules, bij gebruik van 16GB modules kan ik tot 128GB geheugen gaan, bij 32GB modules kan ik tot 256GB gaan (2 verschillende soorten wil ik er niet in hebben)

Met 24x4 zit je "bruto" al aan 96TB, dit zal in freenas termen vertaalt worden naar ~90-100GB geheugen. Als ik echter nog dingen als encryptie/dedup/L2ARC (intel 750 pcie?) etc wil ben ik binnen no time aan de 128gb geheugen...

Is het dan verstandiger gewoon 32GB modules te nemen en met de tijd te upgraden naar 256? (beginnend met 64GB en 6hdd's)

ik hoor graag jullie mening, ik kom van synology en heb alleen wat zitten experimenteren in esxi met freenas, een dedicated build vraagt toch wat resources voor goede performance. Backups van enkele terrabytes wil ik toch snel erop hebben staan.

Ook wil ik naar iscsi ipv lokale schijven gaan om lokale non-raid uit te bannen, en alles op de ZFS machine te krijgen, er gaat dus wel wat werk komen, een geheugen tekort is dan je grootste nachtmerrie wat ik op internet lees.

Wat is jullie advies?

[begintmeta]

offtopic:
Ik ben altijd wel een beetje benieuwd waarmee men 96TB vult

[Q]

aadje93 schreef op zaterdag 17 oktober 2015 @ 14:21:
Heren der ZFS kunde,

Wat is jullie advies?

Die 1 GB / TB aan geheugen regel die maar terug blijft komen is niet relevant voor thuis gebruik.
Zie ook mijn build in mijn signature en wat info over ZFS.

In jouw geval zou ik gewoon 2 x 12-disk RAIDZ2 draaien met large_blocks support ingeschakeld.
Levert je 8 TB extra space op ofwel 300 euro bespaard. Ik weet niet hoeveel data je nu hebt, maar met deze setup zou je nu met 12 disks kunnen beginnen = ~40 TB en later als de boel vol raakt nog eens 12 disks toevoegen pas op het moment dat dit nodig is (ik kon dat niet doen).

Omdat je VMs gaat draaien op deze machine zou ik toch 32 GB RAM overwegen zodat wat meer data gecached kan worden. Misschien zelfs interessanter om 64 GB er in te stoppen dan het geld te besteden aan L2ARC SSD.

Voor thuis - zelfs met een ESXi lab - verwacht ik niet dat je ooit baat gaat hebben bij meer dan 128 GB RAM als cache. Maar eigenlijk denk ik dat dit al totale overkill is.

Misschien is het een idee om eerst eens te kijken wat de performance is met 32 GB RAM en geen L2ARC of ZIL en dan pas te kijken of het echt nodig is om meer geld te investeren.

Als je kunt leven met een corrupte VM mocht de machine uitvallen/crashen, zou je ZIL/SLOG uit kunnen schakelen, wat performance ook weer beter maakt. Anders zou ik zeker een SSD in mirror als SLOG gebruiken.

begintmeta schreef op zaterdag 17 oktober 2015 @ 14:31:

offtopic:
Ik ben altijd wel een beetje benieuwd waarmee men 96TB vult

Porno, wat anders?

[ Voor 58% gewijzigd door Q op 17-10-2015 17:37 ]

[aadje93]

Dank voor je bericht, om de reden van ~128gb als max met 16gb modules (er kunnen er 8 op) en het prijsverschil van ~20 euro tussen 2 16gb modules en 1 32GB module zit ik dus in de clinch, de hdd's worden steeds groter, en daarmee dus ook de eventuele geheugen zucht van ZFS. Datazekerheid is erg belangrijk, ik spendeer liever een paar hdd's aan parity dan dat ik een 12 disk vdev naar de ***** help door een geheugen foutje, of een ontbrekend battery cache.

SLOG device heb ik ook over gelezen, als ik het goed begrijp is een L2ARC de 2e level read cache (1e level de ARC in het geheugen zelf) waarbij de L2arc ook een kleine head heeft in het gewone ARC (vandaar soms de verhalen van in elkaar geklapte performance door een te grote L2ARC)

Zou het mogelijk zijn de xeon met 2 sticks te draaien? Of moeten er echt 4 in voor de quad channel. Ik heb nooit eerder met triple/quad channel gewerkt, altijd dual, dit werkt wel met 1 stick, maar ik weet dus niet of quad channel 2 sticks leuk gaat vinden.

Ik wil ondanks "thuisgebruik" toch minimaal de volle gigabit halen, en als link aggregation mogelijk is dit ook eigenlijk voltrekken, hoe sneller die backups op hun bestemming zijn hoe beter Het VM labje is niet zo groot, maar er gaat veel videomateriaal komen waar ik gewoon backups van wil hebben hier thuis terwijl het ook op youtube komt. Ruwe game capture gaat zo naar de gigabyte per minuut op full hd, dat tikt hard door voor een paar uurtjes filmen

Ik heb nog 2 samsung 840 evo'tjes liggen, misschien dat die in raid 1 als ZIL kunnen dienen, zit volgensmij alleen geen batterij in tegen power failures (de nas komt uiteraard ook gewoon aan een UPS te hangen, alleen het zekere voor het onzekere, op zo'n build mag een componentje van 70 euro niet je 70-80TB aan data ver*****)

Een raid 1 setup als ZIL kan nog enige garantie bieden tegen power failures? Of zeg je gewoon echt een battery backup in de SSD (crucials hadden dit?)

Freenas/ZFS is voor mij redelijk nieuw, maar het is wel interessant met het oog op de toekomst, en de mogelijkheden als dedup/encryptie.

[Q]

aadje93 schreef op zaterdag 17 oktober 2015 @ 17:51:
Dank voor je bericht, om de reden van ~128gb als max met 16gb modules (er kunnen er 8 op) en het prijsverschil van ~20 euro tussen 2 16gb modules en 1 32GB module zit ik dus in de clinch, de hdd's worden steeds groter, en daarmee dus ook de eventuele geheugen zucht van ZFS. Datazekerheid is erg belangrijk, ik spendeer liever een paar hdd's aan parity dan dat ik een 12 disk vdev naar de ***** help door een geheugen foutje, of een ontbrekend battery cache.

Qua data zekerheid denk ik dat 4xRAIDz2 wel erg extreem is, zeker thuis. Voor jou zou eerder het argument zijn dat met 4 VDEVs je betere random I/O performance krijgt. Maar die performance zal nog steeds behoorlijk brak zijn. Grofweg de random I/O performance van 4 disks.

SLOG device heb ik ook over gelezen, als ik het goed begrijp is een L2ARC de 2e level read cache (1e level de ARC in het geheugen zelf) waarbij de L2arc ook een kleine head heeft in het gewone ARC (vandaar soms de verhalen van in elkaar geklapte performance door een te grote L2ARC)

Correct.

Zou het mogelijk zijn de xeon met 2 sticks te draaien? Of moeten er echt 4 in voor de quad channel. Ik heb nooit eerder met triple/quad channel gewerkt, altijd dual, dit werkt wel met 1 stick, maar ik weet dus niet of quad channel 2 sticks leuk gaat vinden.

Je zult wat geheugen bandbreedte inleveren, maar ik betwijfel zelf of je daar iets van merkt in de praktijk.

Ik wil ondanks "thuisgebruik" toch minimaal de volle gigabit halen, en als link aggregation mogelijk is dit ook eigenlijk voltrekken, hoe sneller die backups op hun bestemming zijn hoe beter Het VM labje is niet zo groot, maar er gaat veel videomateriaal komen waar ik gewoon backups van wil hebben hier thuis terwijl het ook op youtube komt. Ruwe game capture gaat zo naar de gigabyte per minuut op full hd, dat tikt hard door voor een paar uurtjes filmen

Sneller dan gigabit is thuis altijd lastig. Link aggregation werkt niet tussen slechts twee computers. Tenzij je 2 x linux draait, dan is mijn artikel in mijn signature van toepassing. Anders moet je investeren in 10Gbe hardware = prijzig. Maar je kunt er even naar kijken.

Ik heb nog 2 samsung 840 evo'tjes liggen, misschien dat die in raid 1 als ZIL kunnen dienen, zit volgensmij alleen geen batterij in tegen power failures (de nas komt uiteraard ook gewoon aan een UPS te hangen, alleen het zekere voor het onzekere, op zo'n build mag een componentje van 70 euro niet je 70-80TB aan data ver*****)

Naar mijn weten is het risico met SSDs zonder supercapacitor of weet ik veel wat de term is: plotseling stroom verlies -> SSD corrupt/dood. die kans is erg klein met een UPS (install wel APCUPSD of kies een NAS distro die dit ondersteund). Rest risico is dat je zelf onhandig bent, maar dat is aan jou.

Zelf heb ik voor de zekerheid wel de 'juiste' SSDs gekocht maar ik had niets liggen.

Een raid 1 setup als ZIL kan nog enige garantie bieden tegen power failures? Of zeg je gewoon echt een battery backup in de SSD (crucials hadden dit?)

Freenas/ZFS is voor mij redelijk nieuw, maar het is wel interessant met het oog op de toekomst, en de mogelijkheden als dedup/encryptie.

Dedup op ZFS = onbruikbaar, sterk af te raden.

[CurlyMo]

Q schreef op zaterdag 17 oktober 2015 @ 19:14:
Dedup op ZFS = onbruikbaar, sterk af te raden.

Daar ben ik het niet mee eens. In geval van een backup schijf kan dit zeker wel interessant zijn.

[matty___]

Q schreef op zaterdag 17 oktober 2015 @ 19:14:
Dedup op ZFS = onbruikbaar, sterk af te raden.

Check deze commit:

https://reviews.csiden.org/r/223/

sha512

This feature enables the use of the SHA-512/256 truncated hash
algorithm (FIPS 180-4) for checksum and dedup. The native 64-bit
arithemtic of SHA-512 provides an approximate 50% performance boost
over SHA-256 on 64-bit hardware and is thus a good minimum-change
replacement candidate for systems where hash performance is
important, but these systems cannot for whatever reason utilize the
faster skein and edonr algorithms.

Booting off of pools utilizing SHA-512/256 is supported (provided
that the updated GRUB stage2 module is installed).

skein

This feature enables the use of the Skein hash algorithm for
checksum and dedup. Skein is a high-performance secure hash
algorithm that was a finalist in the NIST SHA-3 competition. It
provides a very high security margin and high performance on 64-bit
hardware (80% faster than SHA-256). This implementation also
utilizes the new salted checksumming functionality in ZFS, which
means that the checksum is pre-seeded with a secret 256-bit random
key (stored on the pool) before being fed the data block to be
checksummed. Thus the produced checksums are unique to a given
pool, preventing hash collision attacks on systems with dedup.

edonr

This feature enables the use of the Edon-R hash algorithm for
checksum, including for nopwrite (if compression is also enabled,
an overwrite of a block whose checksum matches the data being
written will be ignored). In an abundance of caution, Edon-R can
not be used with dedup (without verification).

Edon-R is a very high-performance hash algorithm that was part of
the NIST SHA-3 competition. It provides extremely high hash
performance (over 350% faster than SHA-256), but was not selected
because of its unsuitability as a general purpose secure hash
algorithm. This implementation utilizes the new salted
checksumming functionality in ZFS, which means that the checksum is
pre-seeded with a secret 256-bit random key (stored on the pool)
before being fed the data block to be checksummed. Thus the
produced checksums are unique to a given pool, blocking hash
collision attacks on systems with dedup.

Deze zit reeds in FreeBsd current. Wachten is op een vergelijkende test om te zien hoeveel deze nieuwe algorithms in de praktijk schelen.

[BartNL]

Q schreef op zaterdag 17 oktober 2015 @ 19:14:
[...]
Sneller dan gigabit is thuis altijd lastig. Link aggregation werkt niet tussen slechts twee computers. Tenzij je 2 x linux draait, dan is mijn artikel in mijn signature van toepassing. Anders moet je investeren in 10Gbe hardware = prijzig. Maar je kunt er even naar kijken.

en wanneer je goede SMB read / write speeds via 10Gbe haalt dan hier even posten hoe je dat doet. Zit hier al weken te klooien met ZFS en via SMB is de performance een bedroevende 180 MB/s. Via FTP haal ik nu ongeveer 400MB/s. Lijkt helaas zo te zijn dat SMB onder ZFSGuru en FreeNAS nog niet voor 10Gb netwerk snelheden is gemaakt.

[maomanna]

Hoe openen jou bestanden? bijv een foto? Duurt dat ook zo lang of is dat klik - klaar?

[aadje93]

Smb/samba is single threaded, ftp volgenamij niet vandaar de brakke pwrformance . Je kunt in windows ook ftp://nas_ip opgevrn ipv je gewone share naam/ip misschien dat het helpt. 10gbe zit ik ook naar de kijken, op ebay zijn de intel 540xt niet gek duur te krijgen. Is toch erg leuk voor eigen pc die ik puur op een ssdtje voor het os wil laten werken, alle storage op zfs

[Q]

BartNL schreef op zaterdag 17 oktober 2015 @ 21:39:
[...]

en wanneer je goede SMB read / write speeds via 10Gbe haalt dan hier even posten hoe je dat doet. Zit hier al weken te klooien met ZFS en via SMB is de performance een bedroevende 180 MB/s. Via FTP haal ik nu ongeveer 400MB/s. Lijkt helaas zo te zijn dat SMB onder ZFSGuru en FreeNAS nog niet voor 10Gb netwerk snelheden is gemaakt.

Ik deed net een SMB test tussen twee Linux hosts over mijn 5 x gigabit bond maar kom niet verder dan gigabit snelheden, zonder verdere tuning. NFS trekt 500+ MB/s over mijn bond.

Het is wel slim om het IP van de bonding interface te gebruiken

Ik haal nu 400 MB/s over SMB tussen twee Linux clients en dat is waarschijnlijk de write performance limiet van de doel array.

[ Voor 14% gewijzigd door Q op 18-10-2015 06:10 ]

[strandbal]

BartNL schreef op zaterdag 17 oktober 2015 @ 21:39:
[...]

en wanneer je goede SMB read / write speeds via 10Gbe haalt dan hier even posten hoe je dat doet. Zit hier al weken te klooien met ZFS en via SMB is de performance een bedroevende 180 MB/s. Via FTP haal ik nu ongeveer 400MB/s. Lijkt helaas zo te zijn dat SMB onder ZFSGuru en FreeNAS nog niet voor 10Gb netwerk snelheden is gemaakt.

Welke samba versie draai je? Mijn ervaringen zijn met 4.2 veel beter dan met alles wat daarvoor kwam. In mijn geval is tuning niet eens meer nodig om fatsoenlijke snelheden te halen.

[BartNL]

Qua Samba op de NAS de default installatie onder laatste stabiele FreeNAS en ZFSGuru versies en die benader ik dan vanaf een Windows 10 client. Met wat tuning krijg ik af en toe wel betere snelheden maar niet iets wat stabiel goed werkt. ZFSGuru is volgens mij redelijk bij qua FreeBSD en had ook gehoopt dat die wat betere performance haalt.
Wanneer ik op dezelfde NAS hardware Windows 10 draai is snelheid richting 500MB/s van en naar een SSD en dan is de SSD de beperking.

[BartNL]

aadje93 schreef op zondag 18 oktober 2015 @ 06:06:
Smb/samba is single threaded, ftp volgenamij niet vandaar de brakke pwrformance . Je kunt in windows ook ftp://nas_ip opgevrn ipv je gewone share naam/ip misschien dat het helpt. 10gbe zit ik ook naar de kijken, op ebay zijn de intel 540xt niet gek duur te krijgen. Is toch erg leuk voor eigen pc die ik puur op een ssdtje voor het os wil laten werken, alle storage op zfs

dat laatste is ook mijn idee maar valt mij dusdanig tegen dat ik het nog niet gebruik.De 10Gbe ZFS NAS is alleen nog een duur probeersel

[G-Tus]

BartNL schreef op zondag 18 oktober 2015 @ 12:55:
Qua Samba op de NAS de default installatie onder laatste stabiele FreeNAS en ZFSGuru versies en die benader ik dan vanaf een Windows 10 client. Met wat tuning krijg ik af en toe wel betere snelheden maar niet iets wat stabiel goed werkt. ZFSGuru is volgens mij redelijk bij qua FreeBSD en had ook gehoopt dat die wat betere performance haalt.
Wanneer ik op dezelfde NAS hardware Windows 10 draai is snelheid richting 500MB/s van en naar een SSD en dan is de SSD de beperking.

De laatste ZFSguru draait nog een redelijk oude Samba, namelijk versie 3.6 (2011), terwijl 4.2 gewoon beschikbaar is voor FreeBSD.

[BartNL]

weet niet of het daar aan moet liggen. Zie ook meldingen van mensen die 350MB/s halen met samba 2. Kan best zijn dat ik hardware setup heb die niet goed ondersteund wordt. Daarbij dacht ik dat FreeNAS en ZFSGuru zo ver waren dat je weinig met de hand moet aanpassen. Dat laatste is bij mijn setup voor 1Gb ook zo. Alleen nadat ik 10Gb upgrade deed blijkt de snelheidswinst winst tegen te vallen.
Draai de ZFS NAS op basis van een Supermicro X10SRA-F mobo met E5-1620v3 CPU en 64GB ram dus qua hardware zou ik geen performance probleem verwachten.

[FireDrunk]

3.6 en 4.2 zijn verschillende ontwikkel lijnen. 3.6 is (mits je upgrade binnen de lijn) nog gewoon courant.

Zie hier:
https://www.samba.org/samba/history/
en:
https://www.samba.org/samba/history/samba-3.6.25.html

Laatste 'bugfix' release is van 23 februari.

[Q]

De versie van Samba waar ik mee testte was 4.1.17 op Debian.

[Compizfox]

strandbal schreef op zondag 18 oktober 2015 @ 10:30:
[...]


Welke samba versie draai je? Mijn ervaringen zijn met 4.2 veel beter dan met alles wat daarvoor kwam. In mijn geval is tuning niet eens meer nodig om fatsoenlijke snelheden te halen.

Dit. Ik merkte inderdaad ook een enorme performanceboost toen ik van 3.6 naar 4.x ging.

FireDrunk schreef op zondag 18 oktober 2015 @ 15:21:
3.6 en 4.2 zijn verschillende ontwikkel lijnen. 3.6 is (mits je upgrade binnen de lijn) nog gewoon courant.

Zie hier:
https://www.samba.org/samba/history/
en:
https://www.samba.org/samba/history/samba-3.6.25.html

Laatste 'bugfix' release is van 23 februari.

Nou ja, courant? Samba 3.6 is nu al sinds maart dit jaar EOL en krijgt dus geen security updates meer. Ik raad het dan ook sterk af om dat nog te gebruiken.

Zie ook https://wiki.samba.org/index.php/Samba_Release_Planning

[FireDrunk]

Ah! Die had ik nog niet gezien, ik dacht dat ze nog geen stable longterm branch hadden op 4.x.
Die is er intussen dus wel!

[Compizfox]

FireDrunk schreef op zondag 18 oktober 2015 @ 16:44:
Ah! Die had ik nog niet gezien, ik dacht dat ze nog geen stable longterm branch hadden op 4.x.
Die is er intussen dus wel!

4.x is al een hele tijd stable. Sterker nog, 4.1 en 4.2 zitten nu in respectievelijk "security fixes only" en "maintainance" state. 4.3 is de nieuwste stable release.

FreeBSD heeft helaas nog geen port voor Samba 4.3, maar dat zal binnenkort wel komen

[FireDrunk]

Voor de mensen die het leuk vinden:

Morgen begint de OpenZFS Developer Summit.

http://livestream.com/accounts/15501788/events/4422403
http://open-zfs.org/

Eerste livestream begint om 18:30 Nederlandse tijd.