Het grote ZFS topic

[Snow_King]

RobertMe schreef op dinsdag 26 november 2024 @ 18:59:
Ik heb mijzelf verblijd met een nieuwe / grotere SSD voor in mijn router, die ook als download client dienst doet, met opslag op een additionele SSD (OS op NVME, downloads op SATA). Alleen ben ik even op zoek naar een second opinion v.w.b. migratie met de minste downtime. Systeem in kwestie is sowieso een TopTon doosje met maar 1 SATA poort, dus beiden via SATA aansluiten gaat hem niet worden. Echter heb ik wel een USB docking station.

Mijn idee nu is:

1. Nieuwe SSD aansluiten via het docking station;
2. Mirror opzetten (zpool attach, even gecheckt, want heb al eens de fout gemaakt met een add en er een stripe van gemaakt ), dit zal dan zijn op basis van het USB id en dus "fout"
3. Wachten tot de resilver klaar is
4. (software stoppen)
5. zpool export tank
6. Afsluiten, SSD wisselen, opstarten
7. zpool import tank (volgens mij gaat dit tegenwoordig automagisch op by-id basis?)
8. zpool detach ... de oude SSD
9. (software starten)

Evt kan ik ook de huidige (/oude) SSD al offlinen voordat ik de pool export. Ik weet niet of dat nog een groot verschil maakt? Maar volgens mij kun je ook eenvoudig een device er uit gooien op basis van het interne id dat ZFS laat zien (met bv een zpool status) als de disk helemaal foetsie is? Dus dat is dan om het even. Enige verschil is dan dat de oude SSD met een zpool detach waarschijnlijk weet dat hij "onbruikbaar" is (/uit de pool is) en met een zpool detach achteraf denkt die natuurlijk nog onderdeel van de pool te zijn?

Daarnaast zou ik natuurlijk ook de drives vooraf al kunnen wisselen. Dus beginnen met exporteren, de nieuwe SSD inbouwen en de oude in de dock, opstarten, importeren, en dan meteen toevoegen op basis van het juiste id. Maar ik denk niet dat dat veel verschil maakt? (behalve evt "planning" technisch. Ik kan nu de drive wisselen en daarna resilveren. Als ik nu eerst resilver is het later op de avond en ga ik wellicht niet meer wisselen ).

Als je wel meer downtime accepteert, waarom niet even met ‘dd’ een kopie maken van de bestaande disk?

[RobertMe]

Snow_King schreef op woensdag 27 november 2024 @ 09:08:
[...]
Als je wel meer downtime accepteert, waarom niet even met ‘dd’ een kopie maken van de bestaande disk?

Met dd een volledige disk kopiëren naar een nieuwe disk lijkt mij niet heel veilig bij ZFS? Aangezien je dan dus meerdere disks hebt met dezelfde identifiers voor pools en vdevs in de pool.

In ieder geval ging "downtime" me voornamelijk om "ik kan niet even de SSD uitbouwen, nieuwe en oude in mijn computer, met wel 2 SATA poorten plaatsen, dan mirroren, en dan de nieuwe terug plaatsen". Dan moest ik immers 2x de router open schroeven. Vandaar de "online" mirroring met de USB dock. Ik dacht alleen dat dat niet "goed" zou gaan met by-id met de switch van USB naar SATA (omdat gevoelsmatig er nog wel eens usb-... vs ata-... in de naam staat), vandaar de export => ombouwen => import "suggestie"/"vraag". Maar die work-a-round was dus niet nodig want de disk werd ondanks de USB dock toch herkent met een ata-... by-id. Waarbij vannacht de resilvering voltooid is en ik dus vanmorgen puur heb afgesloten, systeem geopend en SSD gewisseld, opstarten, en de pool kwam netjes online. Met in totaal nog geen 10 minuten downtime.

[Snow_King]

RobertMe schreef op woensdag 27 november 2024 @ 09:22:
[...]

Met dd een volledige disk kopiëren naar een nieuwe disk lijkt mij niet heel veilig bij ZFS? Aangezien je dan dus meerdere disks hebt met dezelfde identifiers voor pools en vdevs in de pool.

In ieder geval ging "downtime" me voornamelijk om "ik kan niet even de SSD uitbouwen, nieuwe en oude in mijn computer, met wel 2 SATA poorten plaatsen, dan mirroren, en dan de nieuwe terug plaatsen". Dan moest ik immers 2x de router open schroeven. Vandaar de "online" mirroring met de USB dock. Ik dacht alleen dat dat niet "goed" zou gaan met by-id met de switch van USB naar SATA (omdat gevoelsmatig er nog wel eens usb-... vs ata-... in de naam staat), vandaar de export => ombouwen => import "suggestie"/"vraag". Maar die work-a-round was dus niet nodig want de disk werd ondanks de USB dock toch herkent met een ata-... by-id. Waarbij vannacht de resilvering voltooid is en ik dus vanmorgen puur heb afgesloten, systeem geopend en SSD gewisseld, opstarten, en de pool kwam netjes online. Met in totaal nog geen 10 minuten downtime.

dd kan prima, de oude disk wipe je daarna. Zo hoef je geen resilver in ZFS te doen en is het 1 copy. Heb ik voor ZFS wel vaker gedaan, maar was vooral met oudere versies die bepaalde support toen niet had.

[menn0]

Zfs NAS en pool stonden uit.

- Jaar later gaat NAS aan, moederbord overleden.
- USB Boot device in takt

Nieuwe hardware (mobo & geheugen) (ook x86) is besteld.

Ik neem aan dat ik een
<code> zpool import -f "poolname" </code>

moet doen, ik weet overigens de poolname niet meer maar gaat dit los daar van wel werken?
Hoe achterhaal ik de poolname?

[FireDrunk]

menn0 schreef op maandag 16 december 2024 @ 18:35:
Zfs NAS en pool stonden uit.

- Jaar later gaat NAS aan, moederbord overleden.
- USB Boot device in takt

Nieuwe hardware (mobo & geheugen) (ook x86) is besteld.

Ik neem aan dat ik een
<code> zpool import -f "poolname" </code>

moet doen, ik weet overigens de poolname niet meer maar gaat dit los daar van wel werken?
Hoe achterhaal ik de poolname?

Als alle id's van de disks hetzelfde zijn als je cache file, importeert de pool gewoon automatisch. Als je het os gewoon intact laat, werkt alles gewoon.

[RobertMe]

menn0 schreef op maandag 16 december 2024 @ 18:35:
Zfs NAS en pool stonden uit.

- Jaar later gaat NAS aan, moederbord overleden.
- USB Boot device in takt

Nieuwe hardware (mobo & geheugen) (ook x86) is besteld.

Ik neem aan dat ik een
<code> zpool import -f "poolname" </code>

moet doen, ik weet overigens de poolname niet meer maar gaat dit los daar van wel werken?
Hoe achterhaal ik de poolname?

Als je alsnog handmatig moet importeren, kun je eerst zpool import doen. Dan krijg je gewoon een lijstje van wat die gevonden heeft. Daarna kun je dan altijd een zpool import <pool> proberen. Zou dan lijkt mij sowieso moeten werken als je nog van de originele USB / OS opstart. Immers heeft dat systeem dan dezelfde identifier als waarvan die het laatst geimporteerd was.

[Habana]

Zelfs mijn oude ZfsGuru pool (5-disk) werd na jaren ongebruikt zonder problemen herkent en geimporteerd in Truenas Scale, scrub erover en gaan, niet gek voor tien jaar oude WD- 2TB disk..

[Mystic Spirit]

Het is ruim 4 jaar geleden dat ik me gemeld heb in dit topic... Echter loop ik tegen een issue aan waar ik zoek naar een eenvoudige oplossing, maar die is er mogelijk niet. Daarom een check hoe jullie het zouden aanpakken in mijn geval.

Situatie:
Enige tijd geleden heb ik al mijn disks vervangen door grotere. Normaal gesproken expand de pool dan naar de nieuwe maximale grote. Dat is bij mij helaas niet gebeurd. Door een bug in Truenas Scale in die tijd is er 1 disk verkeerd gepartioneerd en mislukt het uitbreiden van de pool naar de juiste grote.

de output van is lsblk is:

code:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdb           8:16   0   9.1T  0 disk 
├─sdb1        8:17   0     2G  0 part 
└─sdb2        8:18   0   9.1T  0 part 
sdc           8:32   0   9.1T  0 disk 
├─sdc1        8:33   0   7.3T  0 part 
└─sdc2        8:34   0     2G  0 part 
sdd           8:48   0   9.1T  0 disk 
├─sdd1        8:49   0     2G  0 part 
└─sdd2        8:50   0   9.1T  0 part 
sde           8:64   0   9.1T  0 disk 
├─sde1        8:65   0     2G  0 part 
└─sde2        8:66   0   9.1T  0 part

Zoals jullie kunnen zien is bij disk sdc het partitioneren verkeerd gegaan. Naast dat de data partitie (sdc1) te klein is. Is ook de swap partitie (sdc2) achter de data partitie gezet. Hierdoor kan de data partitie niet vergroot worden, omdat de je geen overlappende partities kan hebben.

Wat zou nu een goede oplossing zijn?
Ik zou natuurlijk de disk offline kunnen halen, alle partities verwijderen en kunnen resilveren, maar dat gaat vrij lang duren.... Is er ook een mogelijkheid om dit op een veilige manier in de CLI op te lossen?

[GioStyle]

Je zou kunnen kijken of autoexpand aanstaat en of dat invloed heeft, maar volgens mij is je genoemde oplossing de enige juiste oplossing.

code:

zpool get autoexpand

Autoexpand aanzetten:

code:

zpool set autoexpand=on pool

[Mystic Spirit]

@GioStyle goede suggestie, maar voor deze specifieke pool staat de auto expand aan. Dus dat gaat helaas niet helpen.

Op verschillende fora lees ik wel dat het een mogelijkheid zou zijn om gewoon alle swap partities te verwijderen van de disks in de pool. In principe heb ik die swap ook niet nodig (zeker niet op de data pool). De meningen zijn echter verdeeld of dat verstandig is om te doen.
Iemand daar toevallig nog een inzicht over?

[ph0t0nix]

Wat zijn precies de partitiegrenzen (in sectors)? Staat de 2GB partitie direct achter de 7.3TB partitie, of helemaal aan het eind vand de schijf? In het eerste geval kun je proberen om (m.b.v. een live CD) de 2GB partitie te verplaatsen naar het eind van de schijf. Daarna kun je dan de 7.3TB partitie vergroten naar 9.1TB.

Ik heb geen ervaring met TrueNAS, maar ik heb op vergelijkbare wijze al een paar keer ZFS partities (onder Linux) vergroot. Na de autoexpansie zag de pool netjes de extra ruimte .

[Mystic Spirit]

@ph0t0nix Ja, zit er direct achter. Partitie 1 eindigd op xxxxxxx39 en partitie 2 start op xxxxxxx40.

TrueNAS Scale is op basis van Debian. Hoe zou je te werk gaan?
Ik ga remote te werk, dus een live CD wordt hem niet, maar ik kan best wat in de cli.
Kan je met parted makkelijk een partitie naar het einde van de disk verplaatsen?

[GorgeousMetal]

Software-update: OpenZFS 2.3.0

[jimmy87]

Weet iemand toevallig of openzfs 2.3.0 al ergens voor ubuntu 24 te vinden is?

[FireDrunk]

jimmy87 schreef op zaterdag 25 januari 2025 @ 02:25:
Weet iemand toevallig of openzfs 2.3.0 al ergens voor ubuntu 24 te vinden is?

Ik denk niet dat die er gaat komen. Ik verwacht dat die pas bij de volgende Ubuntu release geupgrade wordt in de (main) repo's.

[RobertMe]

FireDrunk schreef op zaterdag 25 januari 2025 @ 14:00:
[...]

Ik denk niet dat die er gaat komen. Ik verwacht dat die pas bij de volgende Ubuntu release geupgrade wordt in de repo's.

