Het grote ZFS topic

[Mr.Sun]

Zpool missing op TrueNAS (na upgrade 'special class VDEV')

Ik heb nog een aardig ‘uitswingertje’ van 2020.... naah, feitelijk niet zo fraai: ik heb een storing waardoor de zpool niet meer gevonden wordt...

Bij het upgraden van de VDEV voor de Metadata (de ‘special class VDEV’), is er blijkbaar iets misgegaan, waardoor de zpool niet meer getoond wordt en er een ‘critical alert’ gemeld wordt:






Ik werk dus met TrueNAS Core versie 12 (de eerste ‘TrueNAS Core’-versie)(voorheen FreeNAS).

Daarin een zpool bestaande uit:
- (‘reguliere’ VDEV’s) harddisks: 2 VDEV’s van elk 6 disks (Z2)
- (‘special class VDEV’) SSD’s: 1 VDEV van 2 SSD’s (in Mirror).
Deze ‘special class VDEV’ was ik gestart met kleine SSD’s van 120GB (met de gedachte om die te upgraden (omwisselen voor grotere) als nodig).
Dat bleek al vlot nodig te zijn. Dus setje van 2 stuks van 500GB SSD erbij gehaald.


Heb de volgende procedure aangehouden voor het upgraden/verwisselen:
1. begonnen (met NAS uitgeschakeld), met het loskoppelen van 1 van die 2 SSD’s (om te zien wat welke is en deze te labelen)
2. NAS opgestart, en het liet uiteraard netjes zien welke SSD afgekoppeld was (heb toen de andere gelabeld)
3. de afgekoppelde SSD weer aangekoppeld (met de NAS nog aan); die SSD kwam weer netjes online (te zien in de Status)
4.
5. toen de andere SSD op ‘offline’ gezet (via > Pools > Status etc)
6. NAS toen uitgeschakeld
7. de 120GB SSD verwisseld voor een 500GB SSD
8. de NAS weer aangeschakeld (met de intentie om die nieuwe SSD dan een ‘replace’-command te gaan geven)
9. maar.... dus helaas..... melding ”Pool Offline”...

[Mr.Sun]

Ik vermoed dat ik toch iets verkeerd heb gedaan met deze procedure (?). Maar ik weet zo niet wat.

Wat ik vermoed is dat:
1)
Ofwel ik had na stap 3. eerst even weer de NAS moeten rebooten, omdat de afgekoppelde en weer aangekoppelde SSD wellicht tóch niet echt ‘online’ was?
(en omdat ik die andere zelf ook afgekoppeld had, was er dan geen SSD meer online, dus geen ‘special-class VDEV’).
2)
Danwel die upgrade-procedure werkt sowieso niet bij de ‘special-class’ VDEV?
3)
Danwel die upgrade-procedure werkt niet bij Mirrors?

Vragen:

1)
Hoe krijg ik de zpool weer in beeld?
(het systeem functioneert verder goed; de Shell doet het etc)(‘alleen’ de pool ontbreekt)
2)
Hoe vergroot je in dit geval de capaciteit van de ‘special class VDEV’?

Ik houd even als tactiek aan dat ik hier eerst even de nodige diverse feedback graag wil verzamelen.
Voordat ik ga ‘peuteren’.

Dus als je feedback/ideeen hebt just shoot please!

(en allen ook een goed uiteinde gewenst... ;-)

[CurlyMo]

@Mr.Sun Dit zijn die momenten waarop je eerst eens de cmdline in duikt om te kijken of het een specifiek TrueNAS probleem is of je pool ook op FreeBSD kern niveau raar doet.

[Mr.Sun]

@CurlyMo je bedoelt denk ik: kijken of je via Shell (commandline) wél de zpool in beeld kunt krijgen?

Welke controles/specifieke commands stel je voor svp?

[CurlyMo]

Mr.Sun schreef op woensdag 30 december 2020 @ 22:27:
@CurlyMo je bedoelt denk ik: kijken of je via Shell (commandline) wél de zpool in beeld kunt krijgen?

Klopt

Welke controles/specifieke commands stel je voor svp?

Voor zo'n vraag is tweakers niet de juiste plek. Daar kan je echt genoeg over vinden op duckduckgo. Als je dan binnen die informatie specifieke vragen hebt, dan is dit wel weer de juiste plek

[Q]

Misschien leuk voor het publiek hier:

[Mr.Sun]

Mjah... uiteraard 'eerst ff zelf werken meneer'.

Maar believe me... er zit al veel zweet op de keys hier.....

Meer to the point:
dit is niet zo'n fraai storing om te krijgen uiteraard: het is ff serieus zaak dat ik (bij een storing als dit) niet 'maar wat probeer dat ik op Google allemaal vind wat gerelateerd kan zijn'.
(we weten allemaal dat daar ook mucho nonsens bij zit).

Ik denk dat het nu vooral zaak is om niet nog meer ingrepen/acties te doen die het terughalen van de zpool verhinderen.

Vandaar dat ik opper: "welke controles/commands specifiek stel je voor svp'.


Ik ga hier ook vandaag en morgen niet mee aan de slag. Toch eerst even het jaar feestelijk uitluiden.

En ik zou verdere feedback van TrueNAS-broeders ook zeer waarderen!

Bij voorbaat dank!

[HyperBart]

Mr.Sun schreef op woensdag 30 december 2020 @ 22:11:

Daarin een zpool bestaande uit:
- (‘reguliere’ VDEV’s) harddisks: 2 VDEV’s van elk 6 disks (Z2)
- (‘special class VDEV’) SSD’s: 1 VDEV van 2 SSD’s (in Mirror).

Ben je hier 100% zeker van dat dit een mirror is/was?

Deze ‘special class VDEV’ was ik gestart met kleine SSD’s van 120GB (met de gedachte om die te upgraden (omwisselen voor grotere) als nodig).
Dat bleek al vlot nodig te zijn. Dus setje van 2 stuks van 500GB SSD erbij gehaald.


Heb de volgende procedure aangehouden voor het upgraden/verwisselen:
1. begonnen (met NAS uitgeschakeld), met het loskoppelen van 1 van die 2 SSD’s (om te zien wat welke is en deze te labelen)
2. NAS opgestart, en het liet uiteraard netjes zien welke SSD afgekoppeld was (heb toen de andere gelabeld)
3. de afgekoppelde SSD weer aangekoppeld (met de NAS nog aan); die SSD kwam weer netjes online (te zien in de Status)

Was op dat moment die special class vdev al terug geresilvered? Was de mirror dus al terug in sync?

4.
5. toen de andere SSD op ‘offline’ gezet (via > Pools > Status etc)
6. NAS toen uitgeschakeld
7. de 120GB SSD verwisseld voor een 500GB SSD
8. de NAS weer aangeschakeld (met de intentie om die nieuwe SSD dan een ‘replace’-command te gaan geven)
9. maar.... dus helaas..... melding ”Pool Offline”...

Ik zou beide SSD's terug aansluiten, opstarten en een poging wagen zpool import (zonder de naam) uit te voeren maar de kans bestaat inderdaad zoals je zelf aangeeft dat er iets mis gegaan is op stap 3. Het jammere is dat special class vdev's even belangrijk zijn als een gewone vdev en een integraal deel vormen van de totale pool. Gaat daar iets mis mee dan is je pool dus ook om zeep.

Door een simpele zpool import kan je/kunnen we ten minste al zien wat ZFS er zelf van vindt ipv de GUI error die je nu post.

[CurlyMo]

@Mr.Sun Koppel dan terug wat je op duckduckgo gevonden hebt zonder het toe te passen. Dan vertellen wij wel of het veilig is.

[HyperBart]

michelvdriel schreef op dinsdag 29 december 2020 @ 22:11:
@CurlyMo Ik heb al eerder een live cd van Ubuntu geprobeerd. Na jouw post ook nog FreeBSD gemount, maar het resultaat was helaas hetzelfde.

@FireDrunk Ik ga er even over nadenken of ik een issue wil openen op github. In de systemlogs van de server zie ik veel errors voorbij komen tijdens het openen en dit lijkt op corruptie te wijzen. Ik ga er nog even een nachtje over slapen. De data is vervangbaar, dus misschien is het verstandig om de data als verloren te beschouwen en een nieuwe pool te maken... Bedankt voor de suggesties!

Michel, hoe is dit verder afgelopen? Ben wel benieuwd naar je probleem en de oplossing uiteindelijk.

[michelvdriel]

@HyperBart Ik heb uiteindelijk opgegeven. Ik had mijn vraag op meerdere plekken uitstaan en helaas kwam ik nergens verder. Ik heb backups van de kritieke data en wilde graag verder.

[Keiichi]

In m'n ZFS nas ben ik een upgrade van ssd's aan het plannen. Deze draaien zowel het root fs, zil en l2arc.

De zil draait als mirror. Ik kan eigenlijk niet vinden hoe ik deze moet vervangen. Het vervangen van de schijven zal met het verwijderen van de schijf gebeuren, ik kan een nieuwe schijf er helaas niet bijhangen. Alles moet gebeuren terwijl de server gewoon doordraait. (zou bij een echte failure ook het geval zijn)
Ik kan alleen instructies vinden voor een zil verwijderen die niet in mirror draait. Wat ik probeer is:

code:

root@nastest:~ # zpool remove zroot /dev/gpt/zil1
cannot remove /dev/gpt/zil1: operation not supported on this type of pool
root@nastest:~ # zpool remove zroot /dev/gpt/zil1 /dev/gpt/zil2
cannot remove /dev/gpt/zil1: operation not supported on this type of pool
cannot remove /dev/gpt/zil2: operation not supported on this type of pool

Ik wil niet de schijf 'hot' uit de server trekken, maar eerst het device inactief maken (l2arc is vrij simpel, van de zroot kan ik schijf offline en met een nieuwe schijf replace als deze vervangen is.

Maar hoe doet ik dat met de zil?

[FireDrunk]

@Keiichi
Je kan gewoon de hele ZIL en L2ARC tijdelijk verwijderen, is geen ramp.
In je commando mis je het woordje log

zpool remove <pool> log <device> uit mijn hoofd.

[ Voor 42% gewijzigd door FireDrunk op 11-01-2021 18:32 ]

[Keiichi]

De l2arc die laat zich wel verwijderen, maar de zil (mirror) niet. In ieder geval niet met het zpool remove commando.

[CurlyMo]

FireDrunk schreef op maandag 11 januari 2021 @ 18:31:
In je commando mis je het woordje log

Zover ik weet gebruik je die specificatie alleen bij het toevoegen. Niet bij het verwijderen, omdat dan de functie al bekend is bij ZFS.

[Keiichi]

Na vervelend lang zoeken:

code:

zpool remove zroot mirror-1

En nu hopen dat ik op de NAS waar ik het wil doen geen typefout maak

[Keiichi]

Ik heb met een FreeBSD 10.2 met zfs gehad dat met een dd commando van een bestand naar een zfs volume heel de server freezed (dd if=image of=/dev/zvol/tank/image bs=4k). Op icmp pings wordt nog wel gereageerd, maar lokale console, connecties die er al waren. Helemaal geen reactie. En ook geen kernel dump oid. De image zelf is exact 107374182400, de aangemaakte volume 100G (zou op de byte nauwkeurig passen ;-) )

Het lijkt wel vrij specifiek bij die actie te zijn, de NAS zelf is genoeg gebruikt met grote zfs send/receive , benchmarks e.d. zonder problemen.

De server zelf is met ECC geheugen, l2arc en zil device recentelijk vervangen. Ik kan niet bedenken waarom het gebeurd. Bios eventlog geeft geen fouten op geheugen of andere zaken. Waarin kan ik het zoeken waar het misgaat?

[FireDrunk]

bs=4k is niet heel handig, maar zou niet voor lockups moeten zorgen. BS=1M is al een stuk beter.

Je kan eens een tweede terminal (op de fysieke console) proberen te openen met ALT + F2, en daar `top` openen. Misschien wordt je daar wijzer uit?

[Keiichi]

Of er een duiveltje mee speelt, ik kon niet zo gek bedenken wat ik in allerlei terminals open had staan en eventueel wegschreef naar de schijf om iets te weten te komen. Draait het overzetten van de image naar de zvol zonder problemen.
Enige verschil sinds de vorige keer, l2arc write en boost had ik hoger staan en prefetch voor l2arc aan. Maar bij de 1ste keer dat het misgaat weet ik niet hoe deze stonden. Maar zelfs met de vreemdste instelling zou het ook niet tot een freeze moeten komen.

De 4k was omdat proxmox de volume's hiermee ook aanmaakt bij zfs over iscsi, verder niet bij stilgestaan.

[ Voor 9% gewijzigd door Keiichi op 15-01-2021 17:03 ]

[Guru Evi]

