Het grote ZFS topic

[FireDrunk]

Zpool export op al je pools
RM /etc/zpool.cache
Rebooten
Zpool import al je pools

Kan zijn dat die cache file ergens anders staat op BSD.

[revox862]

Bedankt! Heeft helaas niet geholpen.

Update: Alle schijven met 'zpool labelclear -f' behandelen heeft het opgelost.
Overigens was de nieuwe pool nog leeg, anders had ik dat niet gedaan

[ Voor 78% gewijzigd door revox862 op 06-08-2015 18:32 ]

[FireDrunk]

Ah, goed om te weten. Fijn dat het opgelost is!

[Verwijderd]

zpool destroy megatron
(oeps te laat..)

[ Voor 26% gewijzigd door Verwijderd op 06-08-2015 22:17 ]

[FireDrunk]

Dat was zijn laatste commando zoals je terug kan lezen

[revox862]

Ach, de pool was toch al stuk en leeg

[Fr0zenFlame]

Momenteel ook aan het experimenteren met ZFS (FreeNas) in onze test omgeving waar ik een server heb met 8 conventionele SAS schijven zonder SLOG om de ZIL op te plaatsen.
Deze server bevat ook maar 8 GB RAM, waar we eigenlijk 8 + 1 GB per TB = 14GB nodig hebben.
Logischerwijs zijn de prestaties niet goed.

Het enige wat hier op draait zijn een aantal test VM's op XenServer via NFSv3 (XenServer 6.5 ondersteund alleen NFSv3), deze presteren redelijkerwijs gewoon goed, alleen wanneer je een grote file zoals een *.ISO of *.IMG gaat verplaatsen van een share of andere VM naar een VM op deze test omgeving dan zie je een doorvoersnelheid die tussen de 80-120MB ligt, dat is dus bijna 1 Gigabit, goed toch? Helaas duurt dit maar even (ongeveer voor de eerste 2GB) daarna degradeerd de snelheid heel snel richting 10MB.
Wanneer SYNC uitgezet wordt is het iets beter richting de 20-30MB.

Vooralsnog is dit een test omgeving om even de feeling te krijgen met FreeNas en ZFS.
De bedoeling is om een PoC te bouwen met een "Full Flash" array, hiervoor willen we de volgende hardware gebruiken;

• Systeem: DL380p Gen8 2* 8C-E2650 V2/32GB/P420i-2GB/25SFF
  2x 750watt psu
• Network: 10Gib 533FLR-T FlexFabric Adapter 2 port on board (LACP 802.11 AD)
• Geheugen: 8x 8GB (1x8GB) Dual Rank x4 PC3-14900R (DDR3-1866)
  Misschien zelfs 16x 8GB
• HBA controller: LSI-9211-8e in IT mode i.p.v. de onboard HP Smart Array 420i
• System Disk: 1x Samsung 850 Pro 128 GB (backup configuration, mirror zou overkill zijn).
• Storage Disks:: 12x of 24x Samsung 845 DC pro 400GB.
• optionalSLOG Device: 2x Samsung 845 DC pro 400GB in mirror.

Ik begrijp dat in onze test omgeving het toevoegen van een SSD als SLOG voor de ZIL een oplossing is.
Maar in de PoC bestaat straks de hele array uit SSDs, volgens mij heb je dan geen losse disk(s) nodig om je ZIL op te plaatsen omdat SSDs gewoonweg snel genoeg zijn om dit te kunnen verwerken, of heb ik dit verkeerd en is het beter om nog 2x een SSD in mirror toe tevoegen als SLOG om de ZIL op te plaatsen?

Op conventionele schijven is het namelijk zo dat als je geen SLOG device voor de ZIL heb toegevoegd de ZIL wordt geplaatst op dezelfde platerns als waar de daadwerkelijke DATA staat en gezien de prestaties van conventionele schijven al niet best zijn in vergelijking tot SSDs gaan ze ook elkaar nog eens in de weg zitten als het om resources gaat.

Nou is het ook zo dat een ZIL eigenlijk alleen maar effectief is bij synchronise schijf acties.
Laten wij nou net NFS gebruiken in onze omgeving om de SRs aan de Hypervisor pool te koppelen, helaas ondersteund XenServer 6.5 alleen NFSv3 en dus is eigenlijk iSCSI sneller (NFSv4 zou beter zijn).
Maarja iSCSI doet dus asynchroon schrijven en is dus sneller, maakt geen gebruik van de ZIL en dat maakt het ook een stuk gevaarlijker.

Misschien dat hier wat mensen ervaring hebben met de volgende twee punten waar ik mee zit:

1. Is een ZIL nou wel of niet nodig als je gebruik maakt van een Full-Flash array?
   In kan hier niet echt een duidelijk antwoord op vinden, en ben ook weinig praktijk voorbeelden tegen gekomen.
2. We hebben tot nu toe altijd NFS gebruikt, is het ondanks de asynchrone writes en het feit dat iSCSI wat complexer is toch aan te raden om dit te implementeren als SR waarop VMs staan?

[Verwijderd]

Fr0zenFlame schreef op zaterdag 08 augustus 2015 @ 10:08:
Momenteel ook aan het experimenteren met ZFS (FreeNas) in onze test omgeving waar ik een server heb met 8 conventionele SAS schijven zonder SLOG om de ZIL op te plaatsen.
Deze server bevat ook maar 8 GB RAM, waar we eigenlijk 8 + 1 GB per TB = 14GB nodig hebben.

Dat is een fabeltje. Je hebt niet meer RAM nodig naarmate je disks groter worden. Je hebt meer RAM nodig naarmate je disks sneller worden. Voor tachtig schijven van een miljoen terabyte per stuk die 1MB/s doen heb je dus veel minder RAM nodig dan 2 SSDs van 10GB per stuk die 10GB/s doen.

Die '1GB RAM per 1TB disk' regel is simpelweg onjuist. Er bestaat geen relatie tot opslagcapaciteit en hoeveelheid RAM. Hooguit dat je een actief deel van je storage in RAM wilt hebben; zoals bij databases. Maar dat heeft an sich niets met de opslag te maken maar op applicatie-niveau.

De bedoeling is om een PoC te bouwen met een "Full Flash" array, hiervoor willen we de volgende hardware gebruiken;

Vertel ook even wat een PoC is.

Ik begrijp dat in onze test omgeving het toevoegen van een SSD als SLOG voor de ZIL een oplossing is.
Maar in de PoC bestaat straks de hele array uit SSDs, volgens mij heb je dan geen losse disk(s) nodig om je ZIL op te plaatsen omdat SSDs gewoonweg snel genoeg zijn om dit te kunnen verwerken, of heb ik dit verkeerd en is het beter om nog 2x een SSD in mirror toe tevoegen als SLOG om de ZIL op te plaatsen?

Het kan nog steeds een voordeel zijn. Bij sLOG hoeven te originele disks deze taak niet meer te verrichten. Hierdoor ontstaat een performancevoordeel; je doet de ZIL naar een stel dedicated disks ipv de hele pool. Bedenk ook dat het evengoed trager kan worden: indien alle writes sync writes zijn, is de sLOG veelal de bottleneck. In dat geval kun je veel beter geen sLOG gebruiken en dus zal de ZIL gewoon vanaf de pool bruikbaar zijn.

Eventueel kun je ook met snapshots werken en sync writes geheel uitschakelen (sync=disabled). ZFS heeft daar geen last van, en zolang je op je snapshots kunt terugvallen kun je alles in een consistente staat terugdraaien.

Nou is het ook zo dat een ZIL eigenlijk alleen maar effectief is bij synchronise schijf acties.
Laten wij nou net NFS gebruiken in onze omgeving om de SRs aan de Hypervisor pool te koppelen, helaas ondersteund XenServer 6.5 alleen NFSv3 en dus is eigenlijk iSCSI sneller (NFSv4 zou beter zijn).
Maarja iSCSI doet dus asynchroon schrijven en is dus sneller, maakt geen gebruik van de ZIL en dat maakt het ook een stuk gevaarlijker.

iSCSI en NFS zijn protocollen; waar haal je vandaan dat iSCSI geen gebruik zou maken van de ZIL? Dat is onzin.

Bij iSCSI naar een Windows machine gedraagt Windows zich net zo alsof het een lokale schijf is. Dus partitioneren, formatteren, initialiseren van het filesystem en er worden ook TRIM en sync writes gestuurd indien het OS dit normaliter ook zou doen.

Alleen ben ik bang dat in jouw geval, alle writes sync writes zijn - wat natuurlijk normaal helemaal niet zo is en eigenlijk vrij dom is. In dat geval bestaat er wel een groot verschil. Want sync writes zijn normaliter vrij spaarzaam om de metadata te scheiden van de data - oftewel om een volgorde van writes te forceren hetgeen de metadata consistent moet houden. Dat geldt evengoed bij iSCSI. Meer dan NFS nog, omdat bij NFS de client niet over de metadata gaat.

Misschien dat hier wat mensen ervaring hebben met de volgende twee punten waar ik mee zit:

1. Is een ZIL nou wel of niet nodig als je gebruik maakt van een Full-Flash array?
   In kan hier niet echt een duidelijk antwoord op vinden, en ben ook weinig praktijk voorbeelden tegen gekomen.
2. We hebben tot nu toe altijd NFS gebruikt, is het ondanks de asynchrone writes en het feit dat iSCSI wat complexer is toch aan te raden om dit te implementeren als SR waarop VMs staan?

NFS is als NAS-protocol altijd superieur aan SAN-protocollen als iSCSI, omdat bij dat laatste ZFS niet het eigenlijke filesystem is. Je hebt een virtuele hardeschijf op ZFS geplaatst, en op die virtuele hardeschijf staat dan een legacy filesystem zoals Ext4, NTFS, enzovoorts. Dat betekent dus ook heel veel minder bescherming. AoE of NFS of SMB zijn dus beter omdat de data direct op ZFS wordt opgeslagen en dat geeft je data dus ook maximale bescherming.

In jouw situatie waarbij je louter SSDs gebruikt denk ik dat je prima zonder sLOG kunt. Ik maak me alleen zorgen dat je het systeem op een losse SSD laat draaien. Als dit een heel belangrijk systeem is, wil je eigenlijk niet dat één falend onderdeel je hele storage/VM-oplossing offline kan halen. Je zegt dat je een backup hebt van de systeemdisk; maar uptime lijkt me ook erg belangrijk? Twee goedkope SSDtjes zoals MX100 lijkt me beter dan Samsung DC modellen, ook al hebben die caps.

[Fr0zenFlame]

Bedankt voor je heldere uitleg CiPHER, dit maakt het voor mij een stuk duidelijker.