Er is natuurlijk best een kans op een 3th party PPA waar die in zit? Of je die moet vertrouwen is natuurlijk een ander verhaal, maar het kan wel.
En mogelijk dat iets uit een toekomstige release is binnen te halen? Bij Debian kun je immers ook packages uit testing (soms) installeren op stable. Maar ZFS 2.3 lijkt daar ook alleen in experimental te zitten, en ook nog niet in sid/unstable.

[vanaalten]

RobertMe schreef op zaterdag 25 januari 2025 @ 14:11:
[...]

Er is natuurlijk best een kans op een 3th party PPA waar die in zit? Of je die moet vertrouwen is natuurlijk een ander verhaal, maar het kan wel.
En mogelijk dat iets uit een toekomstige release is binnen te halen? Bij Debian kun je immers ook packages uit testing (soms) installeren op stable. Maar ZFS 2.3 lijkt daar ook alleen in experimental te zitten, en ook nog niet in sid/unstable.

Hmmm, de soft-freeze voor de volgende Debian release is 15 april ofzo. Dus heel misschien dat openzfs 2.3 voor die tijd nog door Sid en naar Trixie/testing gaat, dan zou die met de release in de tweede helft van 2025 in 'stable' kunnen zitten.

[FireDrunk]

RobertMe schreef op zaterdag 25 januari 2025 @ 14:11:
[...]

Er is natuurlijk best een kans op een 3th party PPA waar die in zit? Of je die moet vertrouwen is natuurlijk een ander verhaal, maar het kan wel.
En mogelijk dat iets uit een toekomstige release is binnen te halen? Bij Debian kun je immers ook packages uit testing (soms) installeren op stable. Maar ZFS 2.3 lijkt daar ook alleen in experimental te zitten, en ook nog niet in sid/unstable.

"belangrijke" releases gaan naar backports. Laten we hopen dat ZFS daar onder valt (mits hij niet het release window haalt uiteraard)

[ Voor 4% gewijzigd door FireDrunk op 25-01-2025 17:05 ]

[nero355]

vanaalten schreef op zaterdag 25 januari 2025 @ 15:13:
Hmmm, de soft-freeze voor de volgende Debian release is 15 april ofzo.
Dus heel misschien dat openzfs 2.3 voor die tijd nog door Sid en naar Trixie/testing gaat, dan zou die met de release in de tweede helft van 2025 in 'stable' kunnen zitten.

Dat moet toch te doen zijn : https://tracker.debian.org/pkg/zfs-linux

Ik liep namelijk tegen het bericht van 27-11-2024 aan dus ze zijn er flink mee bezig

FireDrunk schreef op zaterdag 25 januari 2025 @ 17:04:
"belangrijke" releases gaan naar backports. Laten we hopen dat ZFS daar onder valt (mits hij niet het release window haalt uiteraard)

Backports is toch iets wat je liever niet wilt gebruiken lees ik altijd

[FireDrunk]

nero355 schreef op zondag 26 januari 2025 @ 19:44:
[...]

Backports is toch iets wat je liever niet wilt gebruiken lees ik altijd

Mwoh, er zit iets meer risico aan, maar soms zitten er ook weer patches in voor applicaties die in de main tree niet gefixt worden omdat ze niet 'belangrijk genoeg' zijn.

Het wisselt.

[RobertMe]

Ik ben iets aan het prutsen met overlay/overlayfs, zodat ik een lokale map, zijnde een ZFS dataset, kan samenvoegen met een remote map, zijnde een NFS share/mount. Alleen..., lijkt er vrij weinig "overlayed" te worden. De "merged" map is dus gewoon een weergave van de NFS mount, zonder de items die alleen in de ZFS dataset staan. Dit test ik overigens met een "read only" overlay met alleen twee "lowerdir"s (dus geen upperdir & workdir).

Vervang ik de lokale (ZFS) map met een map in /tmp dan werkt het wel zoals ik verwacht. Gebruik ik de lokale (ZFS) map samen met de /tmp map dan werkt het niet, en zie ik weer alleen wat in de /tmp map zit. Het lijkt dus alsof de overlay de bestanden & mappen in de ZFS map niet ziet.

Komt iemand dit toevallig bekend voor? Hier en daar vind ik wel wat (oudere) issues met overlay support bij ZFS. Maar dat leek voornamelijk in de context van het gebruik als upperdir te zijn, en lowerdir "moe(s)t gewoon werken". En de openstaande issues zijn met 2.2 opgelost, en ik draai een 2.2 versie, dus ook die issues zouden er niet moeten zijn dan.

[nero355]

RobertMe schreef op dinsdag 28 januari 2025 @ 22:03:
Ik ben iets aan het prutsen met overlay/overlayfs, zodat ik een lokale map, zijnde een ZFS dataset, kan samenvoegen met een remote map, zijnde een NFS share/mount.

Komt iemand dit toevallig bekend voor?

Brainfart :

Maakt het wat uit als je de ZFS kant in de vorm van een NFS Share aanbiedt zodat beide kanten "gelijk" zijn "vanuit het blikveld" van dat overlayfs gebeuren


/Totaal geen ervaring mee, maar klinkt allemaal wel interessant en zo...

[RobertMe]

nero355 schreef op woensdag 29 januari 2025 @ 00:21:
Maakt het wat uit als je de ZFS kant in de vorm van een NFS Share aanbiedt zodat beide kanten "gelijk" zijn "vanuit het blikveld" van dat overlayfs gebeuren

Hmm, interessant idee. Maar gezien hoeveel moeite het me kostte om NFS 4, onder Debian, aan de praat te op het andere systeem laat ik dit even aan me voorbij gaan.

offtopic:
Debian levert de packages op zo'n manier dat je altijd met NFS 3 + 4 zit. De wiki geeft daarbij wel aan dat je voor 4 only rpcbind.service & rpcbind.socket kunt masken zodat deze "niks doen". Maar de nfs-server.service heeft nog meerdere dependencies op een aantal rpc* services die vervolgens errors geven als rpcbind niet draait. Dus uiteindelijk heb ik een stuk of 5 tot 10 units moeten masken, + de server config moeten aanpassen om geen v3 te doen, voordat de boel werkte zonder errors.

[RobertMe]

RobertMe schreef op dinsdag 28 januari 2025 @ 22:03:
Ik ben iets aan het prutsen met overlay/overlayfs, zodat ik een lokale map, zijnde een ZFS dataset, kan samenvoegen met een remote map, zijnde een NFS share/mount. Alleen..., lijkt er vrij weinig "overlayed" te worden. De "merged" map is dus gewoon een weergave van de NFS mount, zonder de items die alleen in de ZFS dataset staan. Dit test ik overigens met een "read only" overlay met alleen twee "lowerdir"s (dus geen upperdir & workdir).

Vervang ik de lokale (ZFS) map met een map in /tmp dan werkt het wel zoals ik verwacht. Gebruik ik de lokale (ZFS) map samen met de /tmp map dan werkt het niet, en zie ik weer alleen wat in de /tmp map zit. Het lijkt dus alsof de overlay de bestanden & mappen in de ZFS map niet ziet.

Komt iemand dit toevallig bekend voor? Hier en daar vind ik wel wat (oudere) issues met overlay support bij ZFS. Maar dat leek voornamelijk in de context van het gebruik als upperdir te zijn, en lowerdir "moe(s)t gewoon werken". En de openstaande issues zijn met 2.2 opgelost, en ik draai een 2.2 versie, dus ook die issues zouden er niet moeten zijn dan.

Opgelost Worked around. Het heeft waarschijnlijk te maken met dat de opgegeven ("ZFS") lowerdir map ook een dataset root is. Deze map bevat vervolgens maar 2 mappen (waarin weer een onbepaald aantal (sub)mappen zitten op beide lowerdirs). Als ik vervolgens 2x een overlay mount doe op die 2 mappen dan werkt het wel, maar exact hetzelfde op dus hun parent map (dat het mountpoint van de dataset is) werkt het niet. Verder niet gekeken of het mogelijk een algemener probleem is met dat je geen enkel mount point (onafhankelijk van filesystem type) kunt gebruiken in een overlay, maar lijkt mij sterk dat dat niet werkt.

Overigens moest het wel werken. Aangezien Docker relatief "recent" ook ZFS met overlay (/ Docker "overlayfs2") driver is gaan ondersteunen (daarvoor was er een speciale zfs driver die de layers deed opslaan op basis van ZFS tech, zoals clones etc). En een check van de mounts op het systeem ook aangaf dat er een sh*tload aan overlay mounts waren in /var/lib/docker/.... en /var/lib/docker zelf een ZFS dataset (root) is. Dat gaf mij dus de "misschien werkt het wel met submappen?" ingeving, die bleek te kloppen.

Edit / aanvulling:
Braintfart binnen 5 minuten na posten. Natuurlijk is het geen algemeen probleem met "lowerdir is een mountpoint". Want de NFS share die ik als "tweede" lowerdir gebruik is ook het mountpoint, en die werkte dus prima.
Mogelijk dus dat Linux / de overlay driver kijkt naar de map waar de dataset gemount is i.p.v. daadwerkelijk waar de mount uit komt? Zou ik dus kunnen testen door de dataset te unmounten, dan een bestand in de lege map te zetten, dan de dataset weer mounten, en dan het overlay "aanmaken". Als dan dat bestand zichtbaar is in de overlay blijkt dat het overlay "verkeerd kijkt" in de map waarop gemount is en niet in de mount zelf.

[ Voor 11% gewijzigd door RobertMe op 29-01-2025 18:47 ]

[orvintax]

RobertMe schreef op woensdag 29 januari 2025 @ 09:24:
[...]

Hmm, interessant idee. Maar gezien hoeveel moeite het me kostte om NFS 4, onder Debian, aan de praat te op het andere systeem laat ik dit even aan me voorbij gaan.

offtopic:
Debian levert de packages op zo'n manier dat je altijd met NFS 3 + 4 zit. De wiki geeft daarbij wel aan dat je voor 4 only rpcbind.service & rpcbind.socket kunt masken zodat deze "niks doen". Maar de nfs-server.service heeft nog meerdere dependencies op een aantal rpc* services die vervolgens errors geven als rpcbind niet draait. Dus uiteindelijk heb ik een stuk of 5 tot 10 units moeten masken, + de server config moeten aanpassen om geen v3 te doen, voordat de boel werkte zonder errors.

Je wilt dus NFS client side op 4 forceren? Waarom doe je dit niet via de server?

[RobertMe]

orvintax schreef op donderdag 30 januari 2025 @ 15:48:
[...]

Je wilt dus NFS client side op 4 forceren? Waarom doe je dit niet via de server?

Ik wil het forceren op de server. Maar als je op Debian nfs-kernel-server installeert krijg je de klassieke (NFS 2 / 3 vereiste) rpc stuff erbij (requirement, ook geen recommended, echt required). En niet alleen dat, de nfs-server systemd service heeft ook allemaal dependencies op de rpc services. Dus ja, je kunt de server configureren om alleen NFS 4 te doen. Maar dan probeert die nog steeds allemaal services "voor NFS 3" (rpc gebeuren dus) te starten, die vervolgens ook error logging oplevert (in ieder geval als je Debians eigen stappen volgt en rpcbind.{service,socket} doet masken, omdat die specifiek dan niet start, maar verschillende anderen die rpcbind nodig hebben wel nog gestart worden, en dus niet werken. Zou je rpcbind niet masken krijg je waarschijnlijk geen errors, maar heb je wel onzinnig een stuk of 5 tot 10 services draaien die alleen nodig zijn voor NFS 3, die ik dus niet wil gebruiken).

[orvintax]

RobertMe schreef op donderdag 30 januari 2025 @ 15:53:
[...]