@Keiichi: Als je Proxmox (VM's) + ZFS draait en je speelt met de PF + L2ARC + WB, zit je waarschijnlijk te kort aan geheugen. Dan gaat de kernel inderdaad veel dingen buiten smijten (OOM killer) om je ARC/L2ARC vraag te voldoen.

De L2ARC heeft een paar kB geheugen RAM nodig voor elk blok. Voor een dedicated systeem reken je ong 5:1 - dus als je 500G aan L2ARC hebt, moet je minimum 128GB RAM hebben. Met SSD's van tegenwoordig (groot en goedkoop) loop je snel tegen de limiet.

Beter een kleinere L2ARC of zelfs geen als je een VM wilt draaien.

[ocf81]

gezien het nieuws (nieuws: Intel stopt met Optane-ssd's voor desktop-pc's consumenten) dat intel gaat stoppen met de consumenten SSD's is de tijdspanne waarop ik nog voor een optane SSD kan kiezen verkort en wordt mijn hand nu geforceerd. Daarom wil ik graag even het volgende weten:

1. Is 3D XPoint veel beter dan gewoon flash voor gebruik als ZIL?
2. Hoe groot moet zo'n drive dan zijn volgens de vuistregels van ZFS als je een NAS hebt met 64 GiB aan RAM? (logischerwijs zou dat iets in de trant van "groot genoeg om je writes tijdelijk op te slaan" moeten zijn, maar het zou niet de eerste verassing zijn m.b.t. ZFS, dus ik vraag het maar even voor de zekerheid)
3. Is het noodzakelijk om een ZIL volume te mirroren?

Toepassingsscenario is een NAS/SAN waar o.a. de gaming servers VM's voor mijn clan op draaien. triple nine uptime is niet noodzakelijk, maar herstelbaarheid/integriteit is echter wel zeer gewenst.

[ Voor 10% gewijzigd door ocf81 op 18-01-2021 11:29 ]

[Snow_King]

ocf81 schreef op maandag 18 januari 2021 @ 11:20:
gezien het nieuws (nieuws: Intel stopt met Optane-ssd's voor desktop-pc's consumenten) dat intel gaat stoppen met de consumenten SSD's is de tijdspanne waarop ik nog voor een optane SSD kan kiezen verkort en wordt mijn hand nu geforceerd. Daarom wil ik graag even het volgende weten:

1. Is 3D XPoint veel beter dan gewoon flash voor gebruik als ZIL?
2. Hoe groot moet zo'n drive dan zijn volgens de vuistregels van ZFS als je een NAS hebt met 64 GiB aan RAM? (logischerwijs zou dat iets in de trant van "groot genoeg om je writes tijdelijk op te slaan" moeten zijn, maar het zou niet de eerste verassing zijn m.b.t. ZFS, dus ik vraag het maar even voor de zekerheid)
3. Is het noodzakelijk om een ZIL volume te mirroren?

Toepassingsscenario is een NAS/SAN waar mijn gaming server VM's op draaien. triple nine uptime is niet noodzakelijk, maar herstelbaarheid is echter wel zeer gewenst.

3: Ja, zeker als de herstelbaarheid belangrijk is.

En of 3D Xpoint wat uit haalt ligt helemaal aan de hoeveelheid kleine writes die je er heen stuurt. De lage latency van Optane is enkel handig als het netwerk en de CPU die lage latency ook kunnen verwerken.

Vaak is 8 tot 16GB aan ZIL al wel voldoende.

[ocf81]

Snow_King schreef op maandag 18 januari 2021 @ 11:28:
[...]

3: Ja, zeker als de herstelbaarheid belangrijk is.

En of 3D Xpoint wat uit haalt ligt helemaal aan de hoeveelheid kleine writes die je er heen stuurt. De lage latency van Optane is enkel handig als het netwerk en de CPU die lage latency ook kunnen verwerken.

Vaak is 8 tot 16GB aan ZIL al wel voldoende.

Ik heb dual 10GbE met LACP in de machine zitten. De CPU is nu nog 2x E5-2630 v3, maar ik zit er aan te denken om dat moederbord op termijn te verwisselen voor een Xeon-D 1518 of een Xeon E, aangezien die dual 2630 met zijn duimen zit te draaien en ik het draaien van extra containers of VM's toch liever vanuit Proxmox doe. De VM's draaien als KVM images (Proxmox) via iSCSI.

[Snow_King]

ocf81 schreef op maandag 18 januari 2021 @ 11:37:
[...]

Ik heb dual 10GbE met LACP in de machine zitten. De CPU is nu nog 2x E5-2630 v3, maar ik zit er aan te denken om dat moederbord op termijn te verwisselen voor een Xeon-D 1518 of een Xeon E, aangezien die dual 2630 met zijn duimen zit te draaien en ik het draaien van extra containers of VM's toch liever vanuit Proxmox doe. De VM's draaien als KVM images (Proxmox) via iSCSI.

10GbE LACP heeft niet de meest lage latency. 25GbE heeft een lagere latency. Het punt zit hem hier vooral in de latency, niet in de bandbreedte.

Je zal ook je CPU op C-State 1 willen pinnen, want anders ga je nog steeds weinig aan die 3D Xpoint SSD's hebben.

Ik zou het qua prijs even afwegen tegen elkaar, maar vooral niet een te goedkope SSD voor je ZIL, want die zijn vaak langzaam met random 4k writes bij een Queue Depth van 1

[ocf81]

Snow_King schreef op maandag 18 januari 2021 @ 12:50:
[...]

10GbE LACP heeft niet de meest lage latency. 25GbE heeft een lagere latency. Het punt zit hem hier vooral in de latency, niet in de bandbreedte.

Je zal ook je CPU op C-State 1 willen pinnen, want anders ga je nog steeds weinig aan die 3D Xpoint SSD's hebben.

Ik zou het qua prijs even afwegen tegen elkaar, maar vooral niet een te goedkope SSD voor je ZIL, want die zijn vaak langzaam met random 4k writes bij een Queue Depth van 1

Dat 25 GbE net weer wat sneller is, dat lijkt me evident. Hoewel het nu goedkoper begint te worden is 25 GbE is nog even buiten bereik voor mij. Ik heb nu een leuk Ubiquiti netwerkje draaien dat ik de komende jaren wil blijven gebruiken. Als ik je goed begrijp is 3D XPoint dus een klein beetje overkill voor mijn use case?

[Snow_King]

ocf81 schreef op maandag 18 januari 2021 @ 12:55:
[...]

Dat 25 GbE net weer wat sneller is, dat lijkt me evident. Hoewel het nu goedkoper begint te worden is 25 GbE is nog even buiten bereik voor mij. Ik heb nu een leuk Ubiquiti netwerkje draaien dat ik de komende jaren wil blijven gebruiken. Als ik je goed begrijp is 3D XPoint dus een klein beetje overkill voor mijn use case?

25GbE is qua bandbreedte sneller, maar het zit hem in de latency. 25GbE heeft een lagere latency dan 10GbE.

Latency is een lastig onderwerp en soms moeilijk te doorgronden. Je moet in de hele keten gaan kijken. 3D Xpoint voor je ZIL kan een toevoegingen zijn, maar dan moet je de gehele keten optimaliseren.

Als je CPU (stel) de bottleneck is, dan heeft 3D Xpoint al geen nut. Compressie uitzetten op ZFS heeft meer effect op de latency dan 3D Xpoint toevoegen als ZIL.

Allemaal hele kleine stapjes die in het geheel tot een lagere latency kunnen leiden.

[ocf81]

Snow_King schreef op maandag 18 januari 2021 @ 13:48:
[...]

25GbE is qua bandbreedte sneller, maar het zit hem in de latency. 25GbE heeft een lagere latency dan 10GbE.

Latency en snelheid zijn aan elkaar gekoppeld. Immers is latency, voor zover het om de netwerkschakel in deze keten gaat, afhankelijk van de bitrate. (om even een beeld te geven, ik heb een B.ICT SWE, dit was ook onderdeel van de opleiding)

Snow_King schreef op maandag 18 januari 2021 @ 13:48:
Latency is een lastig onderwerp en soms moeilijk te doorgronden. Je moet in de hele keten gaan kijken. 3D Xpoint voor je ZIL kan een toevoegingen zijn, maar dan moet je de gehele keten optimaliseren.

Als je CPU (stel) de bottleneck is, dan heeft 3D Xpoint al geen nut. Compressie uitzetten op ZFS heeft meer effect op de latency dan 3D Xpoint toevoegen als ZIL.

Allemaal hele kleine stapjes die in het geheel tot een lagere latency kunnen leiden.

Ok, dan moet ik dus eerst gaan benchmarken om het nut van een M10 t.o.v. een andere ZIL cache drive te kunnen bepalen. Ik ga eens op zoek naar hoe ik dat moet doen. (als je tips hebt houd ik mij aanbevolen) In ieder geval bedankt voor de inzichten!

[dcm360]

Als iemand met een leuke testmethode komt, wil ik op zich ook wel de test draaien ter vergelijking. Ik heb twee systemen die niet exact hetzelfde zijn, maar naar mijn idee wel dicht genoeg op elkaar zitten dat er zinnige resultaten uit kunnen komen.
Systeem 1: 48GB RAM, Optane 900P als ZIL en L2ARC, 4x ST5000DM000 in raid Z2
Systeem 2: 64GB RAM, DC P4510 als ZIL en L2ARC, 3x ST8000DM004 in raid Z

De DC P4510 is een tijdje lang de goedkoopste datacenter-class SSD geweest, maar in de pricewatch zie ik nu ook de Samsung PM983 voor lage prijzen gaan (waarschijnlijk omdat die EOL is, want de opvolger is er al). Ik heb geen ervaring met die schijf, maar het ziet er wel interessant uit voor degenen die graag een stapje boven consumentenschijven kijken.

[FireDrunk]

downloads: TrueNAS 12.0-U1-1

Mogelijk van belang omdat er blijkbaar een issue zit in ZFS.

[ph0t0nix]

Het is niet zozeer een issue in ZFS, naar een issue in patches die iXSystems extra aan TrueNAS 12 had toegevoegd. De betreffende patches zijn nog niet officieel onderdeel van OpenZFS (2.x).

Zie ook deze TrueNAS forum thread.

[ Voor 0% gewijzigd door ph0t0nix op 20-01-2021 01:01 . Reden: typo ]

[psy]

Ik ga eens experimenteren met ZFS. Heb een 12-tal schijven 2TB liggen die ik wil gaan gebruiken. Primaire doel als alles lukt is een veiliger backup mogelijk maken met een werkende "Previous versions" functionaliteit in de Windows clients.

Na veel gelezen te hebben maar er toch niet uit te komen heb ik de knoop maar doorgehakt en FreeBSD gedownload en geïnstalleerd. Omdat ik eigenlijk alleen Windows (en de Server varianten, ik draai AD thuis) ken is dit wel een heel andere ervaring. Maar je bent nooit te oud om te leren nietwaar.

Eerste waar ik nu tegenaanloop. Omdat ik er bewust even voor koos om zonder de schijven te installeren is de tutorial die ik ergens vond om ZFS direct bij de installatie te configureren niet bruikbaar. Dit moet ik nu achteraf doen. Is dat handig of kan ik beter opnieuw beginnen?

[Brahiewahiewa]

psy schreef op woensdag 20 januari 2021 @ 12:43:
... Is dat handig of kan ik beter opnieuw beginnen?

Denk dat je beter opnieuw kunt beginnen met een kant&klaar pakket zoals xigmanas of truenas.
Dan kun je meteen focussen op je storage

[matty___]

psy schreef op woensdag 20 januari 2021 @ 12:43:
Ik ga eens experimenteren met ZFS. Heb een 12-tal schijven 2TB liggen die ik wil gaan gebruiken. Primaire doel als alles lukt is een veiliger backup mogelijk maken met een werkende "Previous versions" functionaliteit in de Windows clients.

Na veel gelezen te hebben maar er toch niet uit te komen heb ik de knoop maar doorgehakt en FreeBSD gedownload en geïnstalleerd. Omdat ik eigenlijk alleen Windows (en de Server varianten, ik draai AD thuis) ken is dit wel een heel andere ervaring. Maar je bent nooit te oud om te leren nietwaar.

Eerste waar ik nu tegenaanloop. Omdat ik er bewust even voor koos om zonder de schijven te installeren is de tutorial die ik ergens vond om ZFS direct bij de installatie te configureren niet bruikbaar. Dit moet ik nu achteraf doen. Is dat handig of kan ik beter opnieuw beginnen?

Heb je een werkende installatie? Het aanmaken van een pool is zo gebeurd natuurlijk mits je even alle schijven hebt voorzien van een partitie.

[psy]

Ik heb al een werkende installatie en de eerste 2 schijven heb ik aangesloten. Heb nu even het probleem dat ik mijn user nog su rechten moet geven want ik krijg telkens Permission Denied als ik wat wil uitproberen. Vallen en opstaan enzo

[P5ycho]

Als je het leuk vindt om FreeBSD je eigen te maken, dan is het nog steeds goed om met een werkende ZFS-on-root installatie te beginnen.
Ik ben ook zo begonnen, compleet 'from scratch' in de tijd dat er nog geen ZFS installer was. Dat was ergens in 2008, met FreeBSD 7. Het is te doen, maar je gaat er al genoeg werk aan hebben om de boel op te tuigen zoals je het hebben wilt als je het systeem eenmaal hebt draaien. Gun jezelf even het gemak van de installer, dan hoef je met een beetje geluk niet opnieuw te beginnen omdat je toch wat beginnersfouten hebt gemaakt.

Als je 12 schijven hebt wil je misschien niet beginnen met 2 schijven, maar met 4 of 6. mirrored configuratie is het meest flexibel, maar ook altijd 50% redundancy overhead.

[psy]

Goed, ik ben inmiddels ietsje verder. De permission denied errors vlogen me om mijn oren, dus ik ben maar even als root verder gegaan. Nu kan ik tenminste verder.
Ik heb 10 schijven aangesloten. Alle oude "windows" restjes qua partitie informatie heb ik nu verwijderd.
Ik heb nu een raidz2 pool kunnen aanmaken..

Het is me alleen nu niet heel duidelijk hoe ik verder moet.

code:

user@srv-freebsd:~ $ zpool status
  pool: mypool
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        mypool      ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0
            da7     ONLINE       0     0     0
            da8     ONLINE       0     0     0
            da9     ONLINE       0     0     0
            da10    ONLINE       0     0     0

errors: No known data errors

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

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          da0p3     ONLINE       0     0     0

errors: No known data errors
user@srv-freebsd:~ $

Klopt dit nu?

Als ik zfs list mypool draai

code:

user@srv-freebsd:~ $ zfs list mypool

NAME     USED  AVAIL  REFER  MOUNTPOINT
mypool  1.10M  13.4T   219K  /mypool

user@srv-freebsd:~ $

Als ik het goed begrepen heb hoef ik me niet druk te maken om volumes en/of partities?
Ik kan in principe zo mijn pool gebruiken om files op te zetten?

Doel is om twee hoofd shares te gaan gebruiken bereikbaar vanuit Windows (domein), Public en Private. Ik wil gewoon dat beide mappen dezelfde hoeveelheid ruimte (8 x 2 TB) kunnen gebruiken.
Ik wil snapshots gaan gebruiken zodat ik de Versions functionaliteit in Windows kan gebruiken.

[GioStyle]

Nu moet je filesystems gaan aanmaken... dus bijvoorbeeld zpool create mypool/public en zpool create mypool/private en dan cifs shares zodat je data aan je netwerk kan aanbieden.

[psy]

OK gelukt.

Moet ik niet eerst iets van Samba installeren in FreeBSD?
Als ik de volgende link mag geloven?
https://docs.freebsd.org/...rk-servers/#network-samba

[syl765]

@psy
je hebt nu de schijven als geheel. Het is toch iets mooier om de schijven te voorzien van een partitie en bijvoorbeeld een gpt label.
Wat ik altijd doe is het volgende.

Het schoonmaken van de disk.
gpart destroy -F /dev/da0
gpart destroy -F /dev/da1
enz

gpart create -s gpt /dev/da0
gpart add -a 1m -t freebsd-zfs -l disk0 /dev/da0

gpart create -s gpt /dev/da1
gpart add -a 1m -t freebsd-zfs -l disk1 /dev/da1
enz

Hiermee maak je op iedere disk een partitie aan met een gpt label.
-a 1m zorgt ervoor dat de partitie een offset heeft van 1024kb waarmee je altijd de juiste alignment hebt of je nu een 512k of 4k sector size disk hebt. Dit komt de performance ten goede.
-t geeft aan wat voor type partitie het is.
-l geeft een GPT label mee, in dit geval disk1, maar je kan het een naam geven wat je wilt.

Het voordeel van de GPT label is het feit dat het dan niet meer uitmaakt waar je disk is. Stel je hardware gaat stuk dan kun je de schijven zo overzetten naar een andere machine.
Zelf al gebruik je 6 dubbele USB docking stations waar je de schijven in plaatst ZFS zal ze altijd vinden omdat je de pool geimporteerd heb via de labels en die zijn altijd uniek (tenzij je ze dezelfde naam geeft maar dat is niet handig) handig in een server is bijvoorbeeld bay1, bay2 enz.

Een pool maken op basis van GPT label doe je als volgt.

zpool create raidz2 gpt/disk1 gpt/disk2 gpt/disk3 .......
Zorg er ook voor dat je een ashift van 12 gebruikt. voer onderstaande commando uit VOORDAT je de pool creëert.
sysctl -w vfs.zfs.min_auto_ashift=12


Op linux is deze pool ook gewoon te importeren via /dev/disk/by-partlabel
Werkt allemaal prima.

Ik raad je zeker aan om op deze manier je pool aan te maken.


Ja je moet eerst iets van samba installeren idd om veilig bestanden via cifs te kunnen delen.

[ Voor 7% gewijzigd door syl765 op 04-02-2021 17:46 ]

[idef1x]

Na een ruime 5 jaar is nu de 1e disk in een Z2 pool van 6 disks is dood en dus zit ik met een degraded pool.

Aangezien ik deze server toch denk uit te faseren denk ik er over om hem degraded te laten draaien (is slechts mijn ZFS backup machine).
Is dit verstandig of lijdt de performance er erg onder? Kan ik beter een nieuwe Z1 pool maken of toch de disk vervangen? In die laatste 2 gevallen zullen de andere 5 disken het wel voor hun kiezen krijgen en wellicht gaat er dan nog 1 kapot (zelfde type disk, zelfde aankoopdatum). Alle disken vervangen past niet in mijn huidige budget ervoor

[syl765]

Je kan hem zo laten draaien, je kan de schijf ook fysiek verwijderen.
Als je alle disks op hetzelfde moment hebt gekocht en ze zijn alle van het zelfde type, merk en fabricage batch, dan zit de kans erin dat je andere disks binnenkort ook wel aan de beurt zijn. Hou dit in je achterhoofd.

Qua performance denk ik dat het geen verschil maakt of de pool nu degraded is of niet. Ik zou de disk wel offline zetten of er fysiek uit halen. Je wilt niet dat je pool hem opeens toch weer ziet en gaat resilveren of iets anders gaat doen wat je niet wilt.

[idef1x]

Ok dank voor de terugkoppeling. Goede tip om hem idd wel offline te zetten. Ik ga hem wel verwijderen ook dan kan ie er zeker niets meer mee
Als de rest kapot gaat dan zij het zo. Een kijken hoe lang ie nog kan doordraaien.

[Amanoo]

Ik heb net een server met 8x 2TB in elkaar gezet. Mijn idee was om RAID10 of de ZFS variant daarvan te gebruiken. Ik had begrepen dat RAID6/RAID-Z2 gelimiteerd is tot single-drive snelheid bij writes, en ik wil mijn harde schijven juist versnellen. Ik wil wel een vorm van redundantie aangezien ik 8 drives heb, maar snelheid is belangrijker dan efficiënte redundantie.

Maar ik lees nu dat RAID-Z2 ook een behoorlijk stuk versnelt? Maar ook dat na verloop van tijd de snelheid flink inkakt en dat dus snelheid van een verse pool niet representatief is? Het is ook allemaal lekker complex, met verschillende soorten reads en writes....

Ik raak door de bomen een beetje het bos kwijt. Ik kom er nu echt niet achter welke vorm van RAID ik nu wil. Als RAIDZ-2 naar ietsjes trager is dan RAID10 neem ik net zo lief RAID-Z2. Als het beduidend trager is voldoet het niet aan mijn primaire doel. Dus wat wil ik nou?

[P5ycho]

Wat is de usecase? Heb je iops of sustained read/write nodig? VMs? Network shares? Iets anders?

[Amanoo]

P5ycho schreef op zaterdag 6 februari 2021 @ 08:37:
Wat is de usecase? Heb je iops of sustained read/write nodig? VMs? Network shares? Iets anders?

Er willen nog wel eens wat bestanden van rond de 10GB-15GB of soms 1-3GB worden gedownload, uiteraard volledig legaal Plan is dat ik nog een kleine oude SSD heb die ik als buffer gebruik voor Usenet downloads. Als die daar naartoe zijn gedownload komt het uitgepakte bestand op de harde schijf array. De SSD gebruik ik verder toch nergens anders meer voor.

Verder waarschijnlijk een sandbox voor een vriend (waarschijnlijk een VM) waarin hij in ieder geval Minecraft en Terraria servers wil maken. Dat komt sowieso op de array.

Zelf ga ik sowieso ook bezig met game servers. Wellicht op de SSD waar het OS op staat. Nog even kijken. Misschien op de harde schijf array.

En dan algemeen file host dingen. Af en toe katten foto's en video's uploaden die mijn broertje mij stuurt. Af en toe een desktop backup als ik een herinstallatie doe, zodat ik alles snel kan terughalen. Nextcloud, SMB shares.

Ik denk dat dat de voornaamste dingen zijn. Van IOPS en sustained writes en zo snap ik eigenlijk vrij weinig. Ik heb me geprobeerd erover in te lezen, maar het is nog een vak apart.

[ Voor 5% gewijzigd door Amanoo op 06-02-2021 09:07 ]

[Giesber]

Amanoo schreef op zaterdag 6 februari 2021 @ 09:05:
[...]

Er willen nog wel eens wat bestanden van rond de 10GB-15GB of soms 1-3GB worden gedownload, uiteraard volledig legaal Plan is dat ik nog een kleine oude SSD heb die ik als buffer gebruik voor Usenet downloads. Als die daar naartoe zijn gedownload komt het uitgepakte bestand op de harde schijf array. De SSD gebruik ik verder toch nergens anders meer voor.

Verder waarschijnlijk een sandbox voor een vriend (waarschijnlijk een VM) waarin hij in ieder geval Minecraft en Terraria servers wil maken. Dat komt sowieso op de array.

Zelf ga ik sowieso ook bezig met game servers. Wellicht op de SSD waar het OS op staat. Nog even kijken. Misschien op de harde schijf array.

En dan algemeen file host dingen. Af en toe katten foto's en video's uploaden die mijn broertje mij stuurt. Af en toe een desktop backup als ik een herinstallatie doe, zodat ik alles snel kan terughalen. Nextcloud, SMB shares.

Ik denk dat dat de voornaamste dingen zijn. Van IOPS en sustained writes en zo snap ik eigenlijk vrij weinig. Ik heb me geprobeerd erover in te lezen, maar het is nog een vak apart.

IOPS is hoeveel lees- en schrijf opdrachten de schijf kan verwerken. Bij een HDD is dat redelijk laag: tientallen tot hondertallen, Bij een SSD is dat al rap een factor 1000 hoger. Daarom dat een PC met SSD veel sneller start: er moeten bij het opstarten honderden tot misschien duizenden bestanden ingelezen en/of geschreven worden. Voor het delen van foto's (of filmpjes) vormen IOPS doorgaans geen bottleneck (zelfs niet bij trage schijven), tenzij je in grote bedrijfsomgevingen zit natuurlijk. Een gameserver kan hier misschien baat bij hebben, dat kan wel eens vershillen van spel tot spel. Vooral het opstarten van een VM zal merkbaar sneller gaan als die op een SSD staat in plaats van een HDD.

Dan zijn er sustained writes, daarmee doel je waarschijnlijk op de schrijfsnelheid van grote bestanden: hoe snel kan de schijf data wegschrijven als je er een groot bestand wil opzetten. We spreken bij moderne schijven (HDD) al rap van 100MB/s, wat voor het delen van foto's (of filmpjes) weer prima is. SSD's zijn hier een factor 5 tot pakweg 20 sneller, maar dat ga je denk ik enkel merken bij het uitpakken van grote bestanden. Gameservers gaan hier amper baat bij hebben, al kan dat weer verschillen van spel tot spel.

De performantie van RAIDZ2 kan inderdaad serieus inzakken, maar dat gebeurt dacht ik enkel als de array voor meer dan 80-90% vol staat. Volgens mij is het snelheidsverlies daaronder klein (ik heb er nooit iets van gemerkt hier). Tijd heeft dacht ik geen (merkbare) invloed op de snelheid, het is niet zo dat je server over 5 jaar automatisch een pak trager gaat zijn.

Kortom, voor je gebruik lijkt een RAIDZ2 me prima te zijn, alleen kan je overwegen om de VM's en gameservers op een SSD te zetten.

[ph0t0nix]

Amanoo schreef op zaterdag 6 februari 2021 @ 04:08:
Ik raak door de bomen een beetje het bos kwijt. Ik kom er nu echt niet achter welke vorm van RAID ik nu wil. Als RAIDZ-2 naar ietsjes trager is dan RAID10 neem ik net zo lief RAID-Z2. Als het beduidend trager is voldoet het niet aan mijn primaire doel. Dus wat wil ik nou?

Ik kan dit Ars Technica artikel van harte aanbevelen. Jim Salter vergelijkt daar ZFS mirrors en RAIDZ2 met hun traditionele tegenhangers, en dat voor verschillende soorten lees- en schrijfbenaderingen. En toevallig ook met 8 disks :-).