NFS vs iSCSI:
Nu weet ik eigenlijk vrij zeker dat we voor NFS moeten blijven gaan i.p.v. switchen naar iSCSI.

ZIL:
Ik neig er ook naar om de ZIL gewoon bij de rest van de data disks te laten i.p.v. op een losse SLOG te zetten. Eventueel kan dit later ook.

System Disk:
We hebben er inderdaad voor gekozen om 1 SSD te gebruiken voor het FreeNas OS, helaas is alles meer dan 2GB overkill omdat het hele device wordt gebruikt. Raad je aan om twee disks in Mirror te zetten? In principe zijn er bijna geen WRITES naar de disks en zal deze praktisch onbeperkt beschrijfbaar zijn.
FreeNas wordt immers alleen bij het start in het geheugen geladen en daarna vind er er zeer weinig IO richting die disk plaats.
Ben het inderdaad met je eens dat dit gewoon een goedkopere SSD kan zijn.

Array configuratie::
Verder waar ik nog een beetje over twijfel is welke RAID configuratie ik zal doen.
Uitgaande van 12 SSDs wilde ik voor RAID-Z2 gaan, maar bij 24 SSDs misschien wel RAID-Z3.
Maar ik heb begrepen uit verschillende hoeken dat "performance wise" het wellicht verstandig is om voor "mirrored vdevs" te gaan, een soort RAID-10 eigenlijk... Heb je hier praktijk ervaring mee toevalig?

Misschien een idee om 12 VDEVS te maken van 2 SSDs in mirror van elkaar en hier dan striping over te doen. Of 8 VDEVS van 3 SSDs al is dat misschien zonde van de ruimte. Wel SAFE en veel I/O maar ook veel verlies van ruimte.

[ Voor 7% gewijzigd door Fr0zenFlame op 08-08-2015 14:43 ]

[Dadona]

Verwijderd schreef op zaterdag 08 augustus 2015 @ 12:00:
[...]

Vertel ook even wat een PoC is.

Proof of Concept

[Fr0zenFlame]

Inderdaad "Proof of Concept".

RAID vs Mirror vDevs
Afgelopen weekend mezelf verdiept in ZFS an sich en de voor/nadelen van RAID-Zx vs (stripping over) Mirrored vDevs.

Het idee is nu om dus 12 vDevs te maken in mirror (2x 400GB SSD), en hier vervolgens striping over. Het is alleen zonde dat we dan 50% diskspace verliezen.

SLOG
Verder willen we de ZIL niet los trekken van dit volume d.m.v. SLOG maar gewoon bij de DATA laten staan.

Deduplication
Ik heb veel gelezen over deduplication en gezien dat veel mensen het afraden.
Gezien de hardware (CPU) zal dit niet veel invloed hebben op de prestaties denk ik, maar als ik het goed begrijp wordt er 25% van de ARC (totale geheugen -1GB) gebruikt voor deduplication database gebruikt wat eigenlijk zonden is omdat je zoveel mogelijk in het geheugen gecached wil hebben.

Gezien het feit dat we 128GB DDR3 ECC geheugen gaan gebruiken moet dit goed te doen zijn voor een volume van ongeveer 4TB.

[FireDrunk]

Deduplication kost je vooral ook heel veel latency. Je systeem kan een IO opdracht niet meteen verwerken, en daardoor gaat je systeem gewoon echt een bak minder IOPS verstoken.

Dedup is echt: Doe het niet tenzij je niet anders kan. Kijk eerst of Compressie voldoet.

Overigens, wat CiPHER niet aanstipt is: iSCSI is sneller dan NFS. iSCSI ondersteund namelijk fatsoenlijk multipathing en fatsoenlijke failover. Daar mist NFS nogal wat.

Je kan kijken naar NFS 4.1, daar zijn een hoop van die dingen in opgenomen, maar NFS blijft nog steeds een beetje achter op dat gebied.

Wat CiPHER ook niet aanstipt, is dat je met heel mooi ZVOL's kan gebruiken voor iSCSI. Dat betekend dat je netjes per VM een ZFS volume hebt wat je kan verhuizen mocht dat nodig zijn.

Het kan in theorie een voordeel zijn, maar het hoeft niet. Als performance niet van super groot belang is, is NFS het beter protocol. Ga je echt high speed, dan zou ik voor iSCSI gaan.

[ Voor 56% gewijzigd door FireDrunk op 10-08-2015 09:59 ]

[Fr0zenFlame]

Ik ga het wel/niet toepassen van DEDUP even in de groep gooien, ik ben er inderdaad ook geen voorstander van. Wellicht dat compressie en het feit dat we "over allocate" toepassen (disks 70-80GB per VM t.o.v. 200GB allocated) wel voldoende is.

iSCSI vs NFS blijft een lastig punt vind ik;

• XenServer 6.5 doet alleen maar NFSv3 dus NFS4.1 is geen optie helaas.
• We hebben stranks 2x 10GiB glas, en volgens mij kan je tegenwoordig in XenServer wel een network bond configureren (LAG) in IEEE 802.3 AD mode maar vervolgens kan NFS alleen maar 1 touwtje gebruiken voor doorvoer en is de andere voor failover waar iSCSI wel beide kan gebruiken voor doorvoer.
• Verder blijft het bij iSCSI een nadeel dat er op die blocks (bovenop ZFS) een eigen file system komt (NTFS, EXT2, EXT3, EXT4 etc) komt waardoor je de voordelen van ZFS verliest als we het hebben over data intergriteit.

Het gaat in dit geval op Storage Repositories voor XenServer waarom VMs (RDS Servers) komen te staan, deze servers zijn "vervangbaar" maar vormen samen wel een kritisch component. Ik denk wel dat performance het belangrijkste is voor deze PoC dus dat maakt de discussie NFSv3 vs. iSCSI nog lastiger.

[FireDrunk]

Fr0zenFlame schreef op maandag 10 augustus 2015 @ 10:19:
Ik ga het wel/niet toepassen van DEDUP even in de groep gooien, ik ben er inderdaad ook geen voorstander van. Wellicht dat compressie en het feit dat we "over allocate" toepassen (disks 70-80GB per VM t.o.v. 200GB allocated) wel voldoende is.

iSCSI vs NFS blijft een lastig punt vind ik;
[list]
• XenServer 6.5 doet alleen maar NFSv3 dus NFS4.1 is geen optie helaas.
• We hebben stranks 2x 10GiB glas, en volgens mij kan je tegenwoordig in XenServer wel een network bond configureren (LAG) in IEEE 802.3 AD mode maar vervolgens kan NFS alleen maar 1 touwtje gebruiken voor doorvoer en is de andere voor failover waar iSCSI wel beide kan gebruiken voor doorvoer.

Om 2 * 10GiB Glas dicht te trekken richting je storage backend, moet je wel echt van hele goede huize komen... Als het je vooral om IOPS gaat, is 2*10GiB helemaal niet boeiend (het helpt uiteraard wel).
Kijk vooral wat je IOPS targets zijn. Over 1GiB kan je al snel 3000 IOPS sturen, en > 5000 als je op jumbo frames zit. (Als we het over 4K iops hebben)

Is het niet beter om 1 * 10GiB Dedicated voor storage te pakken en de andere 10GiB dedicated voor LAN verkeer. Daarna kan je beide failover maken voor elkaar. (dus als 1 lijn uitvalt, gaan beide over dezelfde lijn).

• Verder blijft het bij iSCSI een nadeel dat er op die blocks (bovenop ZFS) een eigen file system komt (NTFS, EXT2, EXT3, EXT4 etc) komt waardoor je de voordelen van ZFS verliest als we het hebben over data intergriteit.
[/list]

Dat is niet helemaal waar. Je verliest niet persé de data integriteit. Als je netjes write caching uit zet op het filesystem in de VM, en het filesystem honoreert netjes SYNC requests, is in theorie je systeem net zo veilig.

Het gaat in dit geval op Storage Repositories voor XenServer waarom VMs (RDS Servers) komen te staan, deze servers zijn "vervangbaar" maar vormen samen wel een kritisch component. Ik denk wel dat performance het belangrijkste is voor deze PoC dus dat maakt de discussie NFSv3 vs. iSCSI nog lastiger.

Als het alleen om een PoC gaat, waarom dan niet gewoon beide? Het is niet zo dat ze elkaar uitsluiten...
Daarna kan je lekker wat benches doen, en lever die beide opties op in het 'rapport' van je PoC.
Vermeld netjes er bij dat de beheerslast van NFS iets lager is, en (waarschijnlijk) de performance van iSCSI iets hoger is.

En laat management (of whatever) de beslissing lekker zelf nemen

[toelie]

[...]

Als het alleen om een PoC gaat, waarom dan niet gewoon beide? Het is niet zo dat ze elkaar uitsluiten...
Daarna kan je lekker wat benches doen, en lever die beide opties op in het 'rapport' van je PoC.
Vermeld netjes er bij dat de beheerslast van NFS iets lager is, en (waarschijnlijk) de performance van iSCSI iets hoger is.

En laat management (of whatever) de beslissing lekker zelf nemen

Inderdaad, test zowel NFS als iSCSI. Zorg dat je testen voldoende groot zijn zodat niet alles uit je ARC cache wordt opgehaald tijdens de tests. Dit geeft namelijk onrealistische read performance cijfers.

Dedup gaat in jouw specifieke geval trouwens wel vrij veel voordeel geven als al je RDS machines worden gecloned. Dedup is waarschijnlijk weer niet nodig als je 24x 400GB SSD's gaat nemen, dan heb je voldoende schijfruimte.

In mijn testomgeving (2x intel DC S3500 300GB mirror, met 1x intel DC S3700 100GB, 24GB ram, 1x E5-5620 v2) kon ik met gemak 15 geclonede Windows 7 machines draaien. In het begin haalde ik een dedup factor van rond de 8. Na vier maanden aan windows updates en gebruikers geklooi was de dedup factor richting de 5 gegaan.

Kijk ook eens naar de intel DC ssd's. Ze zijn goed verkrijgbaar en hebben volledige powerloss protection en ontzettend lage gemiddelde en max latency waarden in de praktijk.

[FireDrunk]

En ze zijn geschikt om echt zware workloads op te draaien
Ook niet onbelangrijk

[Verwijderd]