Ik wil het forceren op de server. Maar als je op Debian nfs-kernel-server installeert krijg je de klassieke (NFS 2 / 3 vereiste) rpc stuff erbij (requirement, ook geen recommended, echt required). En niet alleen dat, de nfs-server systemd service heeft ook allemaal dependencies op de rpc services. Dus ja, je kunt de server configureren om alleen NFS 4 te doen. Maar dan probeert die nog steeds allemaal services "voor NFS 3" (rpc gebeuren dus) te starten, die vervolgens ook error logging oplevert (in ieder geval als je Debians eigen stappen volgt en rpcbind.{service,socket} doet masken, omdat die specifiek dan niet start, maar verschillende anderen die rpcbind nodig hebben wel nog gestart worden, en dus niet werken. Zou je rpcbind niet masken krijg je waarschijnlijk geen errors, maar heb je wel onzinnig een stuk of 5 tot 10 services draaien die alleen nodig zijn voor NFS 3, die ik dus niet wil gebruiken).

Aah oke, duidelijk. Ik snap dat het stom is, maar misschien moet je je afvragen of die paar services laten draaien niet verwaarloosbaar is

[nero355]

RobertMe schreef op woensdag 29 januari 2025 @ 09:24:
Hmm, interessant idee. Maar gezien hoeveel moeite het me kostte om NFS 4, onder Debian, aan de praat te op het andere systeem laat ik dit even aan me voorbij gaan.

Ik bedoelde die NFS optie via ZFS zelf net als het ook een optie heeft voor Samba Shares i.p.v. dat je zelf Samba configureert

RobertMe schreef op woensdag 29 januari 2025 @ 18:42:
Opgelost Worked around. Het heeft waarschijnlijk te maken met dat de opgegeven ("ZFS") lowerdir map ook een dataset root is. Deze map bevat vervolgens maar 2 mappen (waarin weer een onbepaald aantal (sub)mappen zitten op beide lowerdirs). Als ik vervolgens 2x een overlay mount doe op die 2 mappen dan werkt het wel, maar exact hetzelfde op dus hun parent map (dat het mountpoint van de dataset is) werkt het niet. Verder niet gekeken of het mogelijk een algemener probleem is met dat je geen enkel mount point (onafhankelijk van filesystem type) kunt gebruiken in een overlay, maar lijkt mij sterk dat dat niet werkt.

Een beetje hetzelfde gezeik als je vanuit Windows een hele HDD wilt Sharen en dus de root shared :
Mag niet!!! Veel te gevaarlijk!!! De wereld vergaat als je dat doet !!!

Vervolgens zet je wat rechten goed en geen haan die erom kraait...

Echt irritant dat soort dingen

RobertMe schreef op donderdag 30 januari 2025 @ 15:53:
Ik wil het forceren op de server. Maar als je op Debian nfs-kernel-server installeert krijg je de klassieke (NFS 2 / 3 vereiste) rpc stuff erbij (requirement, ook geen recommended, echt required). En niet alleen dat, de nfs-server systemd service heeft ook allemaal dependencies op de rpc services. Dus ja, je kunt de server configureren om alleen NFS 4 te doen. Maar dan probeert die nog steeds allemaal services "voor NFS 3" (rpc gebeuren dus) te starten, die vervolgens ook error logging oplevert (in ieder geval als je Debians eigen stappen volgt en rpcbind.{service,socket} doet masken, omdat die specifiek dan niet start, maar verschillende anderen die rpcbind nodig hebben wel nog gestart worden, en dus niet werken. Zou je rpcbind niet masken krijg je waarschijnlijk geen errors, maar heb je wel onzinnig een stuk of 5 tot 10 services draaien die alleen nodig zijn voor NFS 3, die ik dus niet wil gebruiken).

Heel fijn als de documentatie A zegt en jij vervolgens B of zelfs nog meer moet doen om het werkend te krijgen inderdaad...

[RobertMe]

Heeft hier wel eens iemand ZFS on root op een ARM (/Ampere) based VPS gekregen?

Mijn route tot nu toe was altijd het volgen van de instructies in de ZFS docs v.w.b. "on root" (specifiek Debian). Maar dat gaat uit van "boot live CD", dat ik deed via netboot.xyz. Alleen lijkt er uberhaupt geen ARM based live CD te zijn. Dus dat is dan wel lastig. In dit Reddit draadje wordt gebruik gemaakt van het gewone Debian image, alleen dan rescue mode? En neuzende door de netboot.xyz opties kwam ik een "live-arm.ipxe" tegen met een "Grml" optie, dat een Debian based live systeem blijkt te zijn (en waar Debians debootstrap ook in zit).

Iemand hier dus toevallig ervaring met een dergelijke opzet?

[nero355]

RobertMe schreef op vrijdag 7 februari 2025 @ 22:21:
Heeft hier wel eens iemand ZFS on root op een ARM (/Ampere) based VPS gekregen?

Iemand hier dus toevallig ervaring met een dergelijke opzet?

Zit hier niks tussen : https://www.armbian.com/download/

Verder misschien een gek idee, maar er is een ARM versie van OPNsense specifiek voor VPS gebruik : https://forum.opnsense.or...35828.msg174494#msg174494
Zelfs op Ampere gericht !!

En het doet ZFS dus... Why not ?!

[RobertMe]

nero355 schreef op zaterdag 8 februari 2025 @ 00:13:
[...]

Zit hier niks tussen : https://www.armbian.com/download/

Nee. Daar schiet ik niks mee op. Dat zijn allemaal images die je op USB / SD noet zetten en dat proces is "de installatie". Terwijl ik dus op zoek ben naar een live (CD) van waaruit ik Debian kan installeren. Ik heb dus een installer (like) ISO nodig. Geen root filesystem dat al geïnstalleerd is.
Nog los van dat al die images dus voor specifieke hardware zijn, zoals "altijd" bij ARM. Je hebt een specifiek image nodig waarin alle stuff zit ingebakken voor die hardware (de juiste "devicetree").
En, afgaande op Wikipedia, is er pas sinds enkele jaren (ergens na 2020) een certificatie proces waarbij hardware óf het devicetree verhaal moet ondersteunen, óf (een subset van) UEFI moet ondersteunen. En die Ampere CPUs vallen dus onder het laatste. Die doen "gewoon" UEFI. En mogelijk zijn ze daarin ook de enige semi gangbare? Terwijl allemaal die SBCs gebruik maken van een devicetree.

Verder misschien een gek idee, maar er is een ARM versie van OPNsense specifiek voor VPS gebruik : https://forum.opnsense.or...35828.msg174494#msg174494
Zelfs op Ampere gericht !!

En het doet ZFS dus... Why not ?!

En dan? Ik wil ook iets doen met die VPS. En dat is niet er een firewall van maken.

---

Wat wel mogelijk ook nog kan... Is door de grotere HDD gewoon een OS er op laten zetten ("bij levering", bv Debian dan), vervolgens de root partitie verkleinen, achteraan een nieuwe partitie maken en daar (bv) Debian op installeren, dan rebooten naar Debian "achteraan op de HDD". Dan vanaf die installatie het begin van de HDD formateMaaretc met ZFS en daar Debian weer installeren, rebooten naar de installatie op ZFS, partitie achteraan verwijderen, andere partitie resizen, ZFS pool expanden, en tada. Ook dan is de volledige HDD met ZFS gevuld.
Maat makkelijker is dus gewoon een live CD starten en in een keer de hele HDD kunnen formatteren.

[dcm360]

OpenSuse Tumbleweed heeft geschikte live-cd's voor UEFI ARM. Of dat met 'het is op zijn minst ook Linux' ook geschikt genoeg is om een Debian-installatie met root-on-ZFS te maken kan dan nog wel een interessante puzzel zijn.

[RobertMe]

dcm360 schreef op zaterdag 8 februari 2025 @ 09:57:
OpenSuse Tumbleweed heeft geschikte live-cd's voor UEFI ARM. Of dat met 'het is op zijn minst ook Linux' ook geschikt genoeg is om een Debian-installatie met root-on-ZFS te maken kan dan nog wel een interessante puzzel zijn.

debootstrap lijkt er wel in te zitten: https://software.opensuse.org/package/debootstrap
En ZFS lijkt ook beschikbaar te zijn: https://software.opensuse.org/package/zfs

Zou dan wel voor het eerst in uhm, 1,5 decennium zijn dat ik weer eens iets met OpenSuse ga doen. Was mijn eerste distro. Daarna op Arch overgestapt en "Once you'll go Arch you'll never go back"

[nero355]

RobertMe schreef op zaterdag 8 februari 2025 @ 09:00:
Nee. Daar schiet ik niks mee op. Dat zijn allemaal images die je op USB / SD noet zetten en dat proces is "de installatie".

Nog los van dat al die images dus voor specifieke hardware zijn, zoals "altijd" bij ARM.
Je hebt een specifiek image nodig waarin alle stuff zit ingebakken voor die hardware (de juiste "devicetree").

Er zit een "generic" variant bij dus dacht misschien kan je daar wat mee...

En dan? Ik wil ook iets doen met die VPS. En dat is niet er een firewall van maken.

Je moet effe verder lezen :
- Onderhuids is het gewoon FreeBSD en kan je doen wat je wilt.
- De port is als volgt gemaakt :
1. FreeBSD 13.x/14.x geport naar Ampere aarch64
2. Daar de OPNsense patches overheen toegepast.

Dus als je gewoon die vent contact en vraagt naar de basis van Stap #1 dan heb je een werkend OS met OpenZFS ondersteuning voor Ampere aarch64 VPSjes

Denk ik...

RobertMe schreef op zaterdag 8 februari 2025 @ 10:58:
Daarna op Arch overgestapt en "Once you'll go Arch you'll never go back"

Dat is dan "Once you go Arch you never go barch!"

[RobertMe]

RobertMe schreef op vrijdag 7 februari 2025 @ 22:21:
Heeft hier wel eens iemand ZFS on root op een ARM (/Ampere) based VPS gekregen?

Hierop terugkomende...
Ben er nog niet aan begonnen / nog geen besluit genomen of het een ARM based VPS wordt. Maar wat ik mij wel nog bedacht is dat ik eerder in dit topic uitgebreid heb geschreven over mijn avonturen met ZFS native encryption op mijn Intel N5105 systeem. Waarbij geen hardware acceleration v.w.b. aes-gcm gebruikt wordt door het gebrek van de AVX instructieset. Dus toch eens even gezocht hoe het met native encryption op ARM zit. En daar is schijnbaar de enige werkende implementatie de compleet generic variant. Dus 0,0 "acceleratie" en daardoor veel trager dan, bv, geen encryptie. Sinds 2021 ligt er wel al een feature request voor, maar een WIP implementatie is er pas sinds oktober vorig jaar en buiten wat initiële comments is het daar ook stil.

Nu gebruik ik op de VPS geen encryptie (ook semi zinloos I guess. Key komt dan sowieso lokaal te staan + zal altijd gemount zijn en dus ingeladen key*), maar wel iets om bij stil te staan dus.

* Thuis heb ik de keys encrypted op mijn router staan en wordt door servertje daar af gehaald. Bij diefstal moeten dus bij wijze van beide systemen worden meegenomen. En er worden raw send & receives op gedaan waarmee de boel ook, encrypted en al, remote aan komt. Bij de VPS is dat minder aan de orde.

[silverball]

Ik mis tegenwoordig goedkope opties om een beetje energiezuinige ECC setup in huis te halen. Ik heb in 2018 een Supermicro A2SDi-4C-HLN4F gekocht voor 300,- . Heeft eigenlijk alles wat ik zocht. ECC, IPMI, veel sata/sas en cpu met een lekker laag idle verbruik.

Als je zoiets vandaag de dag gaat zoeken kom je op N5105 bordjes o.i.d die alle bovenstaande zaken niet hebben. Ja, op papier moet het energieverbruik nog wat beter zijn, maar verder concurreert het niet. De huidige Intel Atom "Parker Ridge" generatie heeft veel minder lanes.

Waar draaien jullie ZFS op, gewoon zonder ECC naar alle tevredenheid of op een luxer platform?