[Amanoo]

Klinkt alsof RAID-Z2 dan voor mij ook best prima is inderdaad. Ik denk dat voor mij met name sustained writes belangrijk zijn. Als die met een 8 drive RAID-Z2 ook een stuk vlotter gaan in vergelijking met single drive (en zo klinkt het wel), dan is Z2 toch wel erg prima.

[HyperBart]

Amanoo schreef op zaterdag 6 februari 2021 @ 09:05:
[...]

Er willen nog wel eens wat bestanden van rond de 10GB-15GB of soms 1-3GB worden gedownload, uiteraard volledig legaal Plan is dat ik nog een kleine oude SSD heb die ik als buffer gebruik voor Usenet downloads. Als die daar naartoe zijn gedownload komt het uitgepakte bestand op de harde schijf array. De SSD gebruik ik verder toch nergens anders meer voor

Heel goede inzet van een SSD, die opstelling gebruik ik al een jaar of 8 en is zeer performant. Alle intensieve taken gebeuren op de SSD en als het klaar is automatisch een move naar de disks.

Added bonus is dat je bij failed downloads ook je disks niet onnodig laat opspinnen of dat een trage download (door limiet bv owv bandbreedte nodig in huis voor andere dingen) niet noodzakelijk je disks lang aan de draai houdt.