S3500 en S3700 hebben twee capacitors aan de zijkant zitten. Ik weet bijna zeker dat dit onvoldoende is om de twee keer 512MiB DRAM packages lang genoeg van prik te voorzien. Vergelijk namelijk eens met de array van kleinere capacitors die op de Intel 320 zit. Deze voorzag enkel de 192KiB interne SRAM buffercache van prik; want de DRAM-chip op de Intel 320 wordt enkel voor het cachen van de mapping tables gebruikt - niet voor user writes die worden in de interne SRAM opgeslagen. SRAM kost veel minder stroom dan DRAM. Van 0.15MiB naar 1024MiB en dan grofweg dezelfde capaciteit aan capacitors is denk ik al een goede reden om sterk te twijfelen aan volledige power-loss protection.

Zeer waarschijnlijk is de bescherming van de S3500 en S3700 equivalent aan dat van de Crucial MX100/MX200 - dus geen volledige bescherming van de buffercache, maar wel eerbiediging van FLUSH commando's dus sync writes genieten wel goede bescherming. En dat is uiteindelijk waar het om draait.

Zelf ben ik wel erg fan van de Crucial MX200 256GB omdat je die kunt gebruiken als een 128GB SLC SSD mits je max 50% van de capaciteit benut. De 512GB+ versies van dezeflde SSD hebben die feature niet; 'DWA' wordt enkel door het 256GB model ondersteund.

FireDrunk schreef op maandag 10 augustus 2015 @ 10:28:
Dat is niet helemaal waar. Je verliest niet persé de data integriteit. Als je netjes write caching uit zet op het filesystem in de VM, en het filesystem honoreert netjes SYNC requests, is in theorie je systeem net zo veilig.

Als je write-back buffercache uit zet, zullen alle writes sync worden. Dat wil je juist absoluut niet; want dit betekent een enorme performance drain.

Het verlies in data-integriteit zit hem in het feit dat ZFS nu enkel de virtuele hardeschijf beschermt; niet je bestanden. Ext4 of NTFS beschermt je bestanden, en ZFS beschermt de virtuele hardeschijf waar Ext4 of NTFS op staat. Dit betekent dat je een situatie kunt hebben waarbij er corruptie op je filesystem is maar ZFS zegt dat je hardeschijf prima consistent en corruptievrij is.

Grofweg denk ik dat je de helft van de voordelen van ZFS verliest. Je behoudt wel de bescherming van de ZVOL maar verliest de directe bescherming van je bestanden. Ook zaken als compressie, snapshots en caching kun je niet meer per dataset regelen; enkel voor de gehele virtuele schijf.

Daarnaast is een groot nadeel dat je enkel SAN-protocollen kunt toepassen; want een Ext4 filesystem kan niet door meerdere computers tegelijk worden gebruikt, zoals wel kan indien je ZFS met NFS gebruikt; dan gebruik je een NAS-protocol. Bij SAN beheert de client het filesystem zelf.

iSCSI kan nuttig zijn als je zoals je zegt per VM een ZVOL maakt - de nadelen kunnen prima beheersbaar zijn. Sommige VM-producten hebben al een interne iSCSI client die gewoon een SCSI disk aan de VM geven. Dat soort constructies kunnen goed bruikbaar zijn. Bovendien kun je de ZVOLs snapshotten voor nog enige vorm van bescherming tegen filesystem corruptie.

Maar mijn grootste punt is precies dat: je verliest nu de detectie van corruptie. Het is nu mogelijk dat je data corrumpeert zonder dat het wordt opgemerkt. Dat vind ik simpelweg niet meer kunnen in dit tijdperk. Het stenen tijdperk zijn we nu toch wel voorbij; met FAT en NTFS en Ext en UFS en HFS. Dat is gewoon van een andere tijd - dat het normaal was dat dingen corrupt raken, crashen of in elkaar donderen. Detectie van corruptie blijft een cruciaal punt waar ZFS zich mee onderscheid. En het is wel zonde als je een constructie kiest waarbij juist die voordelen worden gemarginaliseerd. Mijn eigen voorkeur zou dus een NAS-protocol betreffen, zodat je alle voordelen behoudt omdat de data direct op ZFS wordt opgeslagen.

[Fr0zenFlame]

CiPHER amen ^_-

Dit is ook ongeveer mijn gedachte er over.
Alleen je leest zoveel tegenstellingen m.b.t. NFS en iSCSI waardoor je tussen beide gaat twijfelen.
Het is daarom beter jezelf zoveel mogelijk in de materie te verdiepen en vervolgens een representatieve test te doen met iSCSI en NFSv3.

Op voorhand gaat mijn voorkeur uit naar NFS simpelweg vanwegen de bovengenoemde voordelen in combinatie met de simpelheid. Maar als iSCSI extreme prestatie verschillen gaat laten zien zullen we het moeten overwegen.

Ik baal een beetje van het feit dat je geen NFSv4.1 supported heb in XenServer 6.5, volgens mij kan je wel gewoon zelf mounten op basis van NFSv4.1 met een paar parameters maarja er zal toch een reden voor moeten zijn waarom het niet "Supported" is.

Verder zullen we dan starten zonder deduplication, met compression en zonder een SLOG.
Mochten de prestaties voor zowel iSCSI als NFS tegenvallen kunnen we gaan testen met een ZIL op een SLOG.

Iemand trouwens ervaring met iSCSI op XenServer?
Het mooiste zou zijn natuurlijk om een grote LUN te gebruiken voor je SR waar dan alle VHDs op komen, ik begrijp dat het wellicht beter is om een LUN per VM (VHD) te maken maar dan krijg je wel erg veel SRs in je pool , dat voelt gewoon niet goed en is ook niet erg overzichtelijk...

[FireDrunk]

Verwijderd schreef op maandag 10 augustus 2015 @ 13:43:
Grofweg denk ik dat je de helft van de voordelen van ZFS verliest. Je behoudt wel de bescherming van de ZVOL maar verliest de directe bescherming van je bestanden. Ook zaken als compressie, snapshots en caching kun je niet meer per dataset regelen; enkel voor de gehele virtuele schijf.

Uh, hoezo? Je kan toch meerdere iSCSI volumes maken? Wat is er anders dan op NFS? 1 NFS volume is ook gewoon 1 ZFS Filesystem?

Daarnaast is een groot nadeel dat je enkel SAN-protocollen kunt toepassen; want een Ext4 filesystem kan niet door meerdere computers tegelijk worden gebruikt, zoals wel kan indien je ZFS met NFS gebruikt; dan gebruik je een NAS-protocol. Bij SAN beheert de client het filesystem zelf.

Allemaal leuk, maar dat heeft niets met ESXiXenServer te maken. Het ging om NFS vs iSCSI op ESXi XenServer

iSCSI kan nuttig zijn als je zoals je zegt per VM een ZVOL maakt - de nadelen kunnen prima beheersbaar zijn. Sommige VM-producten hebben al een interne iSCSI client die gewoon een SCSI disk aan de VM geven. Dat soort constructies kunnen goed bruikbaar zijn.

Het is in ESXiVMware land erg bad practice om iSCSI schijven direct in VM's te mounten. Het is sneller om dat op de host te doen. (Ik weet niet of dat ook voor XenServer geldt, maar ik ga er wel vanuit, omdat je dan paravirtualisatie kan gebruiken.)

Bovendien kun je de ZVOLs snapshotten voor nog enige vorm van bescherming tegen filesystem corruptie.

Als je Nexenta met de VAAI integratie gebruikt, kan je zelfs netjes ZVOL's snapshotten vanuit ESXi Dat gaat helaas niet op voor XenServer

Maar mijn grootste punt is precies dat: je verliest nu de detectie van corruptie. Het is nu mogelijk dat je data corrumpeert zonder dat het wordt opgemerkt.

Uh, ik snap dat niet? Je kan toch gewoon een scrub draaien op een ZVOL? Je weet alleen niet in welk bestand het zit, en ZFS zal je hele ZVOL offline halen als je geen redundancy hebt.

Dat vind ik simpelweg niet meer kunnen in dit tijdperk. Het stenen tijdperk zijn we nu toch wel voorbij; met FAT en NTFS en Ext en UFS en HFS. Dat is gewoon van een andere tijd - dat het normaal was dat dingen corrupt raken, crashen of in elkaar donderen. Detectie van corruptie blijft een cruciaal punt waar ZFS zich mee onderscheid. En het is wel zonde als je een constructie kiest waarbij juist die voordelen worden gemarginaliseerd. Mijn eigen voorkeur zou dus een NAS-protocol betreffen, zodat je alle voordelen behoudt omdat de data direct op ZFS wordt opgeslagen.

Allemaal leuk, maar dat helpt nog steeds geen kont bij ESXi XenServer. Je VM's hebben zelf altijd een los filesystem. (Hoewel je natuurlijk ZFS op ZFS kan draaien, maar dat is een andere discussie )

[ Voor 4% gewijzigd door FireDrunk op 10-08-2015 21:42 ]

[Verwijderd]

FireDrunk schreef op maandag 10 augustus 2015 @ 21:40:
Uh, hoezo? Je kan toch meerdere iSCSI volumes maken? Wat is er anders dan op NFS? 1 NFS volume is ook gewoon 1 ZFS Filesystem?

Meerdere iSCSI volumes kun je maken ja - met daarop legacy filesystems. Bij NFS en CIFS dus alle NAS-protoclllen, is het werkelijke filesystem ZFS zelf en is het protocol enkel een manier andere computers bestanden te kunnen delen zonder dat zij kennis nodig hebben welk filesystem het precies betreft, oftewel: filesystem-agnostisch. De server beheert het filesystem en slaat dus alle bestanden op, de client geeft door welk bestand wat mee moet gebeuren (VFS-laag equivalent).

Bij iSCSI is het andersom: de client beheert het filesystem (Ext4) terwijl ZFS slechts een doorgeefluik is van read en writes met een bepaalde LBA offset en length. Nou leuk. Kun je natuurlijk niets mee. Je hebt geen toegang tot de data. Je kan zien of ZFS een consistente kopie van de virtual harddisk image heeft, maar je weet verder niets over de integriteit van de data zelf. Die zit geëncapsuleerd in een legacy filesystem die op één van de partities staat op één van de virtual harddisks (ZVOL) staan, en die ZVOL wordt door ZFS opgeslagen en beheert.

Bij NFS mount je gewoon een filesystem node ('directory') en je ziet de bestanden maar hebt verder niet complete kennis over wat ZFS doet; compressie/dedup/copies/l1cache/l2cache - alles is verscholen voor de client. Alleen de server weet wat er echt met de data gebeurt. Hierdoor kun je dus ook dezelfde data met meerdere computers delen. Dat kan niet zomaar met iSCSI, waarbij je niet zomaar dezelfde iSCSI-volume door twee computers read-write mag mounten; daar kun je ernstige filesystem corruptie van krijgen met grootschalige vernietiging van gegevens. Ook voor ZFS geldt dit; daarom moet je import -f parameter gebruiken als je wilt importeren terwijl de pool door een andere computer (hostid) als laatste is gemount.

