Het grote ZFS topic

[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.