[Amanoo]

HyperBart schreef op zaterdag 6 februari 2021 @ 15:15:
[...]


Heel goede inzet van een SSD, die opstelling gebruik ik al een jaar of 8 en is zeer performant. Alle intensieve taken gebeuren op de SSD en als het klaar is automatisch een move naar de disks.

Added bonus is dat je bij failed downloads ook je disks niet onnodig laat opspinnen of dat een trage download (door limiet bv owv bandbreedte nodig in huis voor andere dingen) niet noodzakelijk je disks lang aan de draai houdt.

Het was niet eens de reden dat ik het deed. Ik had gewoon iets snellers nodig omdat de harde schijf mijn downloads bottleneckte. Destijds had ik sowieso maar 1 schijf, dus ik kreeg ook geen performance boost dankzij striping, zoals ik hopelijk nu ga hebben dankzij RAID-Z2. Dat wat jij zegt was slechts een leuke bijkomstigheid. Maar nu heb ik toch die SSD, en niet echt een reden om nog iets met die SSD te doen behalve als buffer, dus hee. SATA naar M.2 adaptertje zodat mijn 8 SATA poorten beschikbaar blijven, en gaan met die banaan.

[player-x]

Amanoo schreef op zaterdag 6 februari 2021 @ 09:05:
Van IOPS en sustained writes en zo snap ik eigenlijk vrij weinig.

Voor privé gebruik van een server heeft IOPS en vooral sustained writes zeer weinig invloed, en in beperkte mate met zeer veel kleine files, zeker als je alleen maar een 1Gbit netwerk hebt, tenzij je VM's werkt dan heeft IOPS wel invloed en zou ik een SSD gebruiken.

Heb zelf een 10Gbit netwerk en zelfs daar heb ik met een 10 disk Z2 array geen/weinig beperkingen in snelheid qua doorvoer,

[Amanoo]

Ik heb net een RAID-Z2 pool gemaakt. 8x 2TB drives. Nu schijn ik 10TB te hebben volgens het commando zfs list. Zou dat niet 12TB moeten zijn? Waar is die 2TB heen? Ergens anders ik weer 11TB. 11TB is 10TiB, ongeveer. Dus ik mis nog steeds wat?

Niet dat ik wakker lig om het verschil, maar ik wil wel graag dat het allemaal klopt.

[Freeaqingme]

@Amanoo paste anders even de output van de commando's die je doet.

[Amanoo]

Freeaqingme schreef op donderdag 11 februari 2021 @ 15:30:
@Amanoo paste anders even de output van de commando's die je doet.

code:

marco@hoid:~$ sudo zfs list
NAME     USED  AVAIL     REFER  MOUNTPOINT
hdraid   793K  10.0T      205K  /hdraid

code:

marco@hoid:~$ sudo zpool status
  pool: hdraid
 state: ONLINE
config:

    NAME        STATE     READ WRITE CKSUM
    hdraid      ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        sda     ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sdf     ONLINE       0     0     0
        sdg     ONLINE       0     0     0
        sdh     ONLINE       0     0     0
        sdi     ONLINE       0     0     0

errors: No known data errors

code:

marco@hoid:~$ df -T -h /hdraid/
Filesystem     Type  Size  Used Avail Use% Mounted on
hdraid         zfs    11T  256K   11T   1% /hdraid

Het zijn 1.82TiB drives (oftewel 2TB). df -h geeft human-friendly units. 11TB dus, en 10TiB? Is er dan een halve disk weg?

[ Voor 10% gewijzigd door Amanoo op 11-02-2021 15:50 ]

[dcm360]

Voor df is het verschil simpel: df gebruikt TiB, en als ik 11TiB omreken (11*1024^4/1000^4) kom ik uit op 12TB.

[Amanoo]

dcm360 schreef op donderdag 11 februari 2021 @ 15:50:
Voor df is het verschil simpel: df gebruikt TiB, en als ik 11TiB omreken (11*1024^4/1000^4) kom ik uit op 12TB.

Maar ik gebruikte -h, dat is human-friendly. Dus TB en niet TiB als het goed is.

[dcm360]

Amanoo schreef op donderdag 11 februari 2021 @ 15:51:
[...]

Maar ik gebruikte -h, dat is human-friendly. Dus TB en niet TiB als het goed is.

-h is human-friendly, -H is si-eenheden. Misschien een beetje verwarrend.

[Amanoo]

dcm360 schreef op donderdag 11 februari 2021 @ 15:52:
[...]

-h is human-friendly, -H is si-eenheden. Misschien een beetje verwarrend.

Ah, met -H krijg ik er inderdaad 12T uit. Dan is het dus wel correct. Alleen is die 10.0T van zfs list een beetje vreemd.

[d3vlin]

d3vlin schreef op maandag 21 december 2020 @ 10:05:
[...]

Dank voor het uitgebreide antwoord op de vroege ochtend! Much appreciated Als het puur om kosten en weinig gedoe gaat is een 'reguliere' hardware/software RAID5 oplossing de makkelijke en vertrouwde route. Sterker nog, de server had al een hardware RAID controller die ik speciaal verwisseld heb voor een LBA controller om met ZFS aan de slag te kunnen.

De storage pool wordt effectief ~55TB (na RAIDZ2) maar orde van grootte kom je dan nog steeds op een enorme DDT uit natuurlijk. Het klinkt alsof genoeg RAM de meest bepalende factor is om dedup te laten slagen. Real life tests zullen moeten uitwijzen hoeveel dat is voor deze dataset. De server kan 768GB aan dus daar zit zeker headroom en de kosten voor eventueel extra geheugen zijn geen direct probleem.

Het chassis van de server ondersteunt 8 schijven en die zijn nu dus gevuld (8X10TB). Schijven er bij zetten betekent dus over naar een ander chassis. 60TB effectief met RAID5 biedt overigens zeker ook voldoende ruimte voor de toekomst, ik zie ZFS dedup als een mogelijkheid om binnen de huidige setup nog meer opslag mogelijk te maken die ik best wil onderzoeken. Als dat resulteert in een server die niet bruikbaar is dan is dat natuurlijk een valide reden om er vanaf te zien. Probleem hierbij is dat ik weinig/geen echte verhalen tegen kom over dedup op deze schaal. Als het een aantal seconden duurt om een bestandje te lezen, schrijven of deleten dan klinkt dat als 'niet bruikbaar'.

Ok. Tijd voor een update! De server draait inmiddels. Deze is uiteindelijk uitgerust met 12x10TB waarop een RAIDZ3 pool is aangemaakt met daarop een enkel ZVOL, effectief ~80TB beschikbaar. dedup en lz4 compressie zijn direct aangezet op het ZVOL en deze is inmiddels voor 30% gevuld. 'zpool list' geeft een dedup van 1.30x, wat conform verwachtingen is. Het geheugengebruik was na het vullen van de ZVOL 68GB. Ik heb zojuist als test een deel van de data verplaatst naar een ander tijdelijk ZVOL en weer teruggeplaatst naar het dedup ZVOL. Wat me opviel is dat daarna het geheugengebruik terug is gegaan naar 40GB? Is hier een verklaring voor?

Qua performance is de lees- en schijfsnelheid nog geen moment hinderlijk geweest. Later eens wat getallen produceren. Gezien het om een archive server gaat, is de I/O is buiten het vullen van de server erg beperkt en daarnaast is de gbit nic sowieso de bottleneck in het dagelijks gebruik.

So far so good dus!

Een aantal vragen waar ik tegenaan liep en waarvan ik hoop dat jullie inzicht kunnen geven:
- Ik zag dat het mogelijk is om een ander fs aan te maken op een ZVOL, bijvoorbeeld ext4. Waarom zou je dit doen?
- Alles data staat nu op een enkel ZVOL. Stel dat je meerdere ZVOLs aanmaakt, bijvoorbeeld om gedeeltes van de data te structuren en dedup staat aan op zpool niveau, is er dan ook deduplicatie tussen verschillende ZVOLs of blijft dit beperkt binnen het ZVOL zelf?
- Er zijn plannen voor een tweede identieke server die als backup server van deze archive server moet gaan werken. Het idee is om snapshots te maken en deze naar de andere server te sturen. Moet op de andere server dan ook een dedup ZVOL aangemaakt worden, of juist niet?
- Ook in het kader van de snapshots, zijn er redenen om kleinere delen van de data afzonderlijk te snapshotten of beter het hele ZVOL ineens?

[d3vlin]

Amanoo schreef op donderdag 11 februari 2021 @ 15:24:
Ik heb net een RAID-Z2 pool gemaakt. 8x 2TB drives. Nu schijn ik 10TB te hebben volgens het commando zfs list. Zou dat niet 12TB moeten zijn? Waar is die 2TB heen? Ergens anders ik weer 11TB. 11TB is 10TiB, ongeveer. Dus ik mis nog steeds wat?

Niet dat ik wakker lig om het verschil, maar ik wil wel graag dat het allemaal klopt.

Ik vond deze erg handig bij het bepalen van de uiteindelijke storage capacity:
https://wintelguy.com/zfs-calc.pl

Ook voor het vergelijken van twee alternatieven:
https://wintelguy.com/raidcalc2.pl

[ Voor 8% gewijzigd door d3vlin op 12-02-2021 12:18 ]

[CurlyMo]

d3vlin schreef op vrijdag 12 februari 2021 @ 12:09:
[...]
- Ik zag dat het mogelijk is om een ander fs aan te maken op een ZVOL, bijvoorbeeld ext4. Waarom zou je dit doen?

Zodat je een systeem dat ext4 vereist toch onder de motorkap ZFS kan laten gebruiken. Bijv. Docker containers.

- Alles data staat nu op een enkel ZVOL. Stel dat je meerdere ZVOLs aanmaakt, bijvoorbeeld om gedeeltes van de data te structuren en dedup staat aan op zpool niveau, is er dan ook deduplicatie tussen verschillende ZVOLs of blijft dit beperkt binnen het ZVOL zelf?

Alles wat je op pool niveau instelt, werkt op pool niveau. Behalve als je er op FS niveau ook nog een aanvullende setting voor moet instellen.

- Er zijn plannen voor een tweede identieke server die als backup server van deze archive server moet gaan werken. Het idee is om snapshots te maken en deze naar de andere server te sturen. Moet op de andere server dan ook een dedup ZVOL aangemaakt worden, of juist niet?

Nee, de ontvanger hoeft niet perse dedup aan te hebben staan.

- Ook in het kader van de snapshots, zijn er redenen om kleinere delen van de data afzonderlijk te snapshotten of beter het hele ZVOL ineens?

Dat is voorkeur. Kleinere delen zijn ook kleinere snapshots en dus makkelijker om in delen te repliceren. Of bepaalde ZVOL's niet te backuppen en andere wel.

[d3vlin]

Dank voor de antwoorden, kunnen we weer mee verder.

CurlyMo schreef op vrijdag 12 februari 2021 @ 12:58:
[...]

Nee, de ontvanger hoeft niet perse dedup aan te hebben staan.