Je weet ongetwijfeld 99% van het bovenstaande; maar waar zit hem de 1% in dat we elkaar nog niet goed begrijpen?

[FireDrunk]

Als je NFS gebruikt voor Datastores voor een HyperVisor, gebruik je nog steeds een Virtual Disk voor de VM's. Zoals jij het doet blijken, slaan de VM's hun data direct op, op de NFS share. Dat is niet zo.

Daar zit het verschil.

Je kan niet (dat kan alleen bij Jails van BSD en Containers onder Linux) VM's maken van files direct op een ZFS filesystem.

[dcm360]

En er bestaat ook nog een mogelijkheid die een beetje tussen die twee in hangt: een hypervisor die doorheeft wat een ZVOL is, en dat daar snapshots en clones van gemaakt kunnen worden. Hiermee kom je wat voor- en nadelen betreft een beetje tussen ruw NFS en iSCSI in.

[HyperBart]

Niet echt, dat bestaat al langer: VAAI.

http://www.vmware.com/resources/techresources/10337

Nexenta bood daar ondersteuning voor aan dacht ik.

[CurlyMo]

FireDrunk schreef op maandag 10 augustus 2015 @ 22:53:
Je kan niet (dat kan alleen bij Jails van BSD en Containers onder Linux) VM's maken van files direct op een ZFS filesystem.

Ik snap deze zin eigenlijk niet zo goed. Een ZVOL als VirtualBox image werkt toch prima of is dat niet wat je bedoelt?

[FireDrunk]

Ik bedoel, er zijn weinig manieren om de files die in een VM leven echt de volle 100% van de bescherming te geven van het ZFS filesystem van je host OS.

Daar moet altijd een laagje tussen.

[CurlyMo]

Doet een ZVOL dat niet?

[matty___]

Voor de FreeBSD users met een L2ARC komt er binnenkort een patch uit:

https://svnweb.freebsd.or...=revision&revision=286570
Currently, every buffer cached in the L2ARC is accompanied by a 240-byte
header in memory, leading to very high memory consumption when using very
large cache devices. These changes significantly reduce this overhead.

....

For an average blocksize of 8KB, this means that for the L2ARC, the ratio
of metadata to data has gone down from about 2.92% to 1.56%. For a
'storage optimized' EC2 instance with 1600GB of SSD and 60GB of RAM, this
means that we expect a completely full L2ARC to use (1600 GB * 0.0156) /
60GB = 41% of the available memory, down from 78%.

[Verwijderd]

De verwarring zat hem erin dat FireDrunk doelt op VM-producten die intern een iSCSI client gebruiken om vervolgens een normale SCSI-disk aan de VM te geven. Normaliter kan een VM niet direct een iSCSI disk gebruiken (behalve met PXE kan dat).

Dus ik dacht aan het mounten van iSCSI door de hypervisor, waar vervolgens de disk images op staan. In dat geval is het dus dubbel: ZFS -> ZVOL -> iSCSI -> NTFS -> en daarop dus een .vmdk disk image. Dan heb je dus dubbel geëncapsuleerd. Bij VirtualBox ontkom je daar niet aan, maar sommige VM-producten hebben een interne iSCSI client die vervolgens een normale SCSI disk emuleert aan de VM. Dan heb je dus een stap minder.

@FireDrunk: je hebt zeker wel een goed punt dat het niet meer zoveel uitmaakt als je dus een VM-product hebt wat dit kan, want zoals je zegt is het erg lastig om de bestanden van de guest VM zelf op ZFS te krijgen. Dat werkt vrijwel altijd met een block-container. Jails zou ik geen virtualisatie willen noemen; hooguit privilege separation/security zoals Capsicum dat is - of een soort veredelde chroot. Wat ik zelf heel gaaf vind, is dat met bhyve mogelijk zou moeten worden om je guest VM direct files van ZFS te laten plukken en hier ook direct van te booten. Voorwaarde is wel dat zowel de guest als host BSD is.

[dcm360]

VirtualBox is dan wel een slecht voorbeeld, want ook die kan een iSCSI-disk koppelen aan een VM. Weliswaar niet vanuit de GUI, maar het kan wel.

[Verwijderd]

Oh, dat heb ik nooit geweten.

Ik ken alleen de verborgen 'createrawvmdk' functionaliteit om ruwe disks of partities door te geven.

[FireDrunk]

Verwijderd schreef op dinsdag 11 augustus 2015 @ 12:57:
De verwarring zat hem erin dat FireDrunk doelt op VM-producten die intern een iSCSI client gebruiken om vervolgens een normale SCSI-disk aan de VM te geven. Normaliter kan een VM niet direct een iSCSI disk gebruiken (behalve met PXE kan dat).

VMWare (ESXi) kan dit prima, dat heet RAW Device Mapping, en werkt eigenlijk prima! De performance daar van is vele malen hoger, dan een iSCSI disk binnen de VM laden.

Dus ik dacht aan het mounten van iSCSI door de hypervisor, waar vervolgens de disk images op staan. In dat geval is het dus dubbel: ZFS -> ZVOL -> iSCSI -> NTFS -> en daarop dus een .vmdk disk image. ZFS -> ZVOL -> iSCSI -> VMFS -> VMDK -> NTFS. Dan heb je dus dubbel geëncapsuleerd. Bij VirtualBox ontkom je daar niet aan, maar sommige VM-producten hebben een interne iSCSI client die vervolgens een normale SCSI disk emuleert aan de VM. Dan heb je dus een stap minder.

Fixed that for you

@FireDrunk: je hebt zeker wel een goed punt dat het niet meer zoveel uitmaakt als je dus een VM-product hebt wat dit kan, want zoals je zegt is het erg lastig om de bestanden van de guest VM zelf op ZFS te krijgen. Dat werkt vrijwel altijd met een block-container. Jails zou ik geen virtualisatie willen noemen; hooguit privilege separation/security zoals Capsicum dat is - of een soort veredelde chroot. Wat ik zelf heel gaaf vind, is dat met bhyve mogelijk zou moeten worden om je guest VM direct files van ZFS te laten plukken en hier ook direct van te booten. Voorwaarde is wel dat zowel de guest als host BSD is.

Yes! Je begrijpt me!

[Verwijderd]

Hi Gents,

Ik draai al enige tijd Freebsd 9.2 met ZFS. Zeer tevreden.

Ik wil echter de overstap naar Debian met ZoL maken omdat ik diverse applicaties wil draaien die onder FreeBSD niet (goed genoeg) werken.

Op dit moment draai ik ZFS versie 28 met featureflags (v5000?)
Heeft ZoL hier al support voor en kan ik de pool probleemloos exporten en importen?

code:

root@storage:/ # zpool get all storage
NAME     PROPERTY                       VALUE                          SOURCE
storage  size                           54.4T                          -
storage  capacity                       82%                            -
storage  altroot                        -                              default
storage  health                         ONLINE                         -
storage  guid                           17722407170639032000           default
storage  version                        -                              default
storage  bootfs                         -                              default
storage  delegation                     on                             default
storage  autoreplace                    off                            default
storage  cachefile                      -                              default
storage  failmode                       wait                           default
storage  listsnapshots                  off                            default
storage  autoexpand                     off                            default
storage  dedupditto                     0                              default
storage  dedupratio                     1.00x                          -
storage  free                           9.51T                          -
storage  allocated                      44.9T                          -
storage  readonly                       off                            -
storage  comment                        -                              default
storage  expandsize                     0                              -
storage  freeing                        0                              default
storage  feature@async_destroy          enabled                        local
storage  feature@empty_bpobj            enabled                        local
storage  feature@lz4_compress           enabled                        local
storage  feature@multi_vdev_crash_dump  enabled                        local
storage  feature@spacemap_histogram     active                         local
storage  feature@enabled_txg            active                         local
storage  feature@hole_birth             active                         local
storage  feature@extensible_dataset     enabled                        local
storage  feature@bookmarks              enabled                        local
storage  feature@filesystem_limits      enabled                        local

[ Voor 77% gewijzigd door Verwijderd op 11-08-2015 19:31 ]

[CurlyMo]

Verwijderd schreef op dinsdag 11 augustus 2015 @ 19:28:
Hi Gents,

Ik draai al enige tijd Freebsd 9.2 met ZFS. Zeer tevreden.

Ik wil echter de overstap naar Debian met ZoL maken omdat ik diverse applicaties wil draaien die onder FreeBSD niet (goed genoeg) werken.

Zou je hier niet beter advies op kunnen vragen?

Op dit moment draai ik ZFS versie 28 met featureflags (v5000?)
Heeft ZoL hier al support voor en kan ik de pool probleemloos exporten en importen?

Heb je dat zelf al gewoon eens geprobeerd met een live cd?

[Verwijderd]

CurlyMo schreef op dinsdag 11 augustus 2015 @ 20:05:
[...]

Zou je hier niet beter advies op kunnen vragen?


[...]

Heb je dat zelf al gewoon eens geprobeerd met een live cd?

Nee. Het is een productie systeem.

[CurlyMo]

Exporteren en importeren is gewoon zonder gevaar. Als hij niet geïmporteerd kan worden, dan krijg je een melding.

[Verwijderd]

Snap ik. Maar het blijft een systeem in productie die ik niet offline wil halen om testjes mee uit te voeren.

Ik zoek naar iemand die ervaring heeft met deze actie.

[FireDrunk]

Trek een snapshot.
Pak een tijdelijke disk
Maak een pool op de disk.
ZFS send je snapshot naar de nieuwe pool.
Koppel de disk los.
Pak een test machine.
Boot met Gentoo DVD.
import de pool.

Kijk.

offtopic:
Als ik te bot ben. Dadona 's schuld

[ Voor 22% gewijzigd door FireDrunk op 11-08-2015 22:07 ]

[A1AD]

FireDrunk schreef op dinsdag 11 augustus 2015 @ 21:57:

offtopic:
Als ik te bot ben. Dadona 's schuld

Niets bot, efficient

[CurlyMo]

Een beetje zoekwerk levert alle informatie op die je zoekt (o.a. in de TS dus):
CurlyMo in "Het grote ZFS topic"
http://open-zfs.org/wiki/Feature_Flags

Ik ben trouwens benieuwd hoe je mogelijk gaat migreren naar Debian zonder je systeem offline te halen.

En als je zo bang bent voor de data, waarom heb je jezelf dan niet eerder ingelezen over deze feature flags of er advies over gevraagd. Iedereen "met ervaring" had je hier hetzelfde antwoord gegeven.