[RobertMe]

silverball schreef op maandag 14 april 2025 @ 10:51:
Waar draaien jullie ZFS op, gewoon zonder ECC naar alle tevredenheid of op een luxer platform?

Qua NAS /daadwerkelijk opslag systeem een Fujitsu bord met een Intel i3-9100. Waarbij ECC support ook aanwezig is en ik ECC RAM er in heb gedaan.

Daarnaast draai ik ZFS ook op 2 N5105 systemen, maar dat is dan zonder ECC. Opslag van documenten etc gaat daarbij "24/7" naar het N5105 servertje (ander is mijn router dus doet in principe geen opslag). Maar als de NAS aan staat gaan documenten ook daar heen. Dit middels Syncthing op de PCs die zowel met servertje als NAS verbinden (en servetje en NAS onderling). Als er al ergens een RAM fout is in het servertje verwacht ik dat Syncthing daar uiteindelijk een error op geeft door conflicterende wijzigingen over de opslag locaties.

[pimlie]

@silverball Luxer platform obv een W680 moederbord. Ik heb geupgrade ivm hoog stroomverbruik van vorig systeem, waarom wil jij upgraden?

[silverball]

pimlie schreef op maandag 14 april 2025 @ 13:23:
@silverball Luxer platform obv een W680 moederbord. Ik heb geupgrade ivm hoog stroomverbruik van vorig systeem, waarom wil jij upgraden?

Omdat die nas bij mijn uitzet destijds is achtergebleven bij moederlief.
Ik haal sinds ze op T-Mobile, Odido niet echt lekkere throughput meer naar haar woning, maar ze gebruiken daar de nas gewoon dus ik ga hem ook niet wegkapen.

Dus echt een upgrade is het niet; ik heb die nas simpelweg niet meer.

[ Voor 7% gewijzigd door silverball op 14-04-2025 13:39 ]

[pimlie]

Hoe belangrijk is laag stroomverbruik? Je zou waarschijnlijk nog wel een goedkoper AMD systeem kunnen krijgen met ECC support. Ik heb de W680 aanschafsprijs voor mezelf goed gepraat door het te vergelijken met een kant en klaar qnap/synology systeem. Het is misschien luxer maar nog altijd goedkoper dan zo'n kant en klaar iets.

Als je van knutselen houdt, via ebay kan je voor EUR <100 een Dell Precision 3660 moederbord krijgen met W680 chipset. Vond dat zelf teveel gedoe/risico door waarschijnlijk rare Dell stekkers, geen standaard ATX formaat etc

[silverball]

@pimlie Best wel, ik zou het graag onder de € 100,- per jaar aan stroomverbruik willen houden dus dan zit je aan de 30w idle vanuitgaande € 0,33 ct / kWh. Het is natuurlijk ook wel een vrij dure liefhebberij, want eigenlijk moet er ook nog een offsite back-up bij, bij hetzner o.i.d.

Op mijn huidige 'workstation', tussen aanhalingstekens, doe ik met een AMD Ryzen 7 3700X 40w idle met 1 nvme ssd. Dat vind ik al wat stevig, weet jij hoeveel idle draw je hebt met je W680 ?

Toegegeven, dat is zonder optimalisatie van C-states en powertop of wat dan ook.

Laat ik het zo zeggen, ik wilde het eerst posten in het Het grote zuinige server topic, maar daar moest ik in het verleden ophouden over raid dus zo ver optimaliseren tot op de laatste Wh gaat mij weer wat ver. Ik zou graag zo min mogelijk idle verbruik hebben maar wel gewoon redelijk veilig/volledig een ZFS mirror pool willen draaien.

[ Voor 29% gewijzigd door silverball op 14-04-2025 14:27 ]

[d3vlin]

Dell PowerEdge T130/T330 tower servertjes met Xeon E3-12XXv5/6 zijn voor 75-125 euro gebruikt te koop incl bijbehorende PERC H330/H730 (hebben HBA mode). Tot 64GB ECC, iDRAC en met de T330 8x 3,5'" SAS/SATA hotswappable. Met 1 of 2x SST-ECM20 kun je SATA M.2 en NVME toevoegen voor OS en eventueel een special vdev. Noctua koeling er in en je hebt een stille ZFS server voor heel weinig. Met 8 harddisks en 2x495W redundant PSU ongeveer 70W idle.

https://linustechtips.com...-buyers-guidebuild-guide/

[pimlie]

@silverball Ik doe met een Asrock mobo ~32W idle, maar als je in Het grote zuinige server topic - deel 3 topic zoekt dan zijn er ook mensen met de Asus W680 en die halen <20W idle

Zelf wacht ik momenteel op de Kontron K3836-R, hoop dat die net zo zuinig gaat zijn als veel van zijn voorgangers. Alhoewel die eigenlijk net te weinig i/o heeft

[d3vlin]

FireDrunk schreef op zaterdag 17 augustus 2024 @ 07:11:
[...]

Een Read kan een SSD niet vullen. Jij bedoelt denk ik: als ik van mijn pool lees, wordt de l2arc gevuld. Dat klopt, maar dat zijn voor de ssd writes.

En over arc - > l2arc heb je ook gelijk.
Maar alle data gaat door arc heen. En alle data valt dus uit arc naar l2arc.

Mijn ervaring is vrij simpel, ik had 2 l2arc ssds in stripe toegevoegd. Bij flinke downloadsessie stonden die ssds zich het rambam te schrijven voor 0 performancewinst.
Uitendelijk heb ik voor alle 'sequentiele' filesystems toen l2 metadata caching uitgezet.
Toen werden ze amper gebruikt.
Maar hadden ze dus ook geen nut.

Ik heb nooit de optie gevonden om specifieke data in l2arc te krijgen.

Volgens mij is tegenwoordig (naast voldoende ram / arc) een special vdev op nvme in veel gevallen een betere oplossing dan een aparte l2arc of zil om een zpool snel te krijgen. Metadata en idealiter ook kleine bestanden (met special_small_blocks) vanaf nvme, de bulk vanaf spinning rust.

[FireDrunk]

Klopt. LTT had recent zelfs een flinke ZFS pool op flinke NVMe (of SAS) drives waar ze zelfs heel ARC uit zette. Het was sneller om de data direct via DMA in het geheugen van je applicatie te zetten dan de dubbele geheugen kopieslag te hebben van Disk -> ARC -> App.

Moderne hardware is zo idioot snel, ZFS kan daar soms gewoon niet mee overweg helaas

Gevonden: YouTube: This is stupid, but I love it - Linus Home NAS Update 2021 iets ouder dan ik dacht.

[ Voor 17% gewijzigd door FireDrunk op 14-04-2025 16:19 ]

[silverball]

Er is ook verder geen echt alternatief voor ZFS me dunkt. Btrfs heeft nog steeds raidz issues, "write hole", aan de MS Windows kant is ReFS nog steeds niet af, wat is er verder? RHEL heeft Stratis met daaronder allerlei 'legacy' tools als LVM, LUKS, XFS maar mist daarbij wel echte CoW functionaliteit.

Als je de schaalsprong wilt maken zijn er natuurlijk zaken als Ceph, maar dat is niet helemaal hetzelfde.

[ Voor 6% gewijzigd door silverball op 14-04-2025 16:24 ]

[RobertMe]

silverball schreef op maandag 14 april 2025 @ 16:22:
Er is ook verder geen echt alternatief voor ZFS me dunkt. Btrfs heeft nog steeds raidz issues, "write hole", aan de MS Windows kant is ReFS nog steeds niet af, wat is er verder? RHEL heeft Stratis met daaronder allerlei 'legacy' tools als LVM, LUKS, XFS maar mist daarbij wel echte CoW functionaliteit.

Als je de schaalsprong wilt maken zijn er natuurlijk zaken als Ceph, maar dat is niet helemaal hetzelfde.

Bcachefs heb je nog. Maar volgens mij is dat nog redelijk experimenteel.

[silverball]

RobertMe schreef op maandag 14 april 2025 @ 16:39:
[...]

Bcachefs heb je nog. Maar volgens mij is dat nog redelijk experimenteel.

Een van de laatste posts van Kent Overstreet begint met "TLDR: the future of bcachefs in the kernel is uncertain, and lots of things aren't looking good", en zover ik weet is de 'ruzie' in de LKML nog niet helemaal opgelost. Ik zou dat nog niet in productie inzetten aangezien Kent tevens ook nog steeds een eenpitter is.

[pimlie]

silverball schreef op maandag 14 april 2025 @ 16:22:
Er is ook verder geen echt alternatief voor ZFS me dunkt.

Mergerfs in combinatie met snapraid? Vooral @Mars Warrior is daar volgens mij een advocaat van

Grootste nadeel: FUSE
Grootste voordeel: In essentie een laag bovenop een JBOD, dus je kan alle disks die je hebt liggen gebruiken om een vdev te maken (ipv dat zelfde grootte benodigd is)

[Uberprutser]

Ik draai op een machine met ZFS 2.2.7 een RAIDZ1 en 1 van de schijven is ermee opgehouden.
Normaal is het dan schijf eruit, nieuwe erin en klaar. Helaas staat deze doos 1000+ KM verderop en is het niet zo makkelijk te doen en kom er pas in de zomer weer in de buurt.

Ik kom een aardig eind met ZFS maar is het in een bestaande pool mogelijk om een schijf eruit te knikkeren en dat de RAIDZ1 opnieuw wordt opgebouwd zonder dat de data verloren gaat? Ofwel 1 disk uit de pool halen en dat de 7 die over blijven de nieuwe pool worden (dus dat er weer 1 zou kunnen uitvallen zonder impact)?

[Mars Warrior]

pimlie schreef op woensdag 23 april 2025 @ 11:01:
[...]
Mergerfs in combinatie met snapraid? Vooral @Mars Warrior is daar volgens mij een advocaat van

Grootste nadeel: FUSE
Grootste voordeel: In essentie een laag bovenop een JBOD, dus je kan alle disks die je hebt liggen gebruiken om een vdev te maken (ipv dat zelfde grootte benodigd is)

Nou ja, advocaat. Het bevalt mij wel goed, dat klopt