Ter verduidelijking, het uitgangspunt is dat de kopie bij de ontvanger net zoveel ruimte in neemt als bij de verzender. (Daar wordt ook de filespace op ingericht). In dat geval is het wel nodig om dedup ook aan te hebben staan bij de ontvanger? En dan heeft de ontvanger ook dezelfde hoeveelheid RAM nodig om de snapshots te kunnen mounten?

Heb je ook een idee wat het verschil in geheugengebruik verklaart na de move operatie?

[ Voor 12% gewijzigd door d3vlin op 12-02-2021 14:10 ]

[CurlyMo]

d3vlin schreef op vrijdag 12 februari 2021 @ 14:10:
Ter verduidelijking, het uitgangspunt is dat de kopie bij de ontvanger net zoveel ruimte in neemt als bij de verzender. (Daar wordt ook de filespace op ingericht). In dat geval is het wel nodig om dedup ook aan te hebben staan bij de ontvanger? En dan heeft de ontvanger ook dezelfde hoeveelheid RAM nodig om de snapshots te kunnen mounten?

Klopt beide.

Heb je ook een idee wat het verschil in geheugengebruik verklaart na de move operatie?

Nee, nog niet over nagedacht

[RobertMe]

Ik heb een jaartje terug een Orange Pi 3 in gebruik genomen met een welbekende 5TB 2,5" Seagate schijf, dit voor offsite backups. So far so good en het ding doet het gewoon. Gisteren een schijf erbij geplaatst (wederom de bekende Seagate SMR), om er een mirror van te maken. Maar de boel wilt niet echt vlotten. Intussen ruim 20 uur verder en er is een kleine 250GB gedaan, van de 1,4TB. Waarbij de actuele snelheid zo rond de 3, 3,5 MB/s ligt.

Heeft iemand een idee wat hier de oorzaak van kan zijn? Uiteraard gaat het hier om de SMR schijven, maar nadat de schijf één keer helemaal gevuld is (onder Windows) en er nu een sequentiële write plaats vindt had ik toch iets meer verwacht. Andere oorzaken die ik mij kan bedenken: de USB-3 poorten van de Orange Pi kunnen niet (tegelijkertijd) de maximum snelheid aan, of de hardware is gewoon bij lange na niet krachtig genoeg (dus CPU, RAM, ...). Maar als de oorzaak in CPU/RAM zat zou ik verwachten dat ook te zien als die bv een send/receive van tientallen GBs moest doen en dat leek geen issues te geven.

Verder draait ook niks er op. Alleen elk uur een send/receive. Dus het is niet dat de schijven ook continu bezig zijn met andere taken. En het OS staat dan op interne eMMC, dus ook dat is het niet.

[Thralas]

RobertMe schreef op zaterdag 13 februari 2021 @ 09:52:
Heeft iemand een idee wat hier de oorzaak van kan zijn?

Ja, I/O all over the place en SMR.

Je bent niet heel erg scheutig met details, want je vertelt niet welke versie van ZFS je gebruikt en ook niet wat iets als iostat vertelt over disk utilization. Maar 't kan bijna niet missen..

Uiteraard gaat het hier om de SMR schijven, maar nadat de schijf één keer helemaal gevuld is (onder Windows) en er nu een sequentiële write plaats vindt had ik toch iets meer verwacht.

Je noemt het hier een sequentiële write, maar een traditionele resilver is allesbehalve sequentieel. Sequential reconstruction zit pas in ZFS 2.0 (zpool attach -s).

Probeer het eens met ZFS 2.0 en die optie zou ik zeggen.

[RobertMe]

Thralas schreef op zaterdag 13 februari 2021 @ 14:45:
[...]


Ja, I/O all over the place en SMR.

Je bent niet heel erg scheutig met details, want je vertelt niet welke versie van ZFS je gebruikt en ook niet wat iets als iostat vertelt over disk utilization. Maar 't kan bijna niet missen..


[...]


Je noemt het hier een sequentiële write, maar een traditionele resilver is allesbehalve sequentieel. Sequential reconstruction zit pas in ZFS 2.0 (zpool attach -s).

Probeer het eens met ZFS 2.0 en die optie zou ik zeggen.

Sorry, ik had inderdaad iets meer details mogen delen. ZFS versie is 0.8.4 van de Debian repo. Maar ik dacht juist dat daar al het hele sequentieel lezen & schrijven verhaal in zat? Of was dat alleen scrub en niet resilver?

Ik zie nu overigens dat er al in de 500GB doorheen is, terwijl die vanmorgen nog maar 200-250GB had gedaan. Dus op afgelopen ~5 uur een ruime verdubbeling ten opzichte van de 20 uur ervoor.

iostat ziet er nu dan ook beter uit:

robert@orangepi3:~$ /sbin/zpool iostat 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
backup      1.42T  3.13T     20     68  6.43M  7.75M
backup      1.42T  3.13T     13      3  3.99M  3.99M
backup      1.42T  3.13T     36     14  11.7M  11.7M
backup      1.42T  3.13T      9      2  2.99M  2.99M
backup      1.42T  3.13T     49     20  15.1M  16.0M
backup      1.42T  3.13T      4    105  2.00M  11.4M
backup      1.42T  3.13T     21     34  20.2M  16.2M
backup      1.42T  3.13T     68     47  47.4M  45.3M
backup      1.42T  3.13T     55     47  45.7M  46.1M
backup      1.42T  3.13T     75     44  36.9M  36.5M
backup      1.42T  3.13T     62     46  40.1M  40.6M
backup      1.42T  3.13T     52    152  29.1M  36.9M
backup      1.42T  3.13T     59     66  37.2M  30.2M
backup      1.42T  3.13T     83     61  30.2M  30.3M
backup      1.42T  3.13T     91     65  24.1M  22.9M
backup      1.42T  3.13T      2      2   383K   383K
^C

En voor de volledigheid de status:

robert@orangepi3:~$ /sbin/zpool status
  pool: backup
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Fri Feb 12 13:21:14 2021
        695G scanned at 7.73M/s, 578G issued at 6.43M/s, 1.42T total
        653G resilvered, 39.78% done, no estimated completion time
config:

        NAME                        STATE     READ WRITE CKSUM
        backup                      ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c500ccb58f5c  ONLINE       0     0     0
            wwn-0x5000c500d03a9860  ONLINE       0     0     0  (resilvering)

errors: No known data errors

Edit:
Nog beetje zitten zoeken. Systeem was al langere tijd niet geupdate, en blijkbaar is er een update naar ZFS 2. Wat ik nogal raar vond aangezien niet alle *zfs* packages naar 2 geupdate zouden worden. En nu kom ik erachter dat ARMBian blijkbaar ook hun eigen ZFS packages compiled, met dus afwijkende versies. Ik dacht dat zij alleen het broodnodige deden om Linux op deze bordjes te laten draaien. Dus alleen custom kernel en eventueel firmware gerelateerde zaken. Maar blijkbaar doen ze dus veel meer.

[ Voor 7% gewijzigd door RobertMe op 13-02-2021 15:31 ]

[Thralas]

RobertMe schreef op zaterdag 13 februari 2021 @ 14:58:
Sorry, ik had inderdaad iets meer details mogen delen. ZFS versie is 0.8.4 van de Debian repo. Maar ik dacht juist dat daar al het hele sequentieel lezen & schrijven verhaal in zat? Of was dat alleen scrub en niet resilver?

Dat is inderdaad erg verwarrend.

Over de change in 0.8:

quote: https://zfsonlinux.topicb...rmance-in-zol-constrained

You didn't mention the version of ZFS on Linux that you're using. If you want maximum resilver performance, you absolutely need to be using 0.8.0, which has an important feature called 'sequential scrubs' (and resilvers). You also want a system with a decent amount of memory, because the amount of resilver and scrub activity that ZFS will sort into sequential order and then issue is limited to what it can keep track of in 5% of physical memory (in the current code).

Sequential reconstruction (2.0):

quote: https://github.com/openzfs/zfs/pull/10349

The sequential reconstruction feature adds a more traditional RAID rebuild mechanism to ZFS. Specifically, it allows for mirror vdevs to be rebuilt in LBA order. Depending on the pools average block size, overall fragmentation, and the performance characteristics of the devices (SMR) sequential reconstruction can restore redundancy in less time than a traditional healing resilver.

De eerdere change zorgt er alleen voor dat I/O tijdens een resilver zo sequentieel mogelijk wordt geissued, maar dat kent limieten.

De nieuwe feature werkt daadwerkelijk in LBA order, dat is pas echt sequentiëel. Merk op dat Behlendorf SMR specifiek benoemt, maar zelf test met conventionele disks en alsnog een 2x speedup haalt. In jouw geval zou dat nog eens een heel stuk sneller kunnen gaan.

Als je het nog wilt proberen met 2.0: Alpine Linux kun je van een (kleine) USB device booten, met 'apk add zfs` heb je ZFS 2.0+. De rebuild feature kun je volgens mij gebruiken zonder de pool te hoeven upgraden.

[ Voor 3% gewijzigd door Thralas op 13-02-2021 15:40 ]

[RobertMe]

Thralas schreef op zaterdag 13 februari 2021 @ 15:39:
Als je het nog wilt proberen met 2.0: Alpine Linux kun je van een (kleine) USB device booten, met 'apk add zfs` heb je ZFS 2.0+. De rebuild feature kun je volgens mij gebruiken zonder de pool te hoeven upgraden.

In de ARMBian repo zit dus blijkbaar ook ZFS 2.0 Alleen heb ik nu ogenschijnlijk het systeem gesloopt. Updates gedaan, reboot, maar krijg geen (SSH) verbinding meer Dat wordt dus een dezer dagen het systeem even ophalen.

[d3vlin]

d3vlin schreef op vrijdag 12 februari 2021 @ 12:09:
[...]

Ok. Tijd voor een update! De server draait inmiddels. Deze is uiteindelijk uitgerust met 12x10TB waarop een RAIDZ3 pool is aangemaakt met daarop een enkel ZVOL, effectief ~80GB beschikbaar. dedup en lz4 compressie zijn direct aangezet op het ZVOL en deze is inmiddels voor 30% gevuld. 'zpool list' geeft een dedup van 1.30x, wat conform verwachtingen is. Het geheugengebruik was na het vullen van de ZVOL 68GB. Ik heb zojuist als test een deel van de data verplaatst naar een ander tijdelijk ZVOL en weer teruggeplaatst naar het dedup ZVOL. Wat me opviel is dat daarna het geheugengebruik terug is gegaan naar 40GB? Is hier een verklaring voor?

Qua performance is de lees- en schijfsnelheid nog geen moment hinderlijk geweest. Later eens wat getallen produceren. Gezien het om een archive server gaat, is de I/O is buiten het vullen van de server erg beperkt en daarnaast is de gbit nic sowieso de bottleneck in het dagelijks gebruik.

So far so good dus!

Toch een stevig punt gevonden. Het deleten van dedup data is onacceptabel langzaam. Het verwijderen van een zvol (zfs destroy) of folder (rm -rf) met dedup aan van circa 15GB duurde ruim een half uur! Dezelfde handelingen op een verder identiek zvol zonder dedup duurde slechts enkele seconden.

Het systeem blijft tijdens deze operaties prima benaderbaar en de load blijft laag, maar alle overige IO van/naar de zpool bevriest. Als ik via htop kijk is er een 100% IO wait op 2 van de 24 threads, de rest van de CPU threads doen niets. Geheugen blijft stabiel op circa 40 van de 128GB. Systeem gebruikt dus zeker niet de maximale resources. In de kernel logs een herhaling van het volgende:

code:

Feb 13 18:38:01 store kernel: [ 1210.764946] INFO: task rm:36059 blocked for more than 120 seconds.
Feb 13 18:38:01 store kernel: [ 1210.765006]       Tainted: P           OE     4.19.0-14-amd64 #1 Debian 4.19.171-2
Feb 13 18:38:01 store kernel: [ 1210.765063] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 13 18:38:01 store kernel: [ 1210.765122] rm              D    0 36059  19546 0x00000000
Feb 13 18:38:01 store kernel: [ 1210.765126] Call Trace:
Feb 13 18:38:01 store kernel: [ 1210.765138]  __schedule+0x29f/0x840
Feb 13 18:38:01 store kernel: [ 1210.765143]  schedule+0x28/0x80
Feb 13 18:38:01 store kernel: [ 1210.765146]  io_schedule+0x12/0x40
Feb 13 18:38:01 store kernel: [ 1210.765162]  cv_wait_common+0xaf/0x130 [spl]
Feb 13 18:38:01 store kernel: [ 1210.765169]  ? finish_wait+0x80/0x80
Feb 13 18:38:01 store kernel: [ 1210.765283]  txg_wait_open+0x8a/0xd0 [zfs]
Feb 13 18:38:01 store kernel: [ 1210.765356]  dmu_free_long_range+0x2fe/0x4b0 [zfs]
Feb 13 18:38:01 store kernel: [ 1210.765455]  zfs_rmnode+0x262/0x330 [zfs]
Feb 13 18:38:01 store kernel: [ 1210.765554]  ? zfs_zinactive+0xdc/0xf0 [zfs]
Feb 13 18:38:01 store kernel: [ 1210.765649]  zfs_inactive+0x84/0x210 [zfs]
Feb 13 18:38:01 store kernel: [ 1210.765655]  ? unmap_mapping_pages+0x5e/0x130
Feb 13 18:38:01 store kernel: [ 1210.765749]  zpl_evict_inode+0x3c/0x50 [zfs]
Feb 13 18:38:01 store kernel: [ 1210.765756]  evict+0xd2/0x1a0
Feb 13 18:38:01 store kernel: [ 1210.765761]  do_unlinkat+0x263/0x300
Feb 13 18:38:01 store kernel: [ 1210.765768]  do_syscall_64+0x53/0x110
Feb 13 18:38:01 store kernel: [ 1210.765774]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Feb 13 18:38:01 store kernel: [ 1210.765778] RIP: 0033:0x7fdb10993ff7
Feb 13 18:38:01 store kernel: [ 1210.765786] Code: Bad RIP value.
Feb 13 18:38:01 store kernel: [ 1210.765788] RSP: 002b:00007ffc705e7a98 EFLAGS: 00000246 ORIG_RAX: 0000000000000107
Feb 13 18:38:01 store kernel: [ 1210.765791] RAX: ffffffffffffffda RBX: 0000559a9db8f300 RCX: 00007fdb10993ff7
Feb 13 18:38:01 store kernel: [ 1210.765793] RDX: 0000000000000000 RSI: 0000559a9db8f408 RDI: 0000000000000005
Feb 13 18:38:01 store kernel: [ 1210.765795] RBP: 0000559a9db83400 R08: 0000000000000003 R09: 0000000000000000
Feb 13 18:38:01 store kernel: [ 1210.765797] R10: 0000000000000007 R11: 0000000000000246 R12: 00007ffc705e7c80
Feb 13 18:38:01 store kernel: [ 1210.765798] R13: 0000000000000000 R14: 0000559a9db8f300 R15: 0000000000000000

en eerder ook:

code:

Feb  8 19:28:50 store kernel: [544098.075893] INFO: task txg_sync:1635 blocked for more than 120 seconds.
Feb  8 19:28:50 store kernel: [544098.075958]       Tainted: P           OE     4.19.0-14-amd64 #1 Debian 4.19.171-2
Feb  8 19:28:50 store kernel: [544098.076019] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb  8 19:28:50 store kernel: [544098.076075] txg_sync        D    0  1635      2 0x80000000
Feb  8 19:28:50 store kernel: [544098.076080] Call Trace:
Feb  8 19:28:50 store kernel: [544098.076105]  __schedule+0x29f/0x840
Feb  8 19:28:50 store kernel: [544098.076124]  schedule+0x28/0x80
Feb  8 19:28:50 store kernel: [544098.076128]  schedule_timeout+0x16b/0x3b0
Feb  8 19:28:50 store kernel: [544098.076135]  ? __next_timer_interrupt+0xc0/0xc0
Feb  8 19:28:50 store kernel: [544098.076137]  io_schedule_timeout+0x19/0x40
Feb  8 19:28:50 store kernel: [544098.076150]  __cv_timedwait_common+0x125/0x160 [spl]
Feb  8 19:28:50 store kernel: [544098.076156]  ? finish_wait+0x80/0x80
Feb  8 19:28:50 store kernel: [544098.076229]  zio_wait+0x12a/0x260 [zfs]
Feb  8 19:28:50 store kernel: [544098.076269]  spa_sync+0x5d5/0xf60 [zfs]
Feb  8 19:28:50 store kernel: [544098.076273]  ? mutex_lock+0xe/0x30
Feb  8 19:28:50 store kernel: [544098.076364]  ? spa_txg_history_init_io+0xfe/0x110 [zfs]
Feb  8 19:28:50 store kernel: [544098.076450]  txg_sync_thread+0x294/0x460 [zfs]
Feb  8 19:28:50 store kernel: [544098.076457]  ? __switch_to_asm+0x35/0x70
Feb  8 19:28:50 store kernel: [544098.076543]  ? txg_thread_exit.isra.9+0x60/0x60 [zfs]
Feb  8 19:28:50 store kernel: [544098.076552]  ? __thread_exit+0x20/0x20 [spl]
Feb  8 19:28:50 store kernel: [544098.076560]  thread_generic_wrapper+0x6f/0x80 [spl]
Feb  8 19:28:50 store kernel: [544098.076568]  kthread+0x112/0x130
Feb  8 19:28:50 store kernel: [544098.076572]  ? kthread_bind+0x30/0x30
Feb  8 19:28:50 store kernel: [544098.076576]  ret_from_fork+0x35/0x40

Dit ging om een eenvoudige test en op een relatief klein stukje data. Deleten van data is niet de primaire use case van een storage server, maar het moet natuurlijk wel redelijkerwijs kunnen. Ik voorzie vooral dat dit problemen op gaat leveren als er straks oude snapshots van een dedup zvol verwijderd moeten gaan worden. We zijn er op voorbereid dat dedup veel geheugen nodig heeft (en dat lijkt dus ook nog niet maximaal gebruikt te worden), maar dit lijkt iets anders te zijn.

Wat verdere context:

code:

Linux archive 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux

ii  libzfs2linux                       0.8.6-1~bpo10+1              amd64        OpenZFS filesystem library for Linux
ii  zfs-dkms                           0.8.6-1~bpo10+1              all          OpenZFS filesystem kernel modules for Linux
ii  zfs-zed                            0.8.6-1~bpo10+1              amd64        OpenZFS Event Daemon
ii  zfsutils-linux                     0.8.6-1~bpo10+1              amd64        command-line tools to manage OpenZFS filesystems

Via Google her en der vergelijkbare ervaringen met het deleten op zfs (en in het bijzonder met dedup aan), maar deze posts zijn veelal uit 2015 of eerder. Ik hoop dat hier een verklaring/oplossing voor is, anders is het denk ik toch einde dedup. Iemand tips?

[ Voor 25% gewijzigd door d3vlin op 14-02-2021 10:37 ]

[Thralas]

d3vlin schreef op zondag 14 februari 2021 @ 10:13:
Via Google her en der vergelijkbare ervaringen met het deleten op zfs (en in het bijzonder met dedup aan), maar deze posts zijn veelal uit 2015 of eerder. Ik hoop dat hier een verklaring/oplossing voor is, anders is het denk ik toch einde dedup. Iemand tips?

Ja, deletes veroorzaken random writes naar de DDT, en/of reads als het ding nog niet paged in is. Zie deze twee interessante comments:

Extreme load when deleting large file on full ZFS Filesystem #6823
Large Deletes & Memory Consumption #6783

Je gebruikt RAIDZ, dus dan haal je qua IOPS niet veel meer dan een enkele drive. Niet de plek waar je je DDT wilt opslaan, zo blijkt.

Ik zie in je posts niets meer over SSDs: wat heb je daar uiteindelijk mee gedaan? Een mirror van twee (of drie) special vdevs zou hier wel eens enorm kunnen schelen (die lusten wel wat random IOPS).

En een sidenote: kennelijk geef je zo enorm veel om storage-efficiëntie dat je dedup gebruikt, maar vervolgens comprimeer je met lz4. Ik zou persoonlijk ook zstd (ZFS 2.0+) overwegen, ondanks het nieuwige win je daar bytes mee die min-of-meer gratis zijn, itt. de prijs die je voor dedup betaalt.

[ Voor 4% gewijzigd door Thralas op 14-02-2021 12:04 ]

[d3vlin]

De hele DDT zou toch in het RAM moeten staan zolang er RAM beschikbaar is? Systeem is uitgerust met 128GB RAM waarvan ~40-64GB in gebruik dus dat zou goed moeten gaan. SWAP is 0, wordt niet gebruikt. Zonder dedup is de 15GB zo verwijderd, dus de IO van de data zelf kan eigenlijk niet de bottleneck zijn. Dan blijft de DDT over, het grote verschil met dedup aan natuurlijk. Als de DDT op schijf staat ipv in RAM dan zou dat de IO wait verklaren, maar met voldoende geheugen zou dat toch niet het geval moeten zijn? Ik ben relatief nieuw met ZFS dus ik leer graag.

Ik begreep dat ARC in RAM altijd de voorkeur heeft boven L2ARC op SSD's. Vandaar dat we gekozen hebben om genoeg geheugen te installeren ipv SSD's. Dat kan tot op het niveau dat we er gewoon geheugen bij blijven gooien als de DDT groter wordt naar mate de zpool voller raakt. Kan max 768GB in deze server dus daar zit nog wel wat headroom.

zstd ipv lz4 is zeker interessant en heb ik inderdaad al even bekeken (gzip ipv lz4 trouwens ook). Systeem heeft ruim voldoende CPU/RAM om te encoden/decoden terwijl IO en gbit NIC de bottleneck zijn. Het enige wat me tegen houdt is dat zfs 2.0 alleen nog maar in Debian testing/unstable staat (en dat trekt ook weer wat testing/unstable dependencies mee naar de rest van het systeem). Voor nu in de testfase niet zo'n probleem, maar uiteindelijk moet deze server wel in productie en dus stabiel zijn.

[ Voor 39% gewijzigd door d3vlin op 14-02-2021 14:28 ]

[Thralas]

d3vlin schreef op zondag 14 februari 2021 @ 12:13:
De hele DDT zou toch in het RAM moeten staan zolang er RAM beschikbaar is? Systeem is uitgerust met 128GB RAM waarvan ~40-64GB in gebruik dus dat zou goed moeten gaan.

Eens. Mits hij niet net geboot is natuurlijk. Kun je eens de output van zdb -DD en zpool status -D posten? Volgens mij kun je daarmee zien hoeveel entries paged in zijn (en hoe groot het geheel is).

En met zpool iostat kun je waarschijnlijk wel bepalen of het reads of writes zijn.

Dan blijft de DDT over, het grote verschil met dedup aan natuurlijk. Als de DDT op schijf staat ipv in RAM dan zou dat de IO wait verklaren, maar met voldoende geheugen zou dat toch niet het geval moeten zijn? Ik ben relatief nieuw met ZFS dus ik leer graag.

Die moet natuurlijk altijd op disk bijgehouden worden, anders zou je na een reboot de hele disk moeten lezen om de DDT op te bouwen.

Dus een write naar een file impliceert ook DDT writes. Zie Zero performance overhead OpenZFS dedup, die een niet erg rooskleurig beeld schetsen van de I/O overhead: een factor ~7.

Nu zijn die slides oud, en stelt Ahrens verbeteringen voor, maar ik vraag me af of die het ooit hebben gehaald - er wordt weinig prioriteit gegeven aan dedup.

Ik begreep dat ARC in RAM altijd de voorkeur heeft boven L2ARC op SSD's. Vandaar dat we gekozen hebben om genoeg geheugen te installeren ipv SSD's. Dat kan tot op het niveau dat we er gewoon geheugen bij blijven gooien als de DDT groter wordt naar mate de zpool voller raakt. Kan max 768GB in deze server dus daar zit nog wel wat headroom.

Sure, maar L2ARC is ook de minst interessante use case. De special vdev cachet ddt en metadata. Dat laatste is het voor mij al absoluut waard in een disk array, dan is een find tenminste wel snel.

Als ik die slides zie vraag ik me ook af waarom men het zwaartepunt lijkt te leggen bij het hebben van genoeg memory. Als die slides (nog) kloppen dan is er altijd sprake van veel I/O overhead, ook als de DDT in memory leeft.

Anyhow, zou het even testen met wat special vdevs (of dedup als je SSDs heel klein zijn). Daarvoor zul je helaas wel de pool opnieuw moeten schrijven vrees ik.

Het enige wat me tegen houdt is dat zfs 2.0 alleen nog maar in Debian testing/unstable staat (en dat trekt ook weer wat testing/unstable dependencies mee naar de rest van het systeem). Voor nu in de testfase niet zo'n probleem, maar uiteindelijk moet deze server wel in productie en dus stabiel zijn.

Dat is inderdaad niet heel handig. Voordeel van CentOS/ZFS is dat OpenZFS daar zelf packages voor publiceert. Als je niet een Debian-only shop runt zou ik dat overwegen voor zo'n fileserver.

[d3vlin]