Een nog veel snellere optie is een zpool op een USB stick in FreeBSD maken mét alle feature flags en deze vervolgens importeren in Debian. Dan weet je het gauw genoeg.

[BartNL]

ZFSguru 0.3.pre-release beetje te laat gezien, misschien later deze week eens kijken. NAS nog in test dus beetje pre-release bug kan geen kwaad

[DXaroth]

dus in plaats van een release op de 1e een pre-release de 11e, ben blij dat ik daar niet op heb zitten wachten

[FireDrunk]

Er is in ieder geval iets

[BartNL]

het is niet zo moeilijk na te gaan dat wanneer je regelmatige updates verwacht NAS4Free en FreeNAS meer je ding zullen zijn

[Verwijderd]

FireDrunk schreef op dinsdag 11 augustus 2015 @ 21:57:

offtopic:
Als ik te bot ben. Dadona 's schuld

Dat ben ik van Tweakers inmiddels wel gewend. Er worden vaak direct en vaak onjuiste conclusies getrokken.

CurlyMo schreef op dinsdag 11 augustus 2015 @ 22:57:
Een beetje zoekwerk levert alle informatie op die je zoekt (o.a. in de TS dus):
CurlyMo in "Het grote ZFS topic"
http://open-zfs.org/wiki/Feature_Flags

Ik ben trouwens benieuwd hoe je mogelijk gaat migreren naar Debian zonder je systeem offline te halen.

En als je zo bang bent voor de data, waarom heb je jezelf dan niet eerder ingelezen over deze feature flags of er advies over gevraagd. Iedereen "met ervaring" had je hier hetzelfde antwoord gegeven.

Een nog veel snellere optie is een zpool op een USB stick in FreeBSD maken mét alle feature flags en deze vervolgens importeren in Debian. Dan weet je het gauw genoeg.

Ook hier worden direct weer rare conclusies getrokken.
Ik ben niet bang voor mijn data. Zoals ik aangaf is het een productie systeem en word er dagelijks gebruik van gemaakt. Een migratie moment moet er komen maar het systeem gebruiken als testmachine met live CD's en tijdelijke diskjes neemt onacceptabele en downtime met zich mee die voorkomen had kunnen worden.

Dit systeem is al bijna 4 jaar in productie. Jij gaat mij echt niet wijsmaken dat jij 4 jaar vooruit denkt of uberhaupt kan denken. Gezien de ontwikkelingen rondom het systeem continue doorgaan is het voor mij in ieder geval onmogelijk.

Vaak spelen andere factoren ook mee en is iets verder denken dan de techniek ook belangrijk.

[CurlyMo]

Verwijderd schreef op woensdag 12 augustus 2015 @ 10:09:
Dit systeem is al bijna 4 jaar in productie. Jij gaat mij echt niet wijsmaken dat jij 4 jaar vooruit denkt of uberhaupt kan denken.

Dat ben ik toch niet met je eens en is de persoonlijke aanval is al helemaal onnodig. We helpen je hier graag. Soms wat directer dan dat je gewend bent, maar wel allemaal vrijwillig en met de beste bedoelingen! Het antwoord stond overigens gewoon in die post vermeld.

Feature flags waren er niet opeens. Er is altijd en overal al gezegd dat als je de beste uitwisselbaarheid wil met andere ZFS implementaties je gewoon op v28 moet blijven. Ergens in deze 4 jaar heb jij toch invloed uitgeoefend op die feature flags en ze aangezet. Bewust of onbewust.

In mijn geval ben ik lang op v28 gebleven totdat ik zelf genoeg informatie had over de consequenties van het aanzetten van de flags. Toen ik die informatie had, ben ik gaan gaan testen in een test omgeving wat precies het verschil is tussen de verschillende stadia van de flags (zie mijn post hier). Daarna ben ik een paar van die feature flags gaan gebruiken en ook een aantal niet. Juist om uitwisselbaarheid met andere ZFS implementaties te behouden.

In jouw geval staan er vrij recente flags actief (filesystem_limits). Naar mijn idee heb je deze dus aangezet zonder je bewust te zijn van de consequenties. En naar mijn idee moet een sysadmin juist bewust zijn van de consequenties van zijn acties. Als je ze met voldoende voorinformatie had aangezet en wist wat je deed, dan had je ook het antwoord gehad op je aanvankelijke vraag.

[FireDrunk]

Als we nu met z'n allen niet proberen de schuld van zijn probleem te achterhalen, maar proberen om zijn probleem op te lossen

Heb je al gekeken naar het idee wat ik uitlegde? Want dat is wel een snelle oplossing om van het live systeem een testje te kunnen doen zonder dat het productie raakt.

[CurlyMo]

FireDrunk schreef op woensdag 12 augustus 2015 @ 12:48:
Als we nu met z'n allen niet proberen de schuld van zijn probleem te achterhalen, maar proberen om zijn probleem op te lossen

Het antwoord is al gegeven in mijn post a.d.v. die links. Het is alleen niet een voorgekauwd antwoord, maar die linkjes geven tevens aan waar je de info kan vinden om dit probleem in de toekomst te voorkomen. Typisch tweakers geneuzel dus
En mijn USB tip is nog veel makkelijker.

We proberen dus heus wel te helpen

[ Voor 19% gewijzigd door CurlyMo op 12-08-2015 12:58 ]

[FireDrunk]

Mijn disk kan inderdaad vervangen worden met een USB disk.

[CurlyMo]

Waarom zou je eerst de data van pool op de USB stick zetten? Gewoon een lege pool maken en er een paar dummy bestanden opzetten moet toch voldoende zijn?

[FireDrunk]

Dan moet hij wel met de hand de feature flags meenemen.
Hmm, hoewel hij dat sowieso al moet want die komen natuurlijk niet mee met het snapshot.

Jouw idee van een pootje op USB aanmaken is dus inderdaad beter.

[ Voor 20% gewijzigd door FireDrunk op 12-08-2015 20:23 ]

[Verwijderd]

Bedankt voor de informatie.

Toch denk ik dat de featureflags bij default aanstaan op FreeBSD9.3. Ik heb ze iig niet aangezet want ik gebruik ze ook niet.

Ik kan me ook herinneren dat ik ooit wilde overstappen naar FreeBSD 10.x maar dat dit niet lukte omdat deze een BSD9.3 aangemaakte pool niet wilde importeren i.v.m. versie verschil van de pool welke ZFS op BSD10.x sowieso niet ondersteunde.

Hoe dan ook; Het plan is in ieder geval om een virtuele machine met FreeBSD9.3 met test pool zo identiek mogelijk te krijgen aan de productie machine om vervolgens de test pool in een Debian VM te importeren.

Gevonden:
Wikipedia: ZFS
"LLNL's ZFS on Linux 0.6.1 = V5000"

[CurlyMo]

Ik heb nog steeds het idee dat je de linkjes niet hebt geopend die ik heb gepost. Daar staat namelijk per feature flags per OpenZFS implementatie in of het wordt ondersteunt. Dan zie je ook dat je jouw pool niet kan importeren in ZOL aangezien ZOL de FF filesystem_limits niet ondersteund (hetzij alleen readonly). Aan het simpele feit dat ZOL op V5000 zit zegt daarin niks. Dat is het hele idee dan ook van de FF. Misschien is het goed om eerst eens goed te begrijpen wat nu de filosofie van de ontwikkelaars was bij het invoeren van de FF. Daarover is ook genoeg informatie te vinden.

Daarnaast klopt wat je zegt. Standaard wordt bij het aanmaken of upgraden van een zpool alle FF aangezet. Jij als sysadmin moet er voor zorgen dat dit niet gebeurt, wat inderdaad ook weer minder voor de hand liggend werkt als je denkt. Dat heb ik echter in verschillende samenvattende posts hier uitgelegd.

Je hebt dan ook helemaal niet zoveel stappen nodig om te zien of je pool wel of niet te importeren is. Kijk gewoon in die tabel op de OpenZFS site en je weet voldoende.

[matty___]

Verwijderd schreef op donderdag 13 augustus 2015 @ 10:34:

Ik kan me ook herinneren dat ik ooit wilde overstappen naar FreeBSD 10.x maar dat dit niet lukte omdat deze een BSD9.3 aangemaakte pool niet wilde importeren i.v.m. versie verschil van de pool welke ZFS op BSD10.x sowieso niet ondersteunde.

Dat lijkt mij beetje raar. FB10 kan zeker een oude pool importeren. Anders om juist niet.

[matty___]

CurlyMo schreef op donderdag 13 augustus 2015 @ 10:54:

Daarnaast klopt wat je zegt. Standaard wordt bij het aanmaken of upgraden van een zpool alle FF aangezet. Jij als sysadmin moet er voor zorgen dat dit niet gebeurt, wat inderdaad ook weer minder voor de hand liggend werkt als je denkt. Dat heb ik echter in verschillende samenvattende posts hier uitgelegd.

Feature states
Features can be in one of three states:

active This feature's on-disk format changes are in effect on the
pool. Support for this feature is required to import the pool
in read-write mode. If this feature is not read-only compati-
ble, support is also required to import the pool in read-only
mode (see "Read-only compatibility").

enabled An administrator has marked this feature as enabled on the
pool, but the feature's on-disk format changes have not been
made yet. The pool can still be imported by software that does
not support this feature, but changes may be made to the
on-disk format at any time which will move the feature to the
active state. Some features may support returning to the
enabled state after becoming active. See feature-specific doc-
umentation for details.

disabled This feature's on-disk format changes have not been made and
will not be made unless an administrator moves the feature to
the enabled state. Features cannot be disabled once they have
been enabled.

Volgens mij gaat die niet zomaar van alles op enabled active zetten.
Enabled is het probleem niet omdat je hem nog steeds kunt importeren

[CurlyMo]

Hier staat het allemaal precies uitgelegd:
CurlyMo in "Het grote ZFS topic"

En hier hoe je van v28 naar v5000 gaat zonder alle FF op enabled te zetten:
CurlyMo in "Het grote ZFS topic"

[ Voor 39% gewijzigd door CurlyMo op 13-08-2015 12:38 ]

[FireDrunk]

matty___ schreef op donderdag 13 augustus 2015 @ 11:10:
[...]

Dat lijkt mij beetje raar. FB10 kan zeker een oude pool importeren. Anders om juist niet.

FreeBSD 9.3-STABLE kan verder zijn dan 10.0-RELEASE natuurlijk

[matty___]

FireDrunk schreef op donderdag 13 augustus 2015 @ 14:27:
[...]


FreeBSD 9.3-STABLE kan verder zijn dan 10.0-RELEASE natuurlijk