Nu heb ik op mijn zuinige server (3W idle zonder disken met een 13900K CPU en 128GB RAM) voornamelijk (op disk) statische data waar per dag ca 5-10GB aan data wijzigt. Zelfs als ik elk uur een Snapraid Sync doe, dan is deze in een paar seconden klaar, dus voor mijn use case (JBOD's en zuinig) perfect.

Alle andere data staat op een SSD. Dat is voornamelijk data gegenereerd/beheerd door een 40-tal docker containers. Daar is het regelmatig fijn als ik gewoon met 3GB/sec data kan lezen/schrijven.

Ooit - in 2023 - wel overwogen om deze real-time data op ZFS te zetten, maar nooit gedaan. Één van de redenen was dat alle data in de databases gevuld worden met externe data die op Azure staat.
Dus mocht de database kapot gaan, dan is dat altijd weer te herstellen, al dan niet met een off-site backup van de vorige dag Als ik dat niet had gehad, dan zou ZFS met snapshots wel een mooie aanvulling zijn!
Verder hoef je - vanzelfsprekend - docker containers zelf nooit te backuppen en staan configuraties op Github.

Overigens kan er nog een tweede SSD in en wordt de server steeds meer en zwaarder gebruikt. Dus ZFS staat nog wel steeds als optie als mogelijke wijziging

Voor de echte storage behoeftes wordt gebruik gemaakt van Erasure Coding overigens. Daar is ZFS gewoon niet voor geschikt. Ik zie me al wachten totdat ZFS 100TB heeft lopen resilveren Met EC is een schijf vervangen vaak minuten werk, terwijl de performance nauwelijks afneemt. Goedkoop is het niet, maar het zijn mijn euro's niet gelukkig

[dylan111111]

Uberprutser schreef op woensdag 23 april 2025 @ 11:37:
Ik draai op een machine met ZFS 2.2.7 een RAIDZ1 en 1 van de schijven is ermee opgehouden.
Normaal is het dan schijf eruit, nieuwe erin en klaar. Helaas staat deze doos 1000+ KM verderop en is het niet zo makkelijk te doen en kom er pas in de zomer weer in de buurt.

Ik kom een aardig eind met ZFS maar is het in een bestaande pool mogelijk om een schijf eruit te knikkeren en dat de RAIDZ1 opnieuw wordt opgebouwd zonder dat de data verloren gaat? Ofwel 1 disk uit de pool halen en dat de 7 die over blijven de nieuwe pool worden (dus dat er weer 1 zou kunnen uitvallen zonder impact)?

Na mijn weten kan je helaas geen disks uit een RAIDZ1 pool halen, uit de ZFS documentatie zie ik ook geen opties terug hiervoor. (Verbeter mij gerust als ik het mis heb!)

Heb je nog ongebruikte disks in die machine zitten die groot genoeg is voor alle data? of een externe opslag locatie?
Dan kun je een snapshot nemen, met zfs send alles naar een tijdelijke pool/locatie kopiëren, de oorspronkelijke pool opnieuw opbouwen met 7 disks in RAIDZ1 en daarna de data weer terugzetten met zfs receive.

[pimlie]

@Mars Warrior ZFS wordt blijkbaar wel als basis voor Lustre en/of BeeGFS gebruikt om out te scalen: https://zfsonlinux.topicb...d88fc1c/scale-out-openzfs

@Uberprutser vdev's kunnen niet shrinken zoals @dylan111111 aangeeft. Kan je niet iemand vragen er een nieuwe hdd in te hangen? Gewoon video bellen met dat persoon en ze stap voor stap begeleiden, elke plug kan er maar op 1 manier in dus je hebt alleen iemand nodig die kan luisteren en je instructies op volgt

Een 8 disk vdev met raidz1 op 1000km afstand is overigens een gewaagde keuze...

[HyperBart]

Mars Warrior schreef op woensdag 23 april 2025 @ 13:29:
[...]

Nou ja, advocaat. Het bevalt mij wel goed, dat klopt

Nu heb ik op mijn zuinige server (3W idle zonder disken met een 13900K CPU en 128GB RAM) voornamelijk (op disk) statische data waar per dag ca 5-10GB aan data wijzigt. Zelfs als ik elk uur een Snapraid Sync doe, dan is deze in een paar seconden klaar, dus voor mijn use case (JBOD's en zuinig) perfect.

Alle andere data staat op een SSD. Dat is voornamelijk data gegenereerd/beheerd door een 40-tal docker containers. Daar is het regelmatig fijn als ik gewoon met 3GB/sec data kan lezen/schrijven.

Ooit - in 2023 - wel overwogen om deze real-time data op ZFS te zetten, maar nooit gedaan. Één van de redenen was dat alle data in de databases gevuld worden met externe data die op Azure staat.
Dus mocht de database kapot gaan, dan is dat altijd weer te herstellen, al dan niet met een off-site backup van de vorige dag Als ik dat niet had gehad, dan zou ZFS met snapshots wel een mooie aanvulling zijn!
Verder hoef je - vanzelfsprekend - docker containers zelf nooit te backuppen en staan configuraties op Github.

Overigens kan er nog een tweede SSD in en wordt de server steeds meer en zwaarder gebruikt. Dus ZFS staat nog wel steeds als optie als mogelijke wijziging

Voor de echte storage behoeftes wordt gebruik gemaakt van Erasure Coding overigens. Daar is ZFS gewoon niet voor geschikt. Ik zie me al wachten totdat ZFS 100TB heeft lopen resilveren Met EC is een schijf vervangen vaak minuten werk, terwijl de performance nauwelijks afneemt. Goedkoop is het niet, maar het zijn mijn euro's niet gelukkig

RAID, RAIDZ of die hocuspocus die Synology of UnRAID uitvoert is toch ook allemaal een vorm van erasure coding? Of verstaan wij er iets anders onder?

[pimlie]

@HyperBart Ik heb weinig ervaring ermee maar voor zover ik e.e.a. begrijp is het grootste verschil dat bij EC de chunk & parity count los staat van het aantal disks. Bij ZFS worden data + parity altijd gelijkmatig over alle disks in een vdev weggeschreven. Bij EC wordt van te voren bepaald in hoeveel chunks met hoeveel parity data wordt weggeschreven. Je kan dus prima 10 nodes met elk 4 disks in je EC set hangen, maar als je dan data zou wegschrijven met 6 chunks & 2 parity (gelijk als een 8 disk RAIDZ2) wordt data dus ook maar over 8 disks weggeschreven in plaats van alle 40. En de keuze naar welke 8 disks wordt geschreven is min of meer willekeurig.
Het is dus onwaarschijnlijk dat op 2 disks in je EC exact gelijke data staat. Als er dan dus bij een parity van 2 vervolgens 2 disks van 10TB uit vallen, dan is het niet zo dat je meteen het risico loopt om 10TB data kwijt te raken als er nog een derde disk zou uitvallen. In plaats daarvan is de kans aannemelijker dat er 2x10TB data is met nog maar 1 parity.

[Uberprutser]

dylan111111 schreef op woensdag 23 april 2025 @ 13:30:
[...]


Na mijn weten kan je helaas geen disks uit een RAIDZ1 pool halen, uit de ZFS documentatie zie ik ook geen opties terug hiervoor. (Verbeter mij gerust als ik het mis heb!)

Ik heb het ook niet kunnen vinden maar dacht misschien iemand nog een hidden trick.
Helaas is het de enige pool en geen heb ik geen andere losse schijven meer in die doos.

Als alles uit gaat is het geen ramp; de data staat ook ergens anders en dient tegenwoordig alleen nog als buffer wanneer het internet wegvalt.

pimlie schreef op woensdag 23 april 2025 @ 13:58:
@Uberprutser vdev's kunnen niet shrinken zoals @dylan111111 aangeeft. Kan je niet iemand vragen er een nieuwe hdd in te hangen?

Een 8 disk vdev met raidz1 op 1000km afstand is overigens een gewaagde keuze...

Een tijdelijk knutselproject dat nooit is vervangen voor iets fatsoenlijks.
De SSDs zitten allang aan hun TBW dus binnenkort zal de rest er ook wel mee stoppen.
En er ligt een andere SSD bovenop, alleen moet de power eraf om de boel te vervangen en dan is het maar weer de vraag of alles weer wakker wordt.

[dcm360]

pimlie schreef op woensdag 23 april 2025 @ 14:58:
@HyperBart Ik heb weinig ervaring ermee maar voor zover ik e.e.a. begrijp is het grootste verschil dat bij EC de chunk & parity count los staat van het aantal disks. Bij ZFS worden data + parity altijd gelijkmatig over alle disks in een vdev weggeschreven. Bij EC wordt van te voren bepaald in hoeveel chunks met hoeveel parity data wordt weggeschreven. Je kan dus prima 10 nodes met elk 4 disks in je EC set hangen, maar als je dan data zou wegschrijven met 6 chunks & 2 parity (gelijk als een 8 disk RAIDZ2) wordt data dus ook maar over 8 disks weggeschreven in plaats van alle 40. En de keuze naar welke 8 disks wordt geschreven is min of meer willekeurig.
Het is dus onwaarschijnlijk dat op 2 disks in je EC exact gelijke data staat. Als er dan dus bij een parity van 2 vervolgens 2 disks van 10TB uit vallen, dan is het niet zo dat je meteen het risico loopt om 10TB data kwijt te raken als er nog een derde disk zou uitvallen. In plaats daarvan is de kans aannemelijker dat er 2x10TB data is met nog maar 1 parity.

Wat ik hier vooral aan toe zou willen voegen is dat het geen 'verschil' is, want wat ZFS toepast is nog steeds EC. Bij ZFS is er vooral de implementatiekeuze gemaakt om de layout van de EC vooraf vast te leggen, vastgekoppeld aan de layout van de disks. Doe je dat niet (zoals bijvoorbeeld bij Ceph), moet er wel een mechanisme worden toegevoegd om uit te vogelen waar de data zich bevindt.

[Mars Warrior]

dcm360 schreef op woensdag 23 april 2025 @ 16:04:
[...]

Wat ik hier vooral aan toe zou willen voegen is dat het geen 'verschil' is, want wat ZFS toepast is nog steeds EC. Bij ZFS is er vooral de implementatiekeuze gemaakt om de layout van de EC vooraf vast te leggen, vastgekoppeld aan de layout van de disks. Doe je dat niet (zoals bijvoorbeeld bij Ceph), moet er wel een mechanisme worden toegevoegd om uit te vogelen waar de data zich bevindt.

Ik versta enkel object-based erasure coding als EC. Dus zoals Ceph en Minio dat doen. De implementatie van ZFS is wat mij betreft een rare EC implementatie met teveel beperkingen.

Vanzelfsprekend is het daardoor wel simpeler te implementeren tov de implementaties van Ceph en Minio, waarbij Minio toch wel de meest simpele setup / implementatie kent vanuit gebruikersperspectief vergeleken met Ceph.

Ik weet overigens ook weer waarom ik geen ZFS voor mijn SSD's heb geimplementeerd: in eerdere testen bleek ZFS een enorme bottleneck te zijn als je een hoge I/O load op bijv. een database hebt. Het ZFS proces "flush-zfs" trok de SSD's naar bijna 100% met een load van 900MB/sec of meer.

Zowel xfs als ext4 hebben totaal geen problemen met dezelfde data ingestion rate van circa 100-200MB/sec. Daar zal ik dan alsnog naar moeten kijken mocht ik alsnog ZFS willen toepassen voor dit soort data.

Het is natuurlijk geen standaard scenario voor een gemiddelde NAS, maar dat is een 13900K ook niet

[dcm360]

Mars Warrior schreef op donderdag 24 april 2025 @ 11:25:
[...]

Ik versta enkel object-based erasure coding als EC. Dus zoals Ceph en Minio dat doen. De implementatie van ZFS is wat mij betreft een rare EC implementatie met teveel beperkingen.

Dat mag, maar is dan wel ongebruikelijk. Reed-Solomon coding zoals gebruikt in Raid 6 is het tekstboekvoorbeeld van Erasure Coding (wat bedacht is door, jawel, Reed en Solomon).

[Mars Warrior]

dcm360 schreef op donderdag 24 april 2025 @ 12:18:
[...]
Dat mag, maar is dan wel ongebruikelijk. Reed-Solomon coding zoals gebruikt in Raid 6 is het tekstboekvoorbeeld van Erasure Coding (wat bedacht is door, jawel, Reed en Solomon).

De mannen op het werk die dit inregelen zijn het daarmee niet eens blijkt. ZFS is parity based
Na doorvragen blijkt dat volledige EC in hun ogen enkel van toepassing is op gedistribueerde systemen als Ceph, Minio en het big data systeem dat HDFS gebruikt.

ChatGPT lijkt het daarmee eens te zijn en geeft de volgende samenvatting:

System	Uses Erasure Coding?	Notes
RAID 0/1	❌	No redundancy or just mirroring
RAID 5/6	⚠️ Simplified parity (limited EC)	Fixed parity, not full EC
ZFS RAID-Z	⚠️ Similar to RAID 5/6 (parity)	Not full erasure coding
Ceph / MinIO / HDFS (with EC)	✅ Full erasure coding	Highly configurable (e.g., 6+3 EC)

En kijk ik bij Starline, dan maken zij ook expliciet onderscheid tussen RAID, ZFS, Erasure Coding, en Replica

Uiteindelijk gaat het er natuurlijk om dat het doet wat je verwacht: je data veilig houden
ZFS past nog mooi in een thuisserver met zijn 4 schijven, EC configs gaan al snel naar een minium van 12.

Ik snap nu in ieder geval weer waar ik deze verdeling vandaan heb: van het werk, maar blijkbaar ben ik niet de enige die het zo geleerd heeft.

Er gaat nu nog wel iemand kijken of hij het ZFS probleem dat ik had icm hoge data rate kan reproduceren, dus dat is fijn. Mijn server thuis heeft overigens gewoon DDR5, dus on-die ECC, en geen full-ECC. Helemaal aan de ZFS eisen voldoen wordt dus moeilijk

[dcm360]

Mars Warrior schreef op donderdag 24 april 2025 @ 14:48:
[...]

De mannen op het werk die dit inregelen zijn het daarmee niet eens blijkt. ZFS is parity based
Na doorvragen blijkt dat volledige EC in hun ogen enkel van toepassing is op gedistribueerde systemen als Ceph, Minio en het big data systeem dat HDFS gebruikt.

ChatGPT lijkt het daarmee eens te zijn en geeft de volgende samenvatting:

System	Uses Erasure Coding?	Notes
RAID 0/1	❌	No redundancy or just mirroring
RAID 5/6	⚠️ Simplified parity (limited EC)	Fixed parity, not full EC
ZFS RAID-Z	⚠️ Similar to RAID 5/6 (parity)	Not full erasure coding
Ceph / MinIO / HDFS (with EC)	✅ Full erasure coding	Highly configurable (e.g., 6+3 EC)

En kijk ik bij Starline, dan maken zij ook expliciet onderscheid tussen RAID, ZFS, Erasure Coding, en Replica

Dan is dit een mooi voorbeeld van hoe iets in 'de echte wereld' genoemd wordt, en dat dat af kan wijken van hoe iets algoritmisch/wiskundig in elkaar steekt. Dat valt overigens ook wel af te lezen uit het stukje op Wikipedia, ook daar staat dat RAID (in de juiste variant) technisch gezien gewoon voldoet om Erasure Coding te zijn, maar dat er meestal naar wat anders mee wordt verwezen.

[Mars Warrior]

dcm360 schreef op donderdag 24 april 2025 @ 15:13:
[...]
Dan is dit een mooi voorbeeld van hoe iets in 'de echte wereld' genoemd wordt, en dat dat af kan wijken van hoe iets algoritmisch/wiskundig in elkaar steekt. Dat valt overigens ook wel af te lezen uit het stukje op Wikipedia, ook daar staat dat RAID (in de juiste variant) technisch gezien gewoon voldoet om Erasure Coding te zijn, maar dat er meestal naar wat anders mee wordt verwezen.

Aha!

En dit stukje komt dan precies overeen met hoe de mannen op het werk tegen RAID/ZFS en EC aankijken:

While technically RAID can be seen as a kind of erasure code,[5] "RAID" is generally applied to an array attached to a single host computer (which is a single point of failure), while "erasure coding" generally implies multiple hosts,[3] sometimes called a Redundant Array of Inexpensive Servers (RAIS). The erasure code allows operations to continue when any one of those hosts stops.[4][6]

Het hangt dus af van de context in dit geval of de praktijk en de techniek met elkaar overeenkomen

Dus ook het antwoord van ChatGPT komt uit de praktijk. Nou, nou, dat is wel eens anders

Mijn ZFS performance probleem lijkt overigens onoplosbaar. ZFS cached en dus flushed nu eenmaal naar disk. Er zijn 2 databases getest: CrateDB en QuestDB. De laatste heeft met dezelfde data ongeveer 4x zoveel diskruimte nodig, en heeft met ZFS dus de meeste problemen bij piekbelastingen.

Een aparte SSD lijkt dan de enige optie om te voorkomen dat andere containers last hebben van de idioot hoge I/O belasting.

[Uberprutser]

Uberprutser schreef op woensdag 23 april 2025 @ 15:18:
De SSDs zitten allang aan hun TBW dus binnenkort zal de rest er ook wel mee stoppen.
En er ligt een andere SSD bovenop, alleen moet de power eraf om de boel te vervangen en dan is het maar weer de vraag of alles weer wakker wordt.

Defecte SSD is vervangen, de rest van de schijven hebben zich ook in de afgelopen 24 uur gemeld met fouten (smart) en zojuist is een van die SSDs er ook mee gestopt.

De hele boel maar uitgezet en gaat de container in, nu heeft een Pi alles overgenomen wat er nog op draaide.

[sOid]

Ik ben een nieuwe server aan het bouwen en ben aan het dubben over de ZFS-configuratie.

Ik heb 2x14TB schijven en wil er nog wat bij kopen. Idealiter 2 disk redundancy. Nou heb ik in principe aan 28TB meer dan voldoende. Ik ben gecharmeerd van RAIDZ2, maar dan wordt dus aanbevolen er nog 4 schijven bij te kopen. Dat is echt overkill qua opslag.

Wat is verstandig? 2 schijven extra en RAIDZ2 of 2 schijven extra en mirrors? Hoe gaat dat met het resilveren in beide gevallen? Of is het toch het verstandigst om nog 4 extra schijven te kopen en de rest van de maand op water en brood te leven .

Daarnaast heb ik een nVME-stickje met daarop Proxmox en 2x1TB SSD waar ik een mirror van wil maken voor VM's, containers etc.

Graag advies

[d3vlin]

Ik weet niet wat voor nvme disk het is (naast snelheid en omvang is vooral ook TBW relevant), maar ik zou denk ik gaan voor 4 schijven in Z2 en een mirror nvme als special device voor metadata en small_blocks. Heb je een snellere pool dan met mirrors en met zfs 2.3+ kun je met raid expansion evt. later 1 schijf toevoegen aan de Z2 voor meer storage ipv dat er 2 schijven bij moeten voor een extra vdev met mirrors.

Proxmox VE en VM/LXC storage dan op 2x1TB in zfs mirror (Proxmox maakt zelf de pool en de datasets daarvoor aan bij install).

Proxmox Backup Server installeren in LXC op VE en de datastore aanmaken op de storage pool.
Alle VM's en LXC's backuppen naar PBS (lees: incremental backups en deduplicatie), behalve de PBS LXC zelf, die backup je lokaal met een beetje retentie en repliceer je met een scriptje naar de storage pool.

Mocht je Proxmox om zeep gaan installeer je Proxmox VE opnieuw op de 2x1TB, restore je de PBS LXC vanaf de storage pool en de rest van de VM's / LXC's vanuit PBS. Binnen 30 minuten is je hele systeem weer online.

Wat je verder nog nodig hebt is externe/offline backup van de storage pool, want RAID != backup, maar dat wist je al. ;-)

[orvintax]

sOid schreef op zondag 1 juni 2025 @ 09:58:
Ik ben een nieuwe server aan het bouwen en ben aan het dubben over de ZFS-configuratie.

Ik heb 2x14TB schijven en wil er nog wat bij kopen. Idealiter 2 disk redundancy. Nou heb ik in principe aan 28TB meer dan voldoende. Ik ben gecharmeerd van RAIDZ2, maar dan wordt dus aanbevolen er nog 4 schijven bij te kopen. Dat is echt overkill qua opslag.

Wat is verstandig? 2 schijven extra en RAIDZ2 of 2 schijven extra en mirrors? Hoe gaat dat met het resilveren in beide gevallen? Of is het toch het verstandigst om nog 4 extra schijven te kopen en de rest van de maand op water en brood te leven .

Daarnaast heb ik een nVME-stickje met daarop Proxmox en 2x1TB SSD waar ik een mirror van wil maken voor VM's, containers etc.

Graag advies

Het ligt er een beetje aan wat je wilt. Ik kan aanraden om met een site als deze te spelen, dan zie je meteen het effect van je configuraties.

[HyperBart]

orvintax schreef op dinsdag 3 juni 2025 @ 09:43:
[...]

Het ligt er een beetje aan wat je wilt. Ik kan aanraden om met een site als deze te spelen, dan zie je meteen het effect van je configuraties.

Ik vind dat altijd enorm confronterend

[d3vlin]

d3vlin schreef op donderdag 18 april 2024 @ 08:51:
Wellicht goed om te noemen in deze context:
https://github.com/openzfs/openzfs-docs/issues/494
https://www.reddit.com/r/...developer_for_the_native/
https://www.phoronix.com/news/OpenZFS-Encrypt-Corrupt

Aanvulling:
https://news.ycombinator.com/item?id=39341341
https://docs.google.com/s...SbPZwTexCg/htmlview?pli=1

Native encryption is elegant en het idee om snapshots raw/encrypted te kunnen versturen naar een andere pool (send -w) zonder dat de ontvangende kant de sleutel nodig heeft is m.i. heel goed, zo niet ideaal. Maar potentiele datacorruptie juist bij het gebruik van die methode is het dan weer niet waard. Ik hoop van harte dat iemand dit stuk ZFS code goed onder handen kan nemen.

Deze ontwikkeling kan hier toch niet ongenoemd blijven. Nu raw send/receives nog.
https://www.reddit.com/r/...orruption_bug_when_using/
https://github.com/openzfs/zfs/issues/12014

[RobertMe]

Donderdag kwam ik er achter dat een HDD uit mijn "NAS" vermist was. En gisteren maar de conclusie getrokken dat die overleden is. (Zowel in de "NAS" als USB dock wordt wel de HDD gezien maar elke vorm van lezen faalt, "zelfs" de partities ziet die niet). Nu komt vanmiddag een nieuwe.

Alleen, hoe doe ik nu replacen? Ik heb wel al vaker een replace gedaan, maar dat was "vroeger", met werkende HDDs (van 3 HDDs gekocht in dezelfde tijd elk ~jaar een vervangen zodat ze niet dezelfde runtime hebben, en steeds geupgrade naar groter). Dus die replaces kon ik gewoon op gemelde by-id naampje doen. Maar met een zpool status zie ik nu een/het interne id (incl een "was /dev/disk/by-id/...." vermelding). Ik neem aan dat ik dat interne id ook gewoon kan gebruiken? Dus zfs replace tank <interne id zoals status laat zien> <Toshiba something van de nieuwe uit by-id>. Gaat overigens om een 3 disk RAIDZ1 pool.

[dcm360]

@RobertMe Ja, dat werkt precies zo Het komt bij mij vaker voor dat de originele schijf niet meer beschikbaar is tijdens de replace (meestal vanwege fysiek ruimtegebrek), en dat werkt dan.

[RobertMe]

dcm360 schreef op zaterdag 14 juni 2025 @ 12:14:
Het komt bij mij vaker voor dat de originele schijf niet meer beschikbaar is tijdens de replace (meestal vanwege fysiek ruimtegebrek), en dat werkt dan.

Is dat niet "onhandig" door het verhoogde risico op een "corruptie" doordat je dus tijdelijk minder redundantie hebt? Kun je in dat geval (van "te weinig poorten") niet beter een van beiden online houden over een USB dock?

Zo heb ik eens een 1TB single drive pool geupgrade naar 4TB. Via een USB dock de nieuwe aangesloten en de mirror aangemaakt (/nieuwe geattached aan de oude), en toen die klaar was de oude SSD er uit gehaald en nieuwe geplaatst. Ging om een mini PC met maar 1 SATA poort. Doordat ZFS de disks toch al dat unieke id geeft ziet die daarna dus prima die drive en zal die hem gebruiken, ondanks de andere "plek" (USB vs SATA / uberhaupt een andere /dev/ of /by-id/ of ... path).

Edit:
Dan uiteraard wel doen met een USB dock / adapter die verder overal vanaf blijft. Voldoende adapters die niet 100% exact de originele gegevens doorgegeven. Bv de WD Elements externe HDDs als je die doet shucken hebben ze "ineens" meer sectoren. Wat dus leidt tot "errors" dat er geen backup partitie tabel aan het einde van de disk staat. (En als je dat "fixt" zodat die de partitie tabel wel ook weer achteraan staat loop je uiteraard het risico dat je weer een deel van de partitie tabel "aan het einde" met die adapter overschrijft).

[ Voor 21% gewijzigd door RobertMe op 14-06-2025 12:50 ]

[dcm360]

RobertMe schreef op zaterdag 14 juni 2025 @ 12:46:
[...]

Is dat niet "onhandig" door het verhoogde risico op een "corruptie" doordat je dus tijdelijk minder redundantie hebt? Kun je in dat geval (van "te weinig poorten") niet beter een van beiden online houden over een USB dock?

Dat zou op zich wel het overwegen waard zijn als het zou gaan om een Z1-array. Meestal gaat het dan echter om de overwogen keuze om de contoller/backplane/chassis gewoon vol te zetten met Z2-arrays in plaats van een slot/poort vrij te houden en voor een Z1-array te gaan.

Thuis (waar ik dan wel weer Z1-arrays draai) verzin ik er inderdaad wel altijd iets op. Oude RocketRAID-kaartjes zijn prima om een gebrek aan SATA-aansluitingen op te lossen, en schijven kunnen desnoods ook wel ergens los naast een case liggen

[RobertMe]

dcm360 schreef op zaterdag 14 juni 2025 @ 13:24:
[...]

Dat zou op zich wel het overwegen waard zijn als het zou gaan om een Z1-array. Meestal gaat het dan echter om de overwogen keuze om de contoller/backplane/chassis gewoon vol te zetten met Z2-arrays in plaats van een slot/poort vrij te houden en voor een Z1-array te gaan.

Ah ja, zakelijk / profi zul je ook een iets ander opslag apparaat hebben. En bij een 19" model in een rack wordt een USB disk erbij ook lastig En al helemaal als het een SAS disk zou zijn (geen idee of dat naar USB kan).
En met Z2 heb je natuurlijk al dubbele redundantie. Kans dat net tijdens die resilver nog twee disks uitvallen is wel heel klein. Maar het kan uiteraard wel.

Thuis (waar ik dan wel weer Z1-arrays draai) verzin ik er inderdaad wel altijd iets op. Oude RocketRAID-kaartjes zijn prima om een gebrek aan SATA-aansluitingen op te lossen, en schijven kunnen desnoods ook wel ergens los naast een case liggen

Of dat inderdaad. Maar een USB dock / adapter scheelt dan natuurlijk nogal wat werk ten opzichte van (tijdelijk) een extra kaartje inbouwen en evt dan met open case/... draaien. Kost mogelijk alleen performance (afhankelijk van USB versie).

* RobertMe heeft een Silverstone case met hotswap, 8 bays. Maar mobo heeft maar 6 poorten. En weet eigenlijk niet eens welke daadwerkelijk aangesloten zijn Heeft wel lange tijd gedraaid met een extra PCIe SATA kaartje, maar eigenlijk dus niet nodig (gezien 3 disks maar in gebruik). Maar nu het systeem meer uit dan aan staat maakt het eerst open trekken om kabels te checken ook niet echt uit en is dat kaartje er ook uit.

[The-Source]

In mijn RAID-Z2 pool is SDC qua SMART aan vervanging toe (al wat langer maar 1e dat de melding kwam was lang geleden en melding 2 kwam 2 weken geleden en gisteren melding 3 gehad dus wordt nu echt tijd.
Nu kan ik wel een stappen plan via chatGPT opvragen hoe het beste de vervangen te doen.

Maar wellicht zijn hier nog tips?
ZFS Pool is onderdeel van mijn proxmoxVE host (maar is niet de OS disk)

[RobertMe]

The-Source schreef op maandag 14 juli 2025 @ 16:20:
In mijn RAID-Z2 pool is SDC qua SMART aan vervanging toe (al wat langer maar 1e dat de melding kwam was lang geleden en melding 2 kwam 2 weken geleden en gisteren melding 3 gehad dus wordt nu echt tijd.
Nu kan ik wel een stappen plan via chatGPT opvragen hoe het beste de vervangen te doen.

Maar wellicht zijn hier nog tips?
ZFS Pool is onderdeel van mijn proxmoxVE host (maar is niet de OS disk)

Als dat kan de nieuwe disk erbij zetten (anders eerst de oude er uit halen, maar dan mis je dus redundancy tijdens de resilver). Daarna (onafhankelijk of het met of zonder de nieuwe is) een zpool replace <poolnaam> <oude disk> </dev/by-id naampje van de nieuwe disk>. <pool naam> en <oude disk> kun je daarbij uiteraard halen uit de zpool status output.

[The-Source]

RobertMe schreef op maandag 14 juli 2025 @ 16:53:
[...]

Als dat kan de nieuwe disk erbij zetten (anders eerst de oude er uit halen, maar dan mis je dus redundancy tijdens de resilver). Daarna (onafhankelijk of het met of zonder de nieuwe is) een zpool replace <poolnaam> <oude disk> </dev/by-id naampje van de nieuwe disk>. <pool naam> en <oude disk> kun je daarbij uiteraard halen uit de zpool status output.

Heb uit uiteindelijk de zpool offline sdc gedaan en daarna systeem uitgeschakeld en disk vervangen.
Nu nog 30 uur te gaan met de resilver in het begin was dat nog 74uur dus dat is al een stukje minder geworden

[HyperBart]

@The-Source ik zie alleen dat je met de /dev/sdX naamgevingen werkt. Klopt dat?
Beter is om met labels te werken of met identifiers die altijd naar die disk wijzen omdat die /dev/sdX namen kunnen wisselen na een reboot.

Normaal los je dat op door met partities te werken op die schijf en dan een labeltje er aan te hangen waardoor ze in "by-partlabel" opduiken.

Aangezien je volledige devices doorgeeft moet/mag iemand als @FireDrunk daar wat over roepen welk pad je best gebruikt.

Je exporteert dan de zpool en importeert deze opnieuw met

zpool import -d /pad/naar/disks POOLNAAM

Dat gaat betrouwbaarder werken dan wat je nu doet.
Kan trouwens zijn dat het commando boven niet helemaal klopt qua syntax, dan moet je de poolnaam even verschuiven. Ben het kwijt, lang geleden en kga mijn pool niet exporteren en importeren nu

EDIT: post gevonden van @FireDrunk lang geleden

[ Voor 4% gewijzigd door HyperBart op 16-07-2025 10:34 ]

[The-Source]

@HyperBart klopt dat de meeste disk nu nog onder sd<x> erin zitten.
Nieuwe disk is dus wel by ID gedaan. Proxmox waarmee in de ZFS pool heb gemaakt heeft dat denk ik destijds zo gemaakt maar dat is ruim een jaar dus weet dat ook niet meer zeker.
Op dit moment is nog een scrub bezig.
Maar is het mogelijk om bijvoorbeeld sda te vervangen door device ID zonder te resilver?
Er van uit gaan natuurlijk dat ik ID van sda gebruik

code:

pool: hdds
 state: ONLINE
  scan: scrub in progress since Tue Jul 15 19:43:53 2025
        32.3T / 34.8T scanned at 644M/s, 23.9T / 34.7T issued at 476M/s
        0B repaired, 68.75% done, 06:37:53 to go
config:

        NAME                            STATE     READ WRITE CKSUM
        hdds                            ONLINE       0     0     0
          raidz2-0                      ONLINE       0     0     0
            sda                         ONLINE       0     0     0
            sdb                         ONLINE       0     0     0
            ata-ST12000NM0127_ZJV0JASR  ONLINE       0     0     0
            sdd                         ONLINE       0     0     0
            sde                         ONLINE       0     0     0
            sdf                         ONLINE       0     0     0
            sdg                         ONLINE       0     0     0

errors: No known data errors

Dat is hoe het er nu uit ziet

[ Voor 52% gewijzigd door The-Source op 16-07-2025 10:20 ]

[HyperBart]

@The-Source.
Grappig, die ene die uit de pas loopt.

Ja, maar ik vind dat potentieel een actie die telkens herhaald fout kan lopen.

Beter/makkelijker in één slag zou dan zijn om op basis van deze post:

FireDrunk in "Het grote ZFS topic"

zpool export [poolnaam]
zpool import -d /dev/disk/by-id/ [poolnaam]
reboot

Te doen

[RobertMe]

HyperBart schreef op woensdag 16 juli 2025 @ 10:03:
Normaal los je dat op door met partities te werken op die schijf en dan een labeltje er aan te hangen waardoor ze in "by-partlabel" opduiken.

Het gebruik van partities wordt door ZFS volgens mij afgeraden? Dus dat is sowieso niet de aanbevolen route dan. Beter os gewoon de by-id route. Daarin staat het id van de disk met daarin bij mijn weten (/observatie) ook het serienummer. Dat is dus prima uniek en zal niet wijzigen.

En als het wijzigt hoeft dat volgens mij tegenwoordig ook nog niet perse een ramp te zijn. Immers heeft elke vdev ook een eigen uniek id in de metadata en verwijst de pool naar de vdev op basis van dat id. Uiteindelijk weet die de boel dus altijd wel weer te vinden zolde disk fysiek maar aanwezig is. Maar het gebruik van een persistent identifier / path blijft wel aanbevolen. Maar het is ook niet zo dat een pool stuk is als een disk eerst sda was en daarna ineens sdb. Kan potentieel alleen wat handwerk kosten?

[d3vlin]

The-Source schreef op woensdag 16 juli 2025 @ 10:17:
Maar is het mogelijk om bijvoorbeeld sda te vervangen door device ID zonder te resilver?

Wat @HyperBart zegt, hele pool ineens doen. En zolang je de hele pool ineens compleet importeert is er geen resilver nodig. Of dat nou via sdX of ID of een mix daarvan is maakt niet uit.

Reboot is volgens mij niet nodig. Als het goed is overschrijft hij de pool cache bij het importeren en gebruikt hij die info de volgende keer vanzelf. Je zou dat ook kunnen testen door de pool na een import met ID's te exporteren en weer te importeren zonder de -d opties.

[HyperBart]

RobertMe schreef op woensdag 16 juli 2025 @ 10:44:
[...]

Het gebruik van partities wordt door ZFS volgens mij afgeraden? Dus dat is sowieso niet de aanbevolen route dan. Beter os gewoon de by-id route. Daarin staat het id van de disk met daarin bij mijn weten (/observatie) ook het serienummer. Dat is dus prima uniek en zal niet wijzigen.

En als het wijzigt hoeft dat volgens mij tegenwoordig ook nog niet perse een ramp te zijn. Immers heeft elke vdev ook een eigen uniek id in de metadata en verwijst de pool naar de vdev op basis van dat id. Uiteindelijk weet die de boel dus altijd wel weer te vinden zolde disk fysiek maar aanwezig is. Maar het gebruik van een persistent identifier / path blijft wel aanbevolen. Maar het is ook niet zo dat een pool stuk is als een disk eerst sda was en daarna ineens sdb. Kan potentieel alleen wat handwerk kosten?

Er is geen bezwaar om partities te gebruiken, vaak werd dit verwisseld met "directe access" tot de disk wat wil zeggen dat je geen RAID controllers tussen de kaart wil maar een kale HBA om de SATA/SAS link zo direct mogelijk te houden.

De reden voor partities is dat je dan manueel de controle zelf houdt over de groottes van disks waardoor je later makkelijker een andere disk met licht afwijkende sizes kan gebruiken omdat je dan wat extra padding vanachter laat om die kleine verschillen op te vangen.

[silverball]

Ik ben hier volgens mij wel eens vaker een discussie gestart over ECC, maar voor de kenners; mocht de scrub-of-death gebeuren, die theoretisch zonder ECC gebruik kan voorkomen, markeert ZFS de data dan nog wel als incorrect ? Want dan kan ik gewoon de back-up terugzetten indien een scrub fout gaat.

[vanaalten]

Ik heb thuis een Debian ‘Bookworm’ servertje met encrypted ZFS-on-root (1 disk) en ben van plan deze volgend weekend naar ‘Trixie’ te upgraden.

Zijn er hier mensen die dit al gedaan hebben? Kan ik grote problemen verwachten?

[FireDrunk]

Partities zijn prima tegenwoordig. Vroeger was dat vanwege alignment issues nog wel eens een probleem, en in BSD was het lock mechnisme van een partities iets anders dan van een hele disk, maar dat is in ZoL al jaren opgelost.

Sterker nog, ZFS (ZoL) maakt zelf tegenwoordig partities aan by default.
En ze krijgen die ook netjes een 'name' welke gebruikt kan worden eventueel.

Partition number (1,9, default 9): 1

         Device: /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_9LGD8UAG-part1
          Start: 2048
            End: 27344746495
        Sectors: 27344744448
           Size: 12.7T
           Type: Solaris /usr & Apple ZFS
      Type-UUID: 6A898CC3-1DD2-11B2-99A6-080020736631
           UUID: 87ABA4B7-B02F-944D-A529-904DDD05864B
           Name: zfs-fcb056f55f071886

Dat name veld zie je dus terug in /dev/disk/by-partlabel

[vanaalten]

vanaalten schreef op zondag 27 juli 2025 @ 11:18:
Ik heb thuis een Debian ‘Bookworm’ servertje met encrypted ZFS-on-root (1 disk) en ben van plan deze volgend weekend naar ‘Trixie’ te upgraden.

Zijn er hier mensen die dit al gedaan hebben? Kan ik grote problemen verwachten?

Afgelopen weekend de overstap gemaakt en voor wie twijfelt: compleet nul problemen met ZFS bij de upgrade.

Ik was wat huiverig, ook omdat ik wat creatieve dingen doe met een custom-initrd (de initrd doet zelf op het LAN de decryptie-key ophalen voor de encrypted root disk), maar ook dat werkte meteen probleemloos.

[silverball]

vanaalten schreef op maandag 4 augustus 2025 @ 14:52:
[...]

Afgelopen weekend de overstap gemaakt en voor wie twijfelt: compleet nul problemen met ZFS bij de upgrade.

Ik was wat huiverig, ook omdat ik wat creatieve dingen doe met een custom-initrd (de initrd doet zelf op het LAN de decryptie-key ophalen voor de encrypted root disk), maar ook dat werkte meteen probleemloos.

Kijk daar heb je wat aan. Zelf heb ik rocky met openZFS, dat is ongeveer elke 3 maanden feest. Misschien toch Debian eens installeren.

[RobertMe]

silverball schreef op vrijdag 8 augustus 2025 @ 15:54:
Misschien toch Debian eens installeren.

Vanaf morgen kan het Dan komt Trixie uit.

* RobertMe moet nog even kijken wat die gaat doen. Op mijn router met N5105 draai ik een custom ZFS build waarin SSE ondersteuning voor encryptie zit (ZFS gebruikt AVX dat niet op deze CPU zit). Maar die is dan nog op basis van een 2.2 package dat ik toentertijd uit backports heb gehaald (of nouja, ik heb eerst een tijdje die 2.2 versie uit backports gedraaid, en daarna op basis van die versie / dat originele package de patch er op toegepast). Moet alleen nog even kijken of ik gewoon update naar 2.3 uit de repo, de custom build aanhoud, of kijk of de patch op 2.3 kan (gezien er meerdere soortgelijke PRs lopen voor andere instructiesets m.b.t. hardware encryptie en ik meen 0 daarvan gemerged zijn denk ik dat de PR wel nog toepasbaar is)
En een ander systeem op basis van N5105 heb ik wel diezelfde ZFS versie op draaien, via backports, maar zonder de patch (de router encrypt ik niet essentiele data op, als het weg is is het weg. Het "servertje" daarentegen..., staan ook backups van PCs etc op in een encrypted dataset, iets kritischer dus). Deze zou dus sowieso prima over moeten kunnen naar ZFS 2.3.

[GioStyle]

Wees voorzichtig en neem er de tijd voor. Mijn ssd geeft I/O errors met Debian Trixie, terwijl het in Bookworm prima werkt. Nog geen oorzaak gevonden en tijdelijk maar weer even terug gezet naar Bookworm.

[RobertMe]

GioStyle schreef op zondag 10 augustus 2025 @ 22:18:
Wees voorzichtig en neem er de tijd voor. Mijn ssd geeft I/O errors met Debian Trixie, terwijl het in Bookworm prima werkt. Nog geen oorzaak gevonden en tijdelijk maar weer even terug gezet naar Bookworm.

* RobertMe heeft ook al meerdere issues gehad. Waaronder ZFS gerelateerd dat mijn encrypted datasets niet meer mounte. Heb over mijn oplossing toentertijd wel redelijk wat geschreven hier. Komt simpelweg neer op dat de key op een ander systeem staat en via een custom "load" script / service wordt ingeladen (door dit script vast te leggen als een requirement van de zfs-load-key@<dataset> service dat weer een requirement voor de mount unit is). Echter ontstond er een dependency loop. Het mountpoint is onderdeel van local-fs.target, vervolgens depend mijn "zfs-load-remote-key" op network-online. Alleen depend network-online op een, nieuwe, dkms service, die weer depend op local-fs. Gevolg was dat de mount niet werd uitgevoerd

offtopic:
Daarnaast heb ik SSH geconfigureerd met specifieke Listen adressen. Maar ergens is iets gewijzigd waardoor dit niet meer werkt en errort SSH startup op dat de IPs niet beschikbaar zijn.
En netwerk technisch gaan wel meer dingen mis. IPv6 werkt niet, routeren naar Docker containers met een IPv6 adres werkt prima. Maar SSH over IPv6 naar de bak zelf? Nope. En systemd-networkd-wait-online.service faalt op "timeout reached". Zelfs als ik deze maar alleen op één interface laat wachten (de "lan" interface). En logging van systemd-networkd ook laat zien dat de link geconfigureerd.

[orvintax]

RobertMe schreef op zondag 10 augustus 2025 @ 23:57:
[...]

* RobertMe heeft ook al meerdere issues gehad. Waaronder ZFS gerelateerd dat mijn encrypted datasets niet meer mounte. Heb over mijn oplossing toentertijd wel redelijk wat geschreven hier. Komt simpelweg neer op dat de key op een ander systeem staat en via een custom "load" script / service wordt ingeladen (door dit script vast te leggen als een requirement van de zfs-load-key@<dataset> service dat weer een requirement voor de mount unit is). Echter ontstond er een dependency loop. Het mountpoint is onderdeel van local-fs.target, vervolgens depend mijn "zfs-load-remote-key" op network-online. Alleen depend network-online op een, nieuwe, dkms service, die weer depend op local-fs. Gevolg was dat de mount niet werd uitgevoerd

offtopic:
Daarnaast heb ik SSH geconfigureerd met specifieke Listen adressen. Maar ergens is iets gewijzigd waardoor dit niet meer werkt en errort SSH startup op dat de IPs niet beschikbaar zijn.
En netwerk technisch gaan wel meer dingen mis. IPv6 werkt niet, routeren naar Docker containers met een IPv6 adres werkt prima. Maar SSH over IPv6 naar de bak zelf? Nope. En systemd-networkd-wait-online.service faalt op "timeout reached". Zelfs als ik deze maar alleen op één interface laat wachten (de "lan" interface). En logging van systemd-networkd ook laat zien dat de link geconfigureerd.

Klinkt wel als een vrij specifieke setup Ik vraag me af of dit soort dingen niet ergens gedocumenteerd staat. Meestal heeft Debian goede documentatie.

[rikadoo]

Mini vraagje, ik heb een ZFS build op Ubuntu, nu heb ik een nieuwe HBA op de kop weten te tikken. Kan ik gewoon de HBA vervangen en de disken hierop aansluiten, booten en klaar? Of moet ik eerst nog wat van te voren doen?

[RobertMe]

rikadoo schreef op vrijdag 22 augustus 2025 @ 17:02:
Mini vraagje, ik heb een ZFS build op Ubuntu, nu heb ik een nieuwe HBA op de kop weten te tikken. Kan ik gewoon de HBA vervangen en de disken hierop aansluiten, booten en klaar? Of moet ik eerst nog wat van te voren doen?

Zou moeten werken. Worst case kost het ZFS (initieel) wat meer moeite om alles te vinden. Maar in de metadata van de vdev staat een ZFS eigen identifier die die worst case zal gebruiken om disks terug te vinden.

[FireDrunk]

Je moet mogelijk de pool even handmatig opnieuw importeren omdat de cache file niet meer klopt.

[rikadoo]

RobertMe schreef op vrijdag 22 augustus 2025 @ 17:22:
[...]

Zou moeten werken. Worst case kost het ZFS (initieel) wat meer moeite om alles te vinden. Maar in de metadata van de vdev staat een ZFS eigen identifier die die worst case zal gebruiken om disks terug te vinden.

FireDrunk schreef op vrijdag 22 augustus 2025 @ 17:57:
Je moet mogelijk de pool even handmatig opnieuw importeren omdat de cache file niet meer klopt.

Ik heb de boel omgezet en daarna geboot, zpool status geeft me het volgende en alles lijkt gewoon prima te werken.

code:

root@nas:/home/rikadoo# zpool status
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 12:39:42 with 0 errors on Sun Jan 12 07:34:45 2025
config:

        NAME                                           STATE     READ WRITE CKSUM
        tank                                           ONLINE       0     0     0
          raidz2-0                                     ONLINE       0     0     0
            scsi-SATA_ST8000VX0022-2EJ_xxxxxxxx        ONLINE       0     0     0
            scsi-SATA_WDC_WD80EDAZ-11T_xxxxxxxx        ONLINE       0     0     0
            scsi-SATA_WDC_WD80EDAZ-11T_xxxxxxxx        ONLINE       0     0     0
            scsi-SATA_WDC_WD80EDAZ-11T_xxxxxxxx        ONLINE       0     0     0
            scsi-SATA_WDC_WD80EDAZ-11T_xxxxxxxx        ONLINE       0     0     0
            scsi-SATA_WDC_WD80EDAZ-11T_xxxxxxxx        ONLINE       0     0     0
            scsi-SATA_WDC_WD80EDAZ-11T_xxxxxxxx        ONLINE       0     0     0
            scsi-SATA_WDC_WD80EZZX-11C_xxxxxxxx        ONLINE       0     0     0
        logs
          scsi-SATA_KINGSTON_SV300S3_50026B775505EA43  ONLINE       0     0     0
        cache
          scsi-SATA_KINGSTON_SV300S3_50026B7755081268  ONLINE       0     0     0

errors: No known data errors
root@nas:/home/rikadoo#

[ Voor 8% gewijzigd door rikadoo op 22-08-2025 18:35 ]

[FireDrunk]

Had je een specifieke reden om een (nieuwe) hba te kopen?

[rikadoo]

FireDrunk schreef op vrijdag 22 augustus 2025 @ 18:56:
Had je een specifieke reden om een (nieuwe) hba te kopen?

Nee ik kwam voor een leuke prijs een 12Gbps HBA tegen. dus ik dacht een leuke upgrade voor de toekomst als vervangen van de voor mij oudere IBM 1015 HBA.

[FireDrunk]

Enig idee van het stroomverbruik?

[rikadoo]

FireDrunk schreef op vrijdag 22 augustus 2025 @ 19:49:
Enig idee van het stroomverbruik?

Eerlijk gezegd niet, maar de server staat toch alleen maar aan zodra ik hem nodig heb, dus ik denk dat het voor mij nog wel te overzien is.

[P5ycho]

Kwam er gisteren achter dat ik eind 2024 mijn snapshot regime per ongeluk gesloopt heb. Daardoor voor het eerst in m'n leven daadwerkelijk een backup nodig gehad na een ongelukje met het overschrijven van een document met een oude versie.
Nu snapshots weer elke nacht gemaakt worden dik 2TB teruggewonnen (5x 2TB SSD RAIDZ1 = ~8TB), de snapshots namen ondertussen flink wat loze ruimte in.

Wat een foutje in het aanpassen van een cronjob wel niet teweeg kan brengen...