Gisteren nog wat tests gedaan. Nieuwe zpool gemaakt, daarop 2 zvols met circa 350GB aan data gevuld, eentje met dedup en eentje zonder dedup (verder identiek).
- Deleten van ~100GB/~3300 files op het zvol zonder dedup: ~8 seconden.
- Deleten van dezelfde ~100GB/~3300 files op het zvol met dedup: ~41 seconden.
Dat het langer duurt met dedup is uiteraard aannemelijk vanwege de DDT die bijgewerkt moet worden en komt inderdaad redelijk overeen met de genoemde factor 7.

Op zich mooi dat het deleten van dedup nu gewoon netjes afgerond wordt. Deleten van dezelfde ~100GB/~3300 files aan data op het eerdere zvol met 23TB aan dedup data heb ik na een uur wachten maar gewoon afgekapt, categorie onwerkbaar. Dat het nu wel lukt lijkt mij te verklaren doordat de DDT nu veel kleiner is (maar 350GB aan dedup data ipv 23TB). In dat geval maar eens experimenteren met een andere blocksize/recordsize voor de grote dataset.

Geheugengebruik is nu overigens net als eerder ook weer 68GB/128GB, ondanks de veel kleinere (dedup) dataset. Ik las ook ergens dat zfs standaard gewoon de helft van het geheugen alvast reserveert dus dat kan het ook verklaren. Met het eerdere zvol met 23TB aan dedup data was het geheugengebruik ook ongeveer 68GB/128GB totdat het zakte naar 40GB/128GB na een move operatie (zie hierboven).

[ Voor 9% gewijzigd door d3vlin op 15-02-2021 22:05 ]

[ocaj]

d3vlin schreef op maandag 15 februari 2021 @ 14:17:

Geheugengebruik is nu overigens net als eerder ook weer 68GB/128GB, ondanks de veel kleinere (dedup) dataset. Ik las ook ergens dat zfs standaard gewoon de helft van het geheugen alvast reserveert dus dat kan het ook verklaren.

Als het een pure fileserver is dan is er niets dat je tegenhoudt om ZFS meer geheugen te laten gebruiken voor ARC. Geheugen is er immers om gebruikt te worden!

Hint: de tunable die je moet hebben is: zfs_arc_max

[Chrisiesmit93]

Voormalige Xpenology gebruiker hier, ik ben sinds kort TrueNAS in combi met ZFS aan het testen, maar de 1e resultaten vind ik nog niet zo rooskleurig (vergeleken met Xpenology).

Ik heb TrueNAS binnen ESXi geïnstalleerd (net zoals voorheen met Xpenology) en heb de onboard SATA controller waar de disks aan hangen dmv passtrough "rechtstreeks" aan TrueNAS gekoppeld.
De disks bestaan uit 3x ST8000DM004 en 1x WDC WD80EDAZ (1 ST8000DM004 was gesneuveld dacht ik, maar is toch niet stuk blijkt nadat ik hem had vervangen door de WD disk).

Het probleem is dat ik de pool "traag" vind, voorheen had ik met Xpenology 4x 8tb disks in raid-5 opstelling ongeveer 150-200 MB/s via SMB.

Ik gebruik nu TrueNAS met mirror vdev (als ik het goed zeg) en haal met dezelfde disks ~50MB/s read en ~80MB/s write, dit met 10GB RAM (ook via SMB).

Ik heb getest met en zonder autotune (ben nieuw met ZFS dus eventuele optimalisaties en dergelijke weet ik nog niet), maar voordat ik autotune aanzetten en toen autotune eenmaal aanstond (na reboot), was er niet veel (merkbaar) prestatieverschil.

Onderstaand commando gaf als output 55102941 bytes/sec -> ~55.10 MB / s

code:

/usr/bin/time -h dd if=/dev/zero of=sometestfile bs=1024 count=10

Onderstaand commando gaf als output 89785969 bytes/sec -> ~89.79 MB / s

code:

/usr/bin/time -h dd if=sometestfile of=/dev/null bs=1024 count=10

Het betreft de volgende pool:

code:

  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:00:00 with 0 errors on Sun Jan 31 12:13:22 2021
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            gptid/1d7cd54e-63b5-11eb-b5a2-005056a8a87c  ONLINE       0     0     0
            gptid/1dcc2a67-63b5-11eb-b5a2-005056a8a87c  ONLINE       0     0     0
          mirror-1                                      ONLINE       0     0     0
            gptid/1d882632-63b5-11eb-b5a2-005056a8a87c  ONLINE       0     0     0
            gptid/1df4d29e-63b5-11eb-b5a2-005056a8a87c  ONLINE       0     0     0

Als ik onderstaand command op de 4 disken loslaat, krijg ik het volgende resultaat:

code:

diskinfo -ctv /dev/ada0
I/O command overhead:
        time to read 10MB block      0.392794 sec       =    0.019 msec/sector
        time to read 20480 sectors   4.425186 sec       =    0.216 msec/sector
        calculated command overhead                     =    0.197 msec/sector

Seek times:
        Full stroke:      250 iter in   8.001474 sec =   32.006 msec
        Half stroke:      250 iter in   5.297096 sec =   21.188 msec
        Quarter stroke:   500 iter in   9.008446 sec =   18.017 msec
        Short forward:    400 iter in   3.434901 sec =    8.587 msec
        Short backward:   400 iter in   1.677832 sec =    4.195 msec
        Seq outer:       2048 iter in   0.322322 sec =    0.157 msec
        Seq inner:       2048 iter in  24.428801 sec =   11.928 msec

Transfer rates:
        outside:       102400 kbytes in   0.562015 sec =   182202 kbytes/sec
        middle:        102400 kbytes in   0.662729 sec =   154513 kbytes/sec
        inside:        102400 kbytes in   1.522812 sec =    67244 kbytes/sec

diskinfo -ctv /dev/ada1
I/O command overhead:
        time to read 10MB block      0.059140 sec       =    0.003 msec/sector
        time to read 20480 sectors   4.356374 sec       =    0.213 msec/sector
        calculated command overhead                     =    0.210 msec/sector

Seek times:
        Full stroke:      250 iter in   7.977661 sec =   31.911 msec
        Half stroke:      250 iter in   5.192299 sec =   20.769 msec
        Quarter stroke:   500 iter in   8.667457 sec =   17.335 msec
        Short forward:    400 iter in   3.398716 sec =    8.497 msec
        Short backward:   400 iter in   1.399388 sec =    3.498 msec
        Seq outer:       2048 iter in   0.574570 sec =    0.281 msec
        Seq inner:       2048 iter in  20.750071 sec =   10.132 msec

Transfer rates:
        outside:       102400 kbytes in   0.606931 sec =   168718 kbytes/sec
        middle:        102400 kbytes in   0.772741 sec =   132515 kbytes/sec
        inside:        102400 kbytes in   1.399053 sec =    73192 kbytes/sec


[b]diskinfo -ctv /dev/ada2[/b]
I/O command overhead:
        time to read 10MB block      0.061767 sec       =    0.003 msec/sector
        time to read 20480 sectors   1.265154 sec       =    0.062 msec/sector
        calculated command overhead                     =    0.059 msec/sector

Seek times:
        Full stroke:      250 iter in   6.972497 sec =   27.890 msec
        Half stroke:      250 iter in   4.356467 sec =   17.426 msec
        Quarter stroke:   500 iter in   6.428882 sec =   12.858 msec
        Short forward:    400 iter in   1.452658 sec =    3.632 msec
        Short backward:   400 iter in   1.698970 sec =    4.247 msec
        Seq outer:       2048 iter in   0.088152 sec =    0.043 msec
        Seq inner:       2048 iter in   0.168332 sec =    0.082 msec

Transfer rates:
        outside:       102400 kbytes in   0.491496 sec =   208344 kbytes/sec
        middle:        102400 kbytes in   0.593819 sec =   172443 kbytes/sec
        inside:        102400 kbytes in   1.100336 sec =    93062 kbytes/sec


diskinfo -ctv /dev/ada3
I/O command overhead:
        time to read 10MB block      0.067866 sec       =    0.003 msec/sector
        time to read 20480 sectors   4.440702 sec       =    0.217 msec/sector
        calculated command overhead                     =    0.214 msec/sector

Seek times:
        Full stroke:      250 iter in   7.984825 sec =   31.939 msec
        Half stroke:      250 iter in   5.317585 sec =   21.270 msec
        Quarter stroke:   500 iter in   8.549404 sec =   17.099 msec
        Short forward:    400 iter in   3.373229 sec =    8.433 msec
        Short backward:   400 iter in   1.632390 sec =    4.081 msec
        Seq outer:       2048 iter in   0.321330 sec =    0.157 msec
        Seq inner:       2048 iter in  19.560736 sec =    9.551 msec

Transfer rates:
        outside:       102400 kbytes in   0.558742 sec =   183269 kbytes/sec
        middle:        102400 kbytes in   0.631326 sec =   162198 kbytes/sec
        inside:        102400 kbytes in   1.346460 sec =    76051 kbytes/sec

Weet iemand of bovenstaande cijfers correct zijn voor de hardware die ik heb, of valt er nog meer snelheid uit te behalen?

[FireDrunk]

Heb je ook al eens lokaal op TrueNAS getest? Want mogelijk zit het verschil eerder in Samba (SMB) dan in ZFS?

Of zijn die DD tests die je doet lokaal? (Want je zegt via SMB).
Nevermind, je zegt ook via SMB... mijn fout.

Staat sync aan? dd kan iets anders werken op BSD dan op Linux (wel of geen sync enzo).

[ Voor 52% gewijzigd door FireDrunk op 18-02-2021 09:57 ]

[Chrisiesmit93]