Volgens mij is 10.0 na 9.3 gereleased. Ook patches gaan van boven naar beneden. Hoe dan ook denk ik niet dat de ZFS stack op 10.0 ouder is dan op 9-Stable

Lijkt mij buitengewoon raar als dat wel zo zou zijn. De overgang naar v28 5000 was volgens mij in 8.x of 9.0

[Verwijderd]

FreeBSD 9-STABLE != FreeBSD 9.3. 9-STABLE is wat 9.4 ging worden, en regelmatig ontvangt -STABLE patches van -CURRENT; dat wordt MFC genoemd; MergeFromCurrent.

[matty___]

Verwijderd schreef op donderdag 13 augustus 2015 @ 16:08:
FreeBSD 9-STABLE != FreeBSD 9.3. 9-STABLE is wat 9.4 ging worden, en regelmatig ontvangt -STABLE patches van -CURRENT; dat wordt MFC genoemd; MergeFromCurrent.

Dan heb je het security patches etc en zware bugs die van Current naar 9 gaan als 10 de laatste release is.
Aan 9 wordt nu amper nog iets gedaan anders dan onderhoud.

ZFS versie ophogen valt daar niet onder. Maar goed kwestie van uitproberen.

[Compizfox]

Vraagje: ik heb nog een oude FreeBSD 10.1-RC1 install draaien die nog naar 10.1-RELEASE moet worden geupgraded. Ik heb echter de kernel source nodig. Hoe kom ik daaraan?

Op internet wordt gezegd dat het te vinden moet zijn op ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/, maar daar staat 10.1-RC1 niet tussen...

[matty___]

Compizfox schreef op donderdag 13 augustus 2015 @ 16:37:
Vraagje: ik heb nog een oude FreeBSD 10.1-RC1 install draaien die nog naar 10.1-RELEASE moet worden geupgraded. Ik heb echter de kernel source nodig. Hoe kom ik daaraan?

Op internet wordt gezegd dat het te vinden moet zijn op ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/, maar daar staat 10.1-RC1 niet tussen...

FreeBSD github repo naar /usr/src uitchecken en juiste branch kiezen

Maar wacht nog paar dagen dan zit je op 10.2

[Verwijderd]

matty___ schreef op donderdag 13 augustus 2015 @ 16:36:
[...]

Dan heb je het security patches etc en zware bugs die van Current naar 9 gaan als 10 de laatste release is.
Aan 9 wordt nu amper nog iets gedaan anders dan onderhoud.

ZFS versie ophogen valt daar niet onder. Maar goed kwestie van uitproberen.

Ik weet niet wat je precies bedoelt maar in RELENG_9 (9-STABLE) komen gewoon regelmatig commits binnen. Je kunt ze hier volgen: http://freshbsd.org/searc...t=freebsd&branch=RELENG_9.

Ik volg alleen 10-STABLE en 11-CURRENT.

Maar bijvoorbeeld ZFS updates komen eerst in 11-CURRENT en daarna MFC naar 10-STABLE en 9-STABLE. Niet alles komt in 9-STABLE, en ook niet alles gaat van 11-CURRENT naar 10-STABLE. Maar wel veel.

FreeBSD 9.x heeft regelmatig updates voor ZFS gekregen en dat gaat altijd eerst via -STABLE totdat -STABLE gebranched wordt naar RELENG_9_4 bijvoorbeeld en vanaf dat moment is -STABLE wat uiteindelijk 9.5 gaat worden.

@Compizfox: als dit gaat om ZFSguru 0.2: installeer de Sourcecode onder Misc. Services. Dan heb je /usr/src die bij het systeem hoort. Dan een GENERIC kernel bakken:

make -C /usr/src buildkernel KERNCONF=GENERIC
make -C /usr/src installkernel KERNCONF=GENERIC

Daarna - na het rebooten naar je nieuwe GENERIC kernel - kun je freebsd-update gebruiken voor binary updates. Dat is veel beter dan zelf updaten want vergeet niet dat je dan ook mergemaster moet draaien en dat is veelal te ingewikkeld voor mensen die niet goed met BSD bekend zijn. Het is niet iets wat je voor je plezier doet...

[Compizfox]

Verwijderd schreef op donderdag 13 augustus 2015 @ 16:57:
[...]
@Compizfox: als dit gaat om ZFSguru 0.2: installeer de Sourcecode onder Misc. Services. Dan heb je /usr/src die bij het systeem hoort. Dan een GENERIC kernel bakken:

Oja, daar had ik nog niet aan gedacht. Het gaat inderdaad om ZFSGuru en dat lijkt me de makkelijkste methode

make -C /usr/src buildkernel KERNCONF=GENERIC
make -C /usr/src installkernel KERNCONF=GENERIC

Daarna - na het rebooten naar je nieuwe GENERIC kernel - kun je freebsd-update gebruiken voor binary updates.

Dat was ik ook van plan

Dat is veel beter dan zelf updaten want vergeet niet dat je dan ook mergemaster moet draaien en dat is veelal te ingewikkeld voor mensen die niet goed met BSD bekend zijn. Het is niet iets wat je voor je plezier doet...

Met zelf updaten bedoel je deze procedure? Dat heb ik nog nooit gedaan. Ik heb wel eens eerder een ZFSGuru-bak geupgraded met freebsd-update

[matty___]

Verwijderd schreef op donderdag 13 augustus 2015 @ 16:57:


make -C /usr/src buildkernel KERNCONF=GENERIC
make -C /usr/src installkernel KERNCONF=GENERIC

of in /usr/src: make -j4 kernel

default is altijd GENERIC.
-j4 zijn de parallele jobs. Dus de hoeveelheid cpu cores die je hebt.
kernel = buildkernel installkernel

Daarna - na het rebooten naar je nieuwe GENERIC kernel - kun je freebsd-update gebruiken voor binary updates. Dat is veel beter dan zelf updaten want vergeet niet dat je dan ook mergemaster moet draaien en dat is veelal te ingewikkeld voor mensen die niet goed met BSD bekend zijn. Het is niet iets wat je voor je plezier doet...

Hij past enkel de default bestanden aan. Waar je dus op moet letten is dat je je /etc/master.passwd en /etc/group en /etc/sysctl.conf niet overschrijft.
/etc/rc.conf /boot/loader.conf worden niet geraakt door de mergemaster

Alle andere moet je juist wel overschrijven.

Kwestie van 1 keer doen en tig keer ESC en 3 keer d van delete temp en tig keer i van install (zo uit mijn hoofd)

[ Voor 51% gewijzigd door matty___ op 13-08-2015 17:18 ]

[Verwijderd]

1: FreeBSD 9.3 geïnstalleerd in een VM
2: Zpool aangemaakt met 3 disks
3: Output van "zpool get all <pool>" vergeleken met de productie pool

code:

root@freebsd-test:/usr/home/frank # zpool get all tank
NAME  PROPERTY                       VALUE                          SOURCE
tank  size                           23.8G                          -
tank  capacity                       0%                             -
tank  altroot                        -                              default
tank  health                         ONLINE                         -
tank  guid                           8177764047655959869            default
tank  version                        -                              default
tank  bootfs                         -                              default
tank  delegation                     on                             default
tank  autoreplace                    off                            default
tank  cachefile                      -                              default
tank  failmode                       wait                           default
tank  listsnapshots                  off                            default
tank  autoexpand                     off                            default
tank  dedupditto                     0                              default
tank  dedupratio                     1.00x                          -
tank  free                           23.8G                          -
tank  allocated                      133K                           -
tank  readonly                       off                            -
tank  comment                        -                              default
tank  expandsize                     0                              -
tank  freeing                        0                              default
tank  feature@async_destroy          enabled                        local
tank  feature@empty_bpobj            enabled                        local
tank  feature@lz4_compress           enabled                        local
tank  feature@multi_vdev_crash_dump  enabled                        local
tank  feature@spacemap_histogram     active                         local
tank  feature@enabled_txg            active                         local
tank  feature@hole_birth             active                         local
tank  feature@extensible_dataset     enabled                        local
tank  feature@bookmarks              enabled                        local
tank  feature@filesystem_limits      enabled                        local

4: Pool export

5: Debian geïnstalleerd met ZOL
6: Zpool import <pool> (Gelukt!)
7: zpool output:

code:

root@debian-test:/home/frank# zpool get all tank
NAME  PROPERTY                                      VALUE                                         SOURCE
tank  size                                          23.8G                                         -
tank  capacity                                      0%                                            -
tank  altroot                                       -                                             default
tank  health                                        ONLINE                                        -
tank  guid                                          8177764047655959869                           default
tank  version                                       -                                             default
tank  bootfs                                        -                                             default
tank  delegation                                    on                                            default
tank  autoreplace                                   off                                           default
tank  cachefile                                     -                                             default
tank  failmode                                      wait                                          default
tank  listsnapshots                                 off                                           default
tank  autoexpand                                    off                                           default
tank  dedupditto                                    0                                             default
tank  dedupratio                                    1.00x                                         -
tank  free                                          23.8G                                         -
tank  allocated                                     306K                                          -
tank  readonly                                      off                                           -
tank  ashift                                        0                                             default
tank  comment                                       -                                             default
tank  expandsize                                    -                                             -
tank  freeing                                       0                                             default
tank  fragmentation                                 0%                                            -
tank  leaked                                        0                                             default
tank  feature@async_destroy                         enabled                                       local
tank  feature@empty_bpobj                           enabled                                       local
tank  feature@lz4_compress                          active                                        local
tank  feature@spacemap_histogram                    active                                        local
tank  feature@enabled_txg                           active                                        local
tank  feature@hole_birth                            active                                        local
tank  feature@extensible_dataset                    enabled                                       local
tank  feature@embedded_data                         disabled                                      local
tank  feature@bookmarks                             enabled                                       local
tank  [e-mail]:multi_vdev_crash_dump  inactive                                      local
tank  [e-mail]:filesystem_limits      inactive                                      local

code:

root@debian-test:/home/frank# zpool status
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.

8: zpool upgrade <pool>

code:

root@debian-test:/home/frank# zpool upgrade tank
This system supports ZFS pool feature flags.

Enabled the following features on 'tank':
  embedded_data

code:

root@debian-test:/home/frank# zpool status
  pool: tank
 state: ONLINE
  scan: none requested

Kortom. Mooi spul!

[Compizfox]

matty___ schreef op donderdag 13 augustus 2015 @ 17:05:
[...]

Hij past enkel de default bestanden aan. Waar je dus op moet letten is dat je je /etc/master.passwd en /etc/group en /etc/sysctl.conf niet overschrijft.
/etc/rc.conf /boot/loader.conf worden niet geraakt door de mergemaster

Alle andere moet je juist wel overschrijven.

Kwestie van 1 keer doen en tig keer ESC en 3 keer d van delete temp en tig keer i van install (zo uit mijn hoofd)

Ik heb iets van 2x een ZFSGuru install geupgraded met behulp van freebsd-update. Beide keren moest ik echter iets van 30 bestanden handmatig mergen, terwijl alleen de comment bovenaan met daarin het versienummer is aangepast. Het zou fijn zijn geweest als ik op accept new version of iets dergelijks had kunnen klikken, maar die mogelijkheid is er niet: je moet per bestand handmatig de oude regel weghalen + de junk die de merging tool eromheen zet.

Vrij irritant, vroeg me eigenlijk al af of dat wel normaal is.

[matty___]

Compizfox schreef op donderdag 13 augustus 2015 @ 20:39:
[...]

Ik heb iets van 2x een ZFSGuru install geupgraded met behulp van freebsd-update. Beide keren moest ik echter iets van 30 bestanden handmatig mergen, terwijl alleen de comment bovenaan met daarin het versienummer is aangepast. Het zou fijn zijn geweest als ik op accept new version of iets dergelijks had kunnen klikken, maar die mogelijkheid is er niet: je moet per bestand handmatig de oude regel weghalen + de junk die de merging tool eromheen zet.

Vrij irritant, vroeg me eigenlijk al af of dat wel normaal is.

Mergemaster -F

[FireDrunk]

Daar kan freebsd nog aardig wat aan verbeteren ja..
(en/of leren van Linux... of zelfs windows...)

[Compizfox]

matty___ schreef op donderdag 13 augustus 2015 @ 21:19:
[...]

Mergemaster -F

Ja, wat moet ik daarmee? Zover ik weet kan ik dat niet gebruiken met freebsd-update.

[matty___]

Compizfox schreef op donderdag 13 augustus 2015 @ 21:23:
[...]

Ja, wat moet ik daarmee? Zover ik weet kan ik dat niet gebruiken met freebsd-update.

Ok wist ik niet dat dit niet kon. Gebruik Bin update nooit.

[matty___]

FireDrunk schreef op donderdag 13 augustus 2015 @ 21:22:
Daar kan freebsd nog aardig wat aan verbeteren ja..
(en/of leren van Linux... of zelfs windows...)

Het is geen rocket science en dit doe je nu ook niet wekelijks.
Met apt-get zie ik van alles maar geen idee wat die nu doet.

[Compizfox]

matty___ schreef op donderdag 13 augustus 2015 @ 21:36:
[...]

Het is geen rocket science en dit doe je nu ook niet wekelijks.
Met apt-get zie ik van alles maar geen idee wat die nu doet.

Het punt is meer dat dpkg (bijvoorbeeld) merges veel beter doet dan freebsd-update. Bij dpkg kan ik gewoon kiezen voor install package maintainer's version of keep your version, bijvoorbeeld. Bovendien krijg je die prompt enkel en alleen als er veranderingen in config files zijn waarin jij wijzigingen hebt aangebracht.

[CurlyMo]

@thelightning87, zolang filesystem_limits enabled blijft en niet actief wordt zit je veilig.

[matty___]

Compizfox schreef op donderdag 13 augustus 2015 @ 22:18:
[...]

Het punt is meer dat dpkg (bijvoorbeeld) merges veel beter doet dan freebsd-update. Bij dpkg kan ik gewoon kiezen voor install package maintainer's version of keep your version, bijvoorbeeld. Bovendien krijg je die prompt enkel en alleen als er veranderingen in config files zijn waarin jij wijzigingen hebt aangebracht.

En mijn punt is dat je hetzelfde gedrag met mergemaster -F krijgt als je een build from source doet. Misschien dat er ook zo iets bij freebsd-update is. Keertje opzoeken want de functionaliteit zit in mergemaster en kan mij niet voorstellen dat de binary update een ander mechanisme voor het mergen gebruikt.

edit: Blijkbaar kun je een /etc/mergemaster.rc aanmaken met de default instellingen met bv dit erin:
AUTO_INSTALL='yes'
AUTO_UPGRADE='yes'
# keep our custom motd
IGNORE_FILES='/etc/motd'
# Do not display changes that only affect whitespace
DIFF_FLAG='-Bub'
FREEBSD_ID='yes'
DELETE_STALE_RC_FILES='yes'

en deze zou freebsd-update moeten respecteren.

https://lists.freebsd.org...ons/2013-June/251823.html

Probeer het een keer op deze manier.

[ Voor 23% gewijzigd door matty___ op 14-08-2015 08:48 ]

[FireDrunk]

Auto install en auto upgrade samen? Ben je dan niet bijvoorbeeld meteen je smb.conf kwijt?

[fluppie007]

Ik ga precies toch die WD3IDLE.exe is opzoeken. Is voor de Western Digital WD60EZRX.

code:

Disk    Status  Temperature     Power cycles    Load cycles     Cable errors    Bad sectors     Lifetime
ada0    Healthy     39°C • 102°F  11  50661   0   0 active • 0 passive  3.2 months
ada1    Healthy     38°C • 100°F  11  51204   0   0 active • 0 passive  3.2 months
da0     Healthy     no sensor               ? active • ? passive  ???
da1     Healthy     40°C • 104°F  62  212     0   0 active • 0 passive  1.9 years
da2     Healthy     43°C • 109°F  62  197     0   0 active • 0 passive  1.9 years
da3     Healthy     40°C • 104°F  61  197     0   0 active • 0 passive  1.9 years
da4     Healthy     43°C • 109°F  62  192     0   0 active • 0 passive  1.9 years
da5     Healthy     39°C • 102°F  60  207     0   0 active • 0 passive  1.9 years
da6     Healthy     42°C • 108°F  61  193     0   0 active • 0 passive  1.9 years
da7     Healthy     38°C • 100°F  3   59  0   0 active • 0 passive  2.4 months
da8     Healthy     39°C • 102°F  11  51452   0   0 active • 0 passive  3.2 months

Warning
At least one disk has a high rate of load cycles. While this does not pose a direct problem, it could cause your disk(s) to have a shorter lifetime due to excessive headparking. The disk with the highest load cycle count is calculated to park their heads every 163.5 seconds. You may want to change the APM setting for the affected disk(s). Changing the APM to a setting of 254 on the Disks->Advanced page should cause the load cycles to increase much slower than the current rate.

[matty___]

FireDrunk schreef op vrijdag 14 augustus 2015 @ 09:20:
Auto install en auto upgrade samen? Ben je dan niet bijvoorbeeld meteen je smb.conf kwijt?

Je smb.conf zit in /usr/local/etc dus daar komt die toch niet aan. Dit gaat enkel om wat in /etc/ zit

Verder staat dit in de man page https://www.freebsd.org/c...y=mergemaster(8)&sektion=
# Install the new file if it differs only by VCS Id ($FreeBSD, -F) <-Dit is het gezeik van enkel het versie nummer opgehoogd
#FREEBSD_ID=

# Automatically install files that do not exist on the system already (-i)
#AUTO_INSTALL=

# Automatically upgrade files that have not been user modified (-U)
# ***DANGEROUS***
#AUTO_UPGRADE=

Dus alleen bestanden die niet zijn aangepast.

[ Voor 16% gewijzigd door matty___ op 14-08-2015 10:43 ]

[FireDrunk]

Ah, das perfect idd. Goed om te weten... Dat maakt voor mij FreeBSD gebruiken weer wat interresanter.
Ik wil eigenlijk gewoon een vrij simpel scriptje draaien om de nieuwste kernel te installeren, en compleet userland te upgraden...

[Fr0zenFlame]

Misschien is dit meer FreeNas gerelateerd dan ZFS maar wellicht heeft iemand al ervaring met de volgende setup.

1) We overwegen om i.p.v. een HP DL380 G8 met 128 DDR3 ECC, 2 CPU's, met 2 LSI-9201-16i HBA's, 24 Samsung 845 DC Pro 400GB's en een Samsung 850 Pro 128GB voor OS nu de configuratie op te splitsen in twee systemen (bij dit systeem is zij de disks in 1 Zpool geconfigureerd die bestaat uit 12 vdev mirrors, waarbij de disks evenredig over beide controllers zijn verdeeld, 1 uit elke mirror op een andere controller).

2) Dit zouden dan 2x HP DL380 G7's moeten worden met ook beide 128GB DDR3 ECC, 2 CPU's, beide 1 LSI9201-16-i , 12 Samsung 845 DC Pro 400GB's en 1 OS disk. Het idee hier achter is dat we dan 1 helft van RDS machines op 1 machine zetten, en de andere helft op de andere.

Eventueel zouden we er ook voor kunnen kiezen alles machines op 1 te zetten en dan op basis van een schedule een snapshot te maken die we dan met replication naar de andere machien repliceren elke x periode.

Of in het geval van scenario 1 kunnen we dat ook doen naar een volume op de bestaande storage (Netapp). Weet alleen niet of dit ondersteud is of dat je dan gebruik moet maken van rSYNC wat dan weer een volledige kopie betreft wat eigenlijk ook niet wenselijk is.

Iemand ervaring met het redundant uitvoeren middels replicatie op een ZFS based storage systeem zoals bijvoorbeeld FreeNas?

[Verwijderd]

Heb je al eens naar HAST gekeken? Dat is geen replicatie maar high availability, maar is ook vrij hot op BSD. Misschien dat je daarmee ook bereikt wat je wilt?

[Fr0zenFlame]

Heb even een kort introductie gelezen @ https://wiki.freebsd.org/HAST
Klikt veel belovend! Zijn je ervaringen hier goed mee m.b.t. stabiliteit etc?

Als ik het goed begrijp is HAST in Freenas-9.3-Stable nog niet beschikbaar.

[matty___]

Fr0zenFlame schreef op vrijdag 14 augustus 2015 @ 11:42:
Als ik het goed begrijp is HAST in Freenas-9.3-Stable nog niet beschikbaar.

http://www.freenas.org/wh...ase-is-now-available.html
In 9.2.1.4 hebben ze HAST toegevoegd. Lijkt mij dat het in 9.3 gewoon bruikbaar is

[Fr0zenFlame]

Volgens mij is dat een aankondiging maar is het helaas nog niet toegevoegd als ik af ga op de release notes van 9.3-Beta.
http://www.freenas.org/wh...-beta-released-today.html

En volgens het FreeNas forum is het niet echt supported en moet je er wel wat hacks voor uit halen:
https://forums.freenas.or...ge-hast-in-freenas.30411/

[FireDrunk]