Excuus voor de verwarring, de 1e testen die ik zei (zonder de codeblocks, zijn over SMB.
Alle testen daaronder in de codeblocks, zijn allemaal lokaal uitgevoerd.

FireDrunk schreef op donderdag 18 februari 2021 @ 09:55:
[s]Staat sync aan? dd kan iets anders werken op BSD dan op Linux (wel of geen sync enzo).

@FireDrunk

code:

zfs get sync tank
NAME  PROPERTY  VALUE     SOURCE
tank  sync      standard  default

[ Voor 50% gewijzigd door Chrisiesmit93 op 18-02-2021 10:01 ]

[FireDrunk]

Ah, ik zie dat je bs=1024 doet, dat is een block size van 1KB, das niet zo hoog.

Probeer eens 1M of zelfs 16M.

SMB kan traag zijn omdat Samba soms wat tuning vereist op FreeBSD om wat snelheid te maken. Persoonlijk ben ik meer fan van NFS, maar dat hoeft zeker geen antwoord op jouw probleem te zijn

Kort door de bocht: een stripe van 2 mirrors van 2 relatief moderne schijven die 'maar' 80MB/s haalt is in mijn ogen te laag, dat zou sneller moeten kunnen.

[ Voor 20% gewijzigd door FireDrunk op 18-02-2021 10:03 ]

[Chrisiesmit93]

code:

root@nas-01[/mnt/tank]# /usr/bin/time -h dd if=/dev/zero of=sometestfile bs=16M count=10
167772160 bytes transferred in 0.063065 secs (2660289580 bytes/sec)  -> ~2660 MB / s

code:

root@nas-01[/mnt/tank]# /usr/bin/time -h dd if=sometestfile of=/dev/null bs=16M count=10
167772160 bytes transferred in 0.045975 secs (3649169129 bytes/sec)  -> ~3649 MB/s

Ik gebruik SMB omdat ik dit prettig vind werken, ook met ACL's in combi met Active Directory en dergelijke

[FireDrunk]

2.6GB/s klinkt alsof er veel caching gebeurt

Kan je eens

iflag=O_DIRECT

toevoegen aan je commando's?

offtopic:
bron: https://www.freebsd.org/cgi/man.cgi?dd(1)

[ Voor 29% gewijzigd door FireDrunk op 18-02-2021 10:13 ]

[Chrisiesmit93]

Dat had ik ook al in gedachten ja, anders zijn het hele snelle HDD's!

De flag die jij vraagt kent ie helaas niet

code:

root@nas-01[/mnt/tank]# /usr/bin/time -h dd if=/dev/zero of=sometestfile bs=16M count=10 iflag=O_DIRECT
dd: unknown iflag O_DIRECT

Als ik vervolgens probeer met onderstaand command, dan krjg ik ongeveer dezelfde (cache) snelheden

code:

root@nas-01[/mnt/tank]# /usr/bin/time -h dd if=/dev/zero of=sometestfile bs=16M count=10 oflag=direct
10+0 records in
10+0 records out
167772160 bytes transferred in 0.062672 secs (2676993898 bytes/sec)

Ik weet niet of dit voor hier een nuttige test is, maar dit vond ik zojuist:

code:

root@nas-01[/mnt/tank]# fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --runtime=60 --time_based --end_fsync=1
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.19
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [F(1)][100.0%][w=8766KiB/s][w=2191 IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=3195: Thu Feb 18 10:24:23 2021
  write: IOPS=7965, BW=31.1MiB/s (32.6MB/s)(1886MiB/60620msec)
    slat (nsec): min=1056, max=20947k, avg=32495.90, stdev=78569.05
    clat (nsec): min=981, max=53262k, avg=90561.32, stdev=575737.68
     lat (usec): min=13, max=53329, avg=123.06, stdev=577.67
    clat percentiles (nsec):
     |  1.00th=[    1096],  5.00th=[    1208], 10.00th=[    1368],
     | 20.00th=[    1432], 30.00th=[    1496], 40.00th=[    1656],
     | 50.00th=[   34560], 60.00th=[   56064], 70.00th=[   60672],
     | 80.00th=[   73216], 90.00th=[  203776], 95.00th=[  268288],
     | 99.00th=[  481280], 99.50th=[  806912], 99.90th=[10813440],
     | 99.95th=[10944512], 99.99th=[15007744]
   bw (  KiB/s): min= 9353, max=48284, per=100.00%, avg=32197.61, stdev=8246.64, samples=114
   iops        : min= 2338, max=12071, avg=8049.04, stdev=2061.66, samples=114
  lat (nsec)   : 1000=0.01%
  lat (usec)   : 2=43.41%, 4=1.46%, 10=0.13%, 20=4.26%, 50=4.18%
  lat (usec)   : 100=31.43%, 250=9.27%, 500=4.92%, 750=0.40%, 1000=0.09%
  lat (msec)   : 2=0.16%, 4=0.03%, 10=0.01%, 20=0.25%, 50=0.01%
  lat (msec)   : 100=0.01%
  cpu          : usr=2.03%, sys=4.14%, ctx=503460, majf=1, minf=1
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,482863,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=31.1MiB/s (32.6MB/s), 31.1MiB/s-31.1MiB/s (32.6MB/s-32.6MB/s), io=1886MiB (1978MB), run=60620-60620msec

[ Voor 66% gewijzigd door Chrisiesmit93 op 18-02-2021 10:25 ]

[FireDrunk]

Random Write van 31MB/s klinkt niet slecht, Sequential write is mogelijk iets interessanter.

[Chrisiesmit93]

Maar ik begrijp uit jouw reactie dat de pool nog wel sneller zou moeten kunnen werken ?

Persoonlijk zou ik verwachten dat een read / write van (single file zonder caching oid) minimaal 100-150 MB/s wel minimaal zou moeten lukken, of zit ik er dan naast ?

[Sando]

Is het ook mogelijk om een 3x 8TB RAIDZ te maken waarvan één 8T bestaat uit 2x 4T?

	pool
	  raidz1 vdev
	    Fysieke 8TB hdd 1
	    Fysieke 8TB hdd 2
	    Virtuele 8TB vdev
		  Fysieke 4TB hdd 1
		  Fysieke 4TB hdd 2

[CurlyMo]

Sando schreef op donderdag 18 februari 2021 @ 17:08:
Is het ook mogelijk om een 3x 8TB RAIDZ te maken waarvan één 8T bestaat uit 2x 4T?

	pool
	  raidz1 vdev
	    Fysieke 8TB hdd 1
	    Fysieke 8TB hdd 2
	    Virtuele 8TB vdev
		  Fysieke 4TB hdd 1
		  Fysieke 4TB hdd 2

Ja

[Q]

Iemand al naar ZFS draid gekeken?

[cville]

Ik ben mijn eerste ZFS-based server aan het ontwerpen en zou graag advies krijgen m.b.t. de storage configuratie. De vragen betreffen in eerste instantie de indeling en niet de hardware.

Eerst de use case: home server voor software ontwikkeling, IOT databases (InfluxDB) en backup (van andere systemen) en archiving.

Ik verwacht Proxmox en Ubuntu te gebruiken incl. docker containers en een bescheiden aantal VMs (<5). De Zpool zal bestaan uit een RAIDz2 van 4 stuks 6TB SATA drives (het maximum wat het beoogde mobo aankan).

Mijn vragen gaan over de rest van de storage/drives waarvan ik aanneem dat die allemaal uit NVMe M.2 drives bestaan. Ik heb de afgelopen tijd heel veel over ZFS gelezen maar kom niet uit de praktische kant van het ontwerp. Het mobo dat ik op het oog heb heeft standaard 2 NVMe m.2 slots en ik kan er via een PCIe kaart nog makkelijk 2 bijplaatsen.

• hoe groot maak ik mijn boot drive en wat zet ik daar op? Maak ik een mirror voor de boot drive?
• waar plaats ik de VMs voor software ontwikkeling? Ik neem aan dat die op een SSD draaien i.v.m. performance.
• ik denk aan 64GB memory. Is dat voldoende voor de ARC en de rest van het systeem? Kan ik dit eerst aanzien en later kijken of ik uitbreid tot 128GB of een L2ARC drive toevoeg?

Als beginner (geen ZFS ervaring) ben ik waarschijnlijk nog een aantal essentiële vragen vergeten maar iedere hulp is welkom.

[P5ycho]

Ik doe bovenstaande op een FreeBSD bak met een dual core Pentium, 16GB ram en 5x 2.5" disks. Jails voor virtualisatie. Vanuit mijn perspectief is het zwaar overkill wat je nu gaat bouwen, maar meningen kunnen verschillen.

Als je een boot disk failure en bijbehorende downtime kunt lijden dan heb je redundantie niet nodig. Ik zou 2 SSDs pakken voor boot + VMs.

64GB is heel, heel veel voor een home server. 4-8GB voor ZFS, 2 voor je OS en de rest is voor andere zaken. Met 5 VMs moet je het erg gek maken om dat te vullen.

[cville]

P5ycho schreef op zondag 21 februari 2021 @ 11:24:
Ik doe bovenstaande op een FreeBSD bak met een dual core Pentium, 16GB ram en 5x 2.5" disks. Jails voor virtualisatie. Vanuit mijn perspectief is het zwaar overkill wat je nu gaat bouwen, maar meningen kunnen verschillen.

Als je een boot disk failure en bijbehorende downtime kunt lijden dan heb je redundantie niet nodig. Ik zou 2 SSDs pakken voor boot + VMs.

64GB is heel, heel veel voor een home server. 4-8GB voor ZFS, 2 voor je OS en de rest is voor andere zaken. Met 5 VMs moet je het erg gek maken om dat te vullen.

Overkill is zeker een zorg en een van de redenen om hier advies te vragen; bedankt daarvoor. Het is me nog niet duidelijk wat de beste inrichting van de boot SSDs is. Ik denk aan 2x1TB NVMe. Maak ik daar 1 partitie per SSD van of kan het beter?

[P5ycho]

Ik gebruik zfsonboot, dus elke van de 5 disks is bootable.
Ik zoucdan 2 partities maken denkik. 1 boot partitie, 1 vm pool en een pool op de hdds

[dcm360]

Onder de aanname dat je Proxmox op de hardware gaat installeren: in de installer kan je aangeven welke disks je wil gebruiken (en hoe, dus bijvoorbeeld in mirror) om van te booten, en hoe veel ruimte van die schijven gebruikt mag worden. De resterende ruimte op die disks en op alle andere disks is 'vrij' te gebruiken: je moet er zelf nog verder partities op aanmaken en/of een zpool op aanmaken.

Zelf zie ik overigens niet heel erg veel nut in van een losse zpool voor vm's op de SSD's naast de root-pool. VM's en containers plaats je toch al in een zvol, en losse partities krijg ik meestal spijt van omdat ik altijd wel een verkeerde inschatting voor de grootte maak.

[ Voor 25% gewijzigd door dcm360 op 21-02-2021 13:18 ]

[d3vlin]

ocaj schreef op woensdag 17 februari 2021 @ 20:14:
[...]


Als het een pure fileserver is dan is er niets dat je tegenhoudt om ZFS meer geheugen te laten gebruiken voor ARC. Geheugen is er immers om gebruikt te worden!

Hint: de tunable die je moet hebben is: zfs_arc_max

Thanks! Deze stond (standaard) op 0. "If set to 0 then the max size of ARC is determined by the amount of system memory installed. For Linux, 1/2 of system memory will be used as the limit." Aangepast naar geheugengrootte minus 4GB. Volgens arc_summary wordt er inmiddels dankbaar gebruik van gemaakt.

[ocaj]

@d3vlin Mooi zo!
Zie je nu ook performance verbetering t.o.v. de metingen die je 15 februari postte?

[d3vlin]

Ja, performance verbetering in de zin dat het nu niet helemaal onwerkbaar is om iets te deleten zonder dat er timeouts plaats vinden. Ik ben langzaam de storage pool weer aan het vullen met dedup en goed in de gaten aan het houden hoe het geheugengebruik en in het bijzonder de ARC daarbij vordert. Dat nu vrijwel het gehele ipv het halve geheugen gebruikt kan worden scheelt natuurlijk flink.

[ Voor 9% gewijzigd door d3vlin op 21-02-2021 23:16 ]

[cville]

@P5ycho en @dcm360 bedankt voor jullie adviezen zover. Ik ben me verder aan het inlezen over o.a. zfs on boot. Wordt vervolgd.

[P5ycho]

cville schreef op maandag 22 februari 2021 @ 17:29:
@P5ycho en @dcm360 bedankt voor jullie adviezen zover. Ik ben me verder aan het inlezen over o.a. zfs on boot. Wordt vervolgd.

Ik heb de verkeerde term gebruikt:
https://wiki.freebsd.org/RootOnZFS
Onder FreeBSD heel normaal, andere OS'en wat minder volgens mij.

[FireDrunk]

Q schreef op donderdag 18 februari 2021 @ 23:23:
Iemand al naar ZFS draid gekeken?

Ja, een poos geleden. Het lijkt een soort shared parity over meerdere vdev's heen. Ik vond het een vaag begrip, en het leek mij niet heel nuttig voor thuisgebruikers.

P5ycho schreef op maandag 22 februari 2021 @ 18:00:
[...]

Ik heb de verkeerde term gebruikt:
https://wiki.freebsd.org/RootOnZFS
Onder FreeBSD heel normaal, andere OS'en wat minder volgens mij.

Nou ja, normaal. De linux kernel wordt niet geshipped met ZFS ingebakken, daarom moet je wat kunst en vlieggrepen doen, maar als je de kernel module eenmaal hebt, is het niet zo lastig meer. GRUB ondersteund al tijden ZFS, en als je daarna zorgt voor een initramfs met ZFS er in, kan je root partities prima op ZFS liggen.

[P5ycho]

Klinkt als minder normaal

Draid is mooi voor serieuze brede striped raidz pools. Resilvering is een stuk vlotter, maar pas op met small block alocation want fixed stripe width.

[FireDrunk]

P5ycho schreef op maandag 22 februari 2021 @ 20:07:
Klinkt als minder normaal

Draid is mooi voor serieuze brede striped raidz pools. Resilvering is een stuk vlotter, maar pas op met small block alocation want fixed stripe width.

Ik snap nog niet zo goed hoe resilvering sneller kan zijn, er moet nog altijd 1 disk helemaal gevuld worden, en volgens mij is de snelheid van die disk altijd de bottleneck, en niet het 'resolven' van de informatie die naar die disk moet. Bij mijn laatste resilver haalde mijn pool gewoon de maximale schrijfsnelheid van 1 disk tijdens het resilveren (nou was dat een SMR schijf, dus heel hoog was het niet, maar wel de max ).

Ik zie nog weinig voordelen

[P5ycho]

FireDrunk schreef op dinsdag 23 februari 2021 @ 08:02:
[...]

Ik snap nog niet zo goed hoe resilvering sneller kan zijn, er moet nog altijd 1 disk helemaal gevuld worden, en volgens mij is de snelheid van die disk altijd de bottleneck, en niet het 'resolven' van de informatie die naar die disk moet.

De kunst is om de te resilveren drive te vullen met een continue sequentiele write actie, zonder daarmee de pool zelf te veel te belasten. Het aflopen van de complete tree om blocks te vinden en berekenen haalt de performance van je pool flink naar beneden. Als je dit doet met een 10 of 14 disk raidz array (of zelfs meerdere, striped), dan duurt een resilver misschien wel zo lang dat tegen de tijd dat je resilver klaar is, de volgende disk al de geest gegeven heeft. Zo zit je array ineens altijd in degraded state en is performance atijd ruk want resilvering. Hier helpt draid door eerst een sequential resilver te doen zoals klassieke raid5 dat ook zou doen, en daarna een additionele scrub die we al kennen.

Wat me alleen nog niet duidelijk is is hoeveel beter dit omgaat met SMR disks. In theorie zou dit een resilver op SMR moeten verbeteren. In combinatie met wat Special Allocation Class vdevs voor de small blocksize allocations zou dit interessant kunnen zijn.

Bron: https://klarasystems.com/articles/openzfs-draid-finally/