TrueNAS (De betaalde variant van FreeNAS) kan dit wel volgens mij. Daar betaal je voor support van dat soort features...

Mocht dat niet toereikend zijn, kan je naar Nexenta kijken. Die hebben ook HA oplossingen (welliswaar Solaris ipv BSD).

[ Voor 49% gewijzigd door FireDrunk op 14-08-2015 12:32 ]

[vanaalten]

fluppie007 schreef op vrijdag 14 augustus 2015 @ 10:11:
Ik ga precies toch die WD3IDLE.exe is opzoeken. Is voor de Western Digital WD60EZRX.

Welk besturingssysteem gebruik je?

Je resultaten verbazen mij wel, ik heb twee WD60EZRX in een Debian 'Jessie' systeem (BTRFS i.p.v. ZFS), relevant smart resultaat hier:

code:

  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1356
193 Load_Cycle_Count        0x0032   196   196   000    Old_age   Always       -       12012

en

code:

  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1352
193 Load_Cycle_Count        0x0032   197   197   000    Old_age   Always       -       11648

Draait al sinds januari of zo full-time. Disks spinnen-down automagisch, maar blijkbaar niet zo fanatiek als bij jou.

[vanaalten]

Dubbel.

[ Voor 97% gewijzigd door vanaalten op 14-08-2015 14:11 ]

[Compizfox]

matty___ schreef op vrijdag 14 augustus 2015 @ 08:44:
[...]

En mijn punt is dat je hetzelfde gedrag met mergemaster -F krijgt als je een build from source doet. Misschien dat er ook zo iets bij freebsd-update is. Keertje opzoeken want de functionaliteit zit in mergemaster en kan mij niet voorstellen dat de binary update een ander mechanisme voor het mergen gebruikt.

edit: Blijkbaar kun je een /etc/mergemaster.rc aanmaken met de default instellingen met bv dit erin:
AUTO_INSTALL='yes'
AUTO_UPGRADE='yes'
# keep our custom motd
IGNORE_FILES='/etc/motd'
# Do not display changes that only affect whitespace
DIFF_FLAG='-Bub'
FREEBSD_ID='yes'
DELETE_STALE_RC_FILES='yes'

en deze zou freebsd-update moeten respecteren.

https://lists.freebsd.org...ons/2013-June/251823.html

Probeer het een keer op deze manier.

Thanks, ga ik proberen!

---

FireDrunk schreef op vrijdag 14 augustus 2015 @ 09:20:
Auto install en auto upgrade samen? Ben je dan niet bijvoorbeeld meteen je smb.conf kwijt?

Lijkt me niet, want smb(4).conf komt vanuit de port sambaxx, niet vanuit het base system.

---

offtopic:
Is een FreeBSD-topic eigenlijk niet wat? Dit heeft weinig met ZFS te maken

[ Voor 3% gewijzigd door Compizfox op 14-08-2015 14:18 ]

[CurlyMo]

Compizfox schreef op vrijdag 14 augustus 2015 @ 14:18:

offtopic:
Is een FreeBSD-topic eigenlijk niet wat? Dit heeft weinig met ZFS te maken

Eens

[Verwijderd]

@Compizfox, die vraag is al vaker langsgekomen. Maar dit topic is niet louter voor ZFS, maar ook voor alle ZFS platforms. Pas zodra het topic is gesplitst, waarbij ook het DIY RAID NAS topic wordt geïntegreerd in een nieuw 'zelfbouw NAS' topic, zal het ZFS topic enkel over ZFS gaan. De ZFS platforms krijgen dan een eigen topic.

Dat betekent ook dat tot die tijd dit topic erg breed van opzet is. Ik had de splitsing al een tijd geleden willen doen en ook twee keer begonnen aan een mooie topicstart. Helaas alles verloren door een Firefox crash, en Firefox onthoudt wel de form-data maar niet als deze op een pagina via POST-request is geschreven, zoals waarna je op 'Preview post' klikt. Crasht je Firefox dan, dan ben je ook alles kwijt. Enorm k*t.

[FireDrunk]

Lastige is, dat bij veel debugging het je niet weet of het aan ZFS of aan je OS ligt. Dat zorgt er voor dat mensen vaak elkaar opzoeken in de bekende fora en niet keihard zich houden aan de topic scheiding...

FreeBSD topic heeft denk ik net zo veel bestaansrecht als een BTRFS topic

[Verwijderd]

Bij een groot topic is het ook altijd handiger een eigen topic te beginnen. Een groot NAS project met veel vragen die echt veel verder dan alleen ZFS en de ZFS platforms gaan, kun je daarom ook beter in een eigen topic gieten. Regelmatig vraag ik mensen in het DIY RAID NAS topic om dit te doen - een echt groot project verdient zijn eigen topic. Dan heb je ook minder problemen met een brede vraagstelling.

Maar we kunnen wellicht binnenkort in een 'feedback' topic eens brainstormen hoe we de huidige topics beter kunnen indelen. Want ook tussen DIY RAID NAS en dit ZFS topic is de grens soms vaag en worden ZFS vragen in het DIY RAID NAS topic gesteld en vice versa.

[Q]

Ik heb een nieuwe feature geleerd: "large_blocks". Deze ZFS feature zou enorm onder de schijnwerpers geplaatst moeten worden, want dan kom je van je max record lenght van 128K af.

Dit heeft enorme gevolgen.

Die hele regel can 2^n + parity voor je VDEVs wordt dan totaal irrelevant omdat de bijbehorende overhead verwaarloosbaar wordt, met name als je veel grote files opslaat.

In mijn geval zou ik dan een 24-disk RAIDZ2 kunnen maken of een RAIDZ3, of 2 x 12 disk RAIDZ2, net waar je comfortabel mee bent.

Iemand ergens nog 40 TB spare storage te leen zodat ik mijn pool ff opnieuw op kan zetten?

[ Voor 5% gewijzigd door Q op 14-08-2015 22:40 ]

[Verwijderd]

Klopt, mits je ook ashift=12 gebruikt tenminste. Maar behalve dat overhead veel minder een probleem wordt, kan ook de performance flink gaan stijgen.

Neem nou 10 disks in RAID-Z2. 8 data disks dus 128/8 = 16K per disk. Dat betekent dat je schijven blokjes van 16K te verwerken krijgen. Voor SSDs betekent dit bijna een verzadiging maar bij hardeschijven is dat pas vanaf 64K.

Met large_blocks = 1MiB doen je disks 128K per stuk en dat is het allerbeste. Dus dat betekent ook dat je meer performance uit je mechanische disks haalt. Zeker voor nieuwere type disks (SMR, HAMR) zou dit nog veel meer winst kunnen opleveren.

Het enige nadeel is dat large_blocks niet bootable is. ZFSguru 0.3 heeft large_blocks bij het aanmaken van de pool prominent aangegeven, dus het krijgt daar de aandacht die het verdient. Inderdaad goed dat je met een post hier nog eens op wijst.

[ Voor 6% gewijzigd door Verwijderd op 14-08-2015 22:47 ]

[Compizfox]

Q schreef op vrijdag 14 augustus 2015 @ 22:39:
Ik heb een nieuwe feature geleerd: "large_blocks". Deze ZFS feature zou enorm onder de schijnwerpers geplaatst moeten worden, want dan kom je van je max record lenght van 128K af.

Dit heeft enorme gevolgen.

Die hele regel can 2^n + parity voor je VDEVs wordt dan totaal irrelevant omdat de bijbehorende overhead verwaarloosbaar wordt, met name als je veel grote files opslaat.

In mijn geval zou ik dan een 24-disk RAIDZ2 kunnen maken of een RAIDZ3, of 2 x 12 disk RAIDZ2, net waar je comfortabel mee bent.

Iemand ergens nog 40 TB spare storage te leen zodat ik mijn pool ff opnieuw op kan zetten?

Ik las er al over, maar wist nog niet wat het voor gevolgen had. Bedankt voor de uitleg!

Binnenkort maar eens updaten naar FreeBSD 10.2

[Q]

Verwijderd schreef op vrijdag 14 augustus 2015 @ 22:47:
Inderdaad goed dat je met een post hier nog eens op wijst.

Bedankt voor de verduidelijking.

Volgens mij zou ik een paar TB extra storage space overhouden als ik mijn pool op mijn 71 TB array zou upgraden. Voelt wel een beetje spannend.

[Compizfox]

Q schreef op vrijdag 14 augustus 2015 @ 23:39:
[...]


Bedankt voor de verduidelijking.

Volgens mij zou ik een paar TB extra storage space overhouden als ik mijn pool op mijn 71 TB array zou upgraden. Voelt wel een beetje spannend.

Allemachtig, 71 TB?

[Q]

Zie mijn signature.

Support voor large_blocks zit nog bijna nergens ingebakken behalve in BSD als ik het goed begrijp.

http://open-zfs.org/wiki/Feature_Flags

Dus het is nog even wachten voordat de mainstream deze feature kan gebruiken.

Alhoewel ik mijn dubbele RAIDZ2 niet kan omtoveren, zal die feature flag toch wel wat storage space reclaimen gok ik zo. Ik ga het voorzichtig aanzien.

[Verwijderd]

Zit ook al een tijd in -STABLE en dat draaien veel mensen, waaronder ik.

Hoezo kun je je huidige pool niet upgraden? Kan toch gewoon? Alleen bestaande data blijft zoals hij is, alleen nieuwe data wordt dan met grotere blocks geschreven.

[Compizfox]

Q schreef op zaterdag 15 augustus 2015 @ 00:42:
Zie mijn signature.

Support voor large_blocks zit nog bijna nergens ingebakken behalve in BSD als ik het goed begrijp.

http://open-zfs.org/wiki/Feature_Flags

Dus het is nog even wachten voordat de mainstream deze feature kan gebruiken.

FreeBSD is in de context van ZFS toch aardig mainstream hoor. Ik heb geen harde cijfers, maar ik gok dat het populairder is dan ZoL (komt natuurlijk ook door projecten als FreeNAS, NAS4Free en ZFSGuru).

[Verwijderd]

Ja, bovendien heeft ZFS al een lange historie op FreeBSD terwijl ZoL nog vrij nieuw is. FreeBSD heeft de eerste ZFS import sinds v6. Mac OSX v9 volgens mij, maar daarna is het eruit gesloopt mogelijk vanwege de overname van Sun door Oracle.

ZFS heeft op BSD ook heel veel liefde gekregen, voornamelijk omdat UFS+SU toch niet zo heel sexy is onder BSD en dus een modern filesystem enorm gewenst was. Ook omdat BSD toch vooral een server operating system is, terwijl Linux veel universeler is.