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.

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

[CH4OS]

Ik zie vandaag in Scrutiny dat een van mijn disks slecht begint te worden. Nu zat ik toch al te denken om die disks te vervangen, maar ik zit ook even met een vraag.

Allereerst zal ik even de situatie schetsen, ik heb 1 ZFS pool, met daarin 2 keer 4 disks als Z1:

code:

data
  raidz1-0
    ata-WDC_WD140EDFZ
    ata-WDC_WD140EDFZ
    ata-WDC_WD140EDFZ
    ata-WDC_WD140EDFZ
  raidz1-1
    ata-WDC_WD40EFRX
    ata-WDC_WD40EFRX
    ata-WDC_WD40EFRX
    ata-WDC_WD40EFRX

Nu is een van de vier 4TB disks (die in raidz1-1 zit) dus slecht aan het worden, als ik deze vervang voor een grotere, kan ik dan gelijk die raidz1-1 vergroten, of kan dat pas wanneer alle vier de disks groter zijn?

Ik zou de disk dan namelijk wel gelijk willen upgraden met meer storage (welke grootte dat dan wordt weet ik nog niet). Ik wil dan misschien omdat mij dat financieel beter uit komt, vier maanden lang 1 disk vervangen (ik heb alle vier de disks tegelijkertijd gekocht dus wie weet hoe lang de anderen het nog gaan uithouden), maar wil dan wel gelijk profiteren van de nieuwe hoeveelheid opslag.

[RobertMe]

CH4OS schreef op vrijdag 2 januari 2026 @ 15:57:
Ik zie vandaag in Scrutiny dat een van mijn disks slecht begint te worden. Nu zat ik toch al te denken om die disks te vervangen, maar ik zit ook even met een vraag.

Allereerst zal ik even de situatie schetsen, ik heb 1 ZFS pool, met daarin 2 keer 4 disks als 2 Z1:

code:

data
  raidz1-0
    ata-WDC_WD140EDFZ
    ata-WDC_WD140EDFZ
    ata-WDC_WD140EDFZ
    ata-WDC_WD140EDFZ
  raidz1-1
    ata-WDC_WD40EFRX
    ata-WDC_WD40EFRX
    ata-WDC_WD40EFRX
    ata-WDC_WD40EFRX

Nu is een van de vier 4TB disks (die in raidz1-1 zit) dus slecht aan het worden, als ik deze vervang voor een grotere, kan ik dan gelijk die raidz1-1 vergroten, of kan dat pas wanneer alle vier de disks groter zijn?

Ik zou de disk dan namelijk wel gelijk willen upgraden met meer storage (welke grootte dat dan wordt weet ik nog niet). Ik wil dan misschien omdat mij dat financieel beter uit komt, vier maanden lang 1 disk vervangen (ik heb alle vier de disks tegelijkertijd gekocht dus wie weet hoe lang de anderen het nog gaan uithouden), maar wil dan wel gelijk profiteren van de nieuwe hoeveelheid opslag.

Wat is raidz1-1? Is dat dan een raidz1 vdev bestaande uit de 4 disks? (Waarbij je twee raidz vdevs hebt waarbij eentje uit 4TB disks bestaat en eentje uit 14TB disks, en die samen een mirror vormen).
Zo ja: RAIDZ1 heeft als capaciteit (kleinste disk * (aantal disks -1)). Dus zolang er nog (minimaal) één 4TB disk in die RAIDZ1 zit blijft de maximale capaciteit (4 * (4-1)) aka 12TB. Pas als alle disks vervangen zijn krijg je de extra capaciteit erbij.

Alleen lees ik (als niet kenner) het meer alsof je nu 2 vdevs hebt die samen een RAIDZ1 vormen. Alleen kan ik dan niet er uit op maken wat die 4 schijven in elke vdev zijn.

[CH4OS]

Ik heb nu als het goed is 2 VDEVs binnen de pool, die elk een Z1 array zijn.

[ Voor 5% gewijzigd door CH4OS op 02-01-2026 16:12 ]

[RobertMe]

CH4OS schreef op vrijdag 2 januari 2026 @ 16:12:
Ik heb nu als het goed is 2 VDEVs binnen de pool, die elk een Z1 array zijn.

Ik denk dat dat idd klopt. 2 vdevs van 4 schijven in Z1 en die vdevs dan als stripe (aka: als een van de vdevs "uitvalt" ben je alles kwijt van de volledige pool). Geen idee hoe ik dacht dat je een mirror had.

Ook op basis van vergelijking bij mijzelf. Mijn "tank" pool met simpel 3 disks in Z1 heet ook "raidz1-0" en dan direct onder "tank" (zoals jij -0 en -1 direct onder "data" hebt). Mijn rpool mirror is vervolgens rpool net daaronder mirror-0 met daaronder de 2 disks. Waarbij jij dus geen mirror, noch andere, vermelding hebt tussen data en raidz1 dat mij doet aannemen dat het om een stripe gaat.

In any case. Voor raidz1 geldt dus wat ik aangaf: capaciteit wordt bepaalt door de kleinste disk. En dat blijft dus 4TB totdat je de laatste disk vervangt.
Is uiteraard ook logisch, stel je hebt 2 disks van 20TB en 1 van 4 TB, hoe wil die dan de parity opslaan? Op de 2 20TB disks kan veel meer data dan dat die de parity op de 4TB disk kan zetten.

[CH4OS]

Thanks, ik was even op zoek naar wat zekerheid, die heb ik nu. Thanks @RobertMe!

[CyBeR]

CH4OS schreef op vrijdag 2 januari 2026 @ 15:57:
Nu is een van de vier 4TB disks (die in raidz1-1 zit) dus slecht aan het worden, als ik deze vervang voor een grotere, kan ik dan gelijk die raidz1-1 vergroten, of kan dat pas wanneer alle vier de disks groter zijn?

Dat kan pas als alle devices in een vdev vervangen zijn door grotere. RAID-Z1/2(/3) werkt net als RAID 5/6(/7, maar dat bestaat eigenlijk niet), dus alle drives moeten even groot zijn of anders telt de kleinste als de limiet voor de capaciteit.

[GorgeousMetal]

CH4OS schreef op vrijdag 2 januari 2026 @ 15:57:
Ik zie vandaag in Scrutiny dat een van mijn disks slecht begint te worden. Nu zat ik toch al te denken om die disks te vervangen, maar ik zit ook even met een vraag.

Nu is een van de vier 4TB disks (die in raidz1-1 zit) dus slecht aan het worden, als ik deze vervang voor een grotere, kan ik dan gelijk die raidz1-1 vergroten, of kan dat pas wanneer alle vier de disks groter zijn?

Ik zou de disk dan namelijk wel gelijk willen upgraden met meer storage (welke grootte dat dan wordt weet ik nog niet). Ik wil dan misschien omdat mij dat financieel beter uit komt, vier maanden lang 1 disk vervangen (ik heb alle vier de disks tegelijkertijd gekocht dus wie weet hoe lang de anderen het nog gaan uithouden), maar wil dan wel gelijk profiteren van de nieuwe hoeveelheid opslag.

Als je TrueNAS hebt dan kun je ook denken aan ZFS expansion. Vervang dus eerst de 'slechtere' disk en breidt dan geleidelijk je pool uit. Dan ben je wellicht met goedkopere harddisk van dezelfde grootte goedkoper uit als je meer ruimte wilt krijgen.

Zie bijvoorbeeld ook de volgende YouTube video.

[ Voor 4% gewijzigd door GorgeousMetal op 06-01-2026 14:05 ]

[d3vlin]

Expansion kan natuurlijk ook zonder TrueNAS.
https://openzfs.github.io...2.4/8/zpool-attach.8.html
https://freebsdfoundation...a-in-storage-flexibility/

Daarna wel een rebalance / rewrite van je data doen voor het bijwerken van de parity:
https://github.com/markusressel/zfs-inplace-rebalancing
https://openzfs.github.io...ster/8/zfs-rewrite.8.html

[CH4OS]

Ik denk dat ik het “gewoon” hou, elke maand een disk vervangen, daarna de z1 expand.

[ElCondor]

-whups- verkeerde topic

[ Voor 101% gewijzigd door ElCondor op 08-01-2026 13:35 ]

[BladeSlayer1000]

Hallo allemaal,

Ik ben al een tijdje aan het experimenteren met TrueNAS, en heb nu al 1 jaar tevreden een 4x2TB RAIDz2 draaien. Vandaag heb ik besloten deze uit te breiden, omdat ik langzaam te weinig ruimte kreeg met nog eens 2x2TB.
Nu heb ik dat gedaan via storage ->manage device -> add VDEV en de stappen gevolgd.

In mijn storage zie ik nu staan:
Usable Capacity: 5.16 TiB
Used: 2.98 TiB
Available: 4.48 TiB

Ik zou zeggen, als ik 2 schijven toevoeg van 1.8TiB, ik totaal ongeveer 7.2 TiB (6x1.8Tib = 7,2TiB) en dan 2 parity disks aan opslag zou moeten hebben; dat is nu niet het geval.
Heb ik iets verkeerd gedaan, of kijk ik ergens overheen?

Wat mij ook opvalt, als ik naar de datasets ga, is de dataset nog steeds 4.48TiB, moet ik nog iets aan de instellingen veranderen?

[ Voor 3% gewijzigd door BladeSlayer1000 op 10-01-2026 22:13 ]

[GioStyle]

Hoe jij denkt dat zfs werkt is niet hoe zfs werkt. Je hebt een pool, bestaande uit 1 vdev 4 disks in raidz2 en aan je pool heb je een vdev toegevoegd, waarschijnlijk een vdev 2 disks in mirror. Zfs maakt daar geen 6 disks raidz2 array van. Wil je dat wel, dan zou je de pool volledig opnieuw moeten opbouwen.

[BladeSlayer1000]

GioStyle schreef op zaterdag 10 januari 2026 @ 22:40:
Hoe jij denkt dat zfs werkt is niet hoe zfs werkt. Je hebt een pool, bestaande uit 1 vdev 4 disks in raidz2 en aan je pool heb je een vdev toegevoegd, waarschijnlijk een vdev 2 disks in mirror. Zfs maakt daar geen 6 disks raidz2 array van. Wil je dat wel, dan zou je de pool volledig opnieuw moeten opbouwen.

Aah, dus je kunt aan een bestaande pool niet extra opslag toevoegen, zonder de pool opnieuw te bouwen. Weer wat geleerd, bedankt!

[RobertMe]

BladeSlayer1000 schreef op zaterdag 10 januari 2026 @ 23:16:
[...]


Aah, dus je kunt aan een bestaande pool niet extra opslag toevoegen, zonder de pool opnieuw te bouwen. Weer wat geleerd, bedankt!

In een "recentere" ZFS versie (2.3? Of 2.4?) zit wel raidz expansion en kun je wel uitbreiden met extra disks. Ik heb alleen geen idee hoe dat exact in elkaar zit (alleen de nieuwe data zal dan anders verdeeld worden? Lijkt me niet dat die ineens alle data gaat "herschrijven", dus van "de" 2 disks de data lezen (+ parity lezen / controleren), de data weer aan elkaar plakken, en dan door vieren delen en opnieuw naar de, nu vier, disks schrijven + nieuwe parity daarvan wegschrijven).

En als je wilt weten wat je nu concreet hebt kun/moet je naar zpool status <pool> kijken. Daar staat beschreven wat de layout is (als het niet ook in TrueNAS staat).

[d3vlin]

BladeSlayer1000 schreef op zaterdag 10 januari 2026 @ 23:16:
[...]
Aah, dus je kunt aan een bestaande pool niet extra opslag toevoegen, zonder de pool opnieuw te bouwen. Weer wat geleerd, bedankt!

Je hebt nu een nieuwe vdev toegevoegd aan je pool, naast de raidz2 vdev die je al had. Je hebt nu waarschijnlijk een raidz2 vdev van 4x2TB (effectief 4TB) en daarnaast een 2x2TB mirror (effectief (2TB). In totaal dan inderdaad 6TB (5.16TB met 1GB = 1024MB etc.). 'zpool status' kan dat mooi weergeven.

Vanuit de oude situatie had je de 4x2TB raidz2 vdev met raid expansion uit kunnen breiden met 2 extra disks naar 6x2TB raidz2. De benodigde stappen hiervoor kwamen een paar posts terug ook al voorbij, inclusief een eventuele rebalance van de data om gebruik te maken van de nieuwe parity ratio.

Je kunt in zfs echter geen vdevs verwijderen zonder de pool om zeep te helpen. Effectief kun je nu dus niet meer terug naar de oude situatie en zal je voor een 6x2TB raidz2 je pool opnieuw op moeten bouwen.

[d3vlin]

RobertMe schreef op zaterdag 10 januari 2026 @ 23:37:
[...]

In een "recentere" ZFS versie (2.3? Of 2.4?) zit wel raidz expansion en kun je wel uitbreiden met extra disks. Ik heb alleen geen idee hoe dat exact in elkaar zit (alleen de nieuwe data zal dan anders verdeeld worden? Lijkt me niet dat die ineens alle data gaat "herschrijven", dus van "de" 2 disks de data lezen (+ parity lezen / controleren), de data weer aan elkaar plakken, en dan door vieren delen en opnieuw naar de, nu vier, disks schrijven + nieuwe parity daarvan wegschrijven).

Matt Ahrens legt dat keurig uit:
https://openzfs.org/w/images/6/68/RAIDZ_Expansion_v2.pdf
Samengevat; alleen nieuwe data wordt met de nieuwe parity ratio weggeschreven. Om je oude data ook bij te werken is er een rebalance nodig van die data. Eerder moest dat buiten zfs om, maar inmiddels is er ook de rewrite feature. Zie ook een paar posts terug.

Of het zinnig is om direct een rebalance te doen na het toevoegen van een disk zijn de meningen over verdeeld: https://louwrentius.com/z...t-has-a-small-caveat.html

[ Voor 9% gewijzigd door d3vlin op 11-01-2026 09:37 ]

[GorgeousMetal]

M.b.t. ZFS rebalance vond ik deze tool op GIT.

[ Voor 3% gewijzigd door GorgeousMetal op 13-01-2026 16:32 ]

[FireDrunk]

BladeSlayer1000 schreef op zaterdag 10 januari 2026 @ 22:11:
Hallo allemaal,

Ik ben al een tijdje aan het experimenteren met TrueNAS, en heb nu al 1 jaar tevreden een 4x2TB RAIDz2 draaien. Vandaag heb ik besloten deze uit te breiden, omdat ik langzaam te weinig ruimte kreeg met nog eens 2x2TB.
Nu heb ik dat gedaan via storage ->manage device -> add VDEV en de stappen gevolgd.

In mijn storage zie ik nu staan:
Usable Capacity: 5.16 TiB
Used: 2.98 TiB
Available: 4.48 TiB

Ik zou zeggen, als ik 2 schijven toevoeg van 1.8TiB, ik totaal ongeveer 7.2 TiB (6x1.8Tib = 7,2TiB) en dan 2 parity disks aan opslag zou moeten hebben; dat is nu niet het geval.
Heb ik iets verkeerd gedaan, of kijk ik ergens overheen?

Wat mij ook opvalt, als ik naar de datasets ga, is de dataset nog steeds 4.48TiB, moet ik nog iets aan de instellingen veranderen?

@BladeSlayer1000

Voordat we je allemaal advies gaan geven, kan je even een `zpool status` posten om te laten zien hoe je config nu exact is? Want als je een 4 disk RAIDZ2 had, en daar 2 _losse_ vdev's aan toegevoegd hebt, is je pool ineens extreem onveilig geworden, en moet je als de wiedeweerga je data veilig gaan stellen

[BladeSlayer1000]

FireDrunk schreef op dinsdag 13 januari 2026 @ 18:29:
[...]

@BladeSlayer1000

Voordat we je allemaal advies gaan geven, kan je even een `zpool status` posten om te laten zien hoe je config nu exact is? Want als je een 4 disk RAIDZ2 had, en daar 2 _losse_ vdev's aan toegevoegd hebt, is je pool ineens extreem onveilig geworden, en moet je als de wiedeweerga je data veilig gaan stellen

Ik heb diezelfde avond nog backups gemaakt (gebeurt iedere avond automatisch naar de cloud, en ik maak manueel nog backups 1x per week op een SSD en HDD waarvan 1 van die 2 altijd op een externe locatie wordt bewaard), de gehele pool verwijderd en omgezet naar 1 nieuwe vdev.

Maar om even te controleren, momenteel ziet de zpool status er zo uit:

code:

 pool: NAS
 state: ONLINE
  scan: scrub repaired 0B in 00:00:07 with 0 errors on Sun Jan 11 00:00:08 2026
config:

        NAME                                      STATE     READ WRITE CKSUM
        NAS                                       ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            18906560-9889-4088-85d4-9b8e21af6d70  ONLINE       0     0     0
            440da2c8-3875-42f8-afa6-61cd3b2a6788  ONLINE       0     0     0
            bc23cfc0-9582-4134-b13f-5df704af73eb  ONLINE       0     0     0
            6ad10a9f-932f-4ef4-85f4-4fdb38fa0058  ONLINE       0     0     0
            04a298b0-779a-478b-9d13-766dfeb6f70b  ONLINE       0     0     0
            3bed9136-4ef2-403e-bc0b-dd564bddecbd  ONLINE       0     0     0

errors: No known data errors

  pool: boot-pool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:58 with 0 errors on Wed Jan  7 03:46:00 2026
config:

        NAME         STATE     READ WRITE CKSUM
        boot-pool    ONLINE       0     0     0
          nvme1n1p3  ONLINE       0     0     0

Is zo alles weer veilig? Ik heb in ieder geval weer rond de 8TB aan opslag, wat ik had verwacht.

[FireDrunk]

BladeSlayer1000 schreef op dinsdag 13 januari 2026 @ 19:43:
[...]


Ik heb diezelfde avond nog backups gemaakt (gebeurt iedere avond automatisch naar de cloud, en ik maak manueel nog backups 1x per week op een SSD en HDD waarvan 1 van die 2 altijd op een externe locatie wordt bewaard), de gehele pool verwijderd en omgezet naar 1 nieuwe vdev.

Maar om even te controleren, momenteel ziet de zpool status er zo uit:

code:

 pool: NAS
 state: ONLINE
  scan: scrub repaired 0B in 00:00:07 with 0 errors on Sun Jan 11 00:00:08 2026
config:

        NAME                                      STATE     READ WRITE CKSUM
        NAS                                       ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            18906560-9889-4088-85d4-9b8e21af6d70  ONLINE       0     0     0
            440da2c8-3875-42f8-afa6-61cd3b2a6788  ONLINE       0     0     0
            bc23cfc0-9582-4134-b13f-5df704af73eb  ONLINE       0     0     0
            6ad10a9f-932f-4ef4-85f4-4fdb38fa0058  ONLINE       0     0     0
            04a298b0-779a-478b-9d13-766dfeb6f70b  ONLINE       0     0     0
            3bed9136-4ef2-403e-bc0b-dd564bddecbd  ONLINE       0     0     0

errors: No known data errors

  pool: boot-pool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:58 with 0 errors on Wed Jan  7 03:46:00 2026
config:

        NAME         STATE     READ WRITE CKSUM
        boot-pool    ONLINE       0     0     0
          nvme1n1p3  ONLINE       0     0     0

Is zo alles weer veilig? Ik heb in ieder geval weer rond de 8TB aan opslag, wat ik had verwacht.

Dat ziet er goed uit, goed dat je backups had, en direct kon herstellen! Petje af!

[BladeSlayer1000]

FireDrunk schreef op woensdag 14 januari 2026 @ 14:11:
[...]

Dat ziet er goed uit, goed dat je backups had, en direct kon herstellen! Petje af!

Bedankt, het is iets wat ik helemaal heb bedacht voordat ik de NAS ging bouwen. Ik zeg altijd je kunt beter goed voorbereid zijn op een crisis, dan achteraf merken dat het niet werkt.

[ComTech]

Ik draai op mn server ubuntu 24.04.03 LTS zfs-2.2.2-0ubuntu9.4 zfs-kmod-2.2.2-0ubuntu9.4
en heb daar een pool van 2 ssd's.
Deze is gemount in de root onder /ssd-pool

NAME PROPERTY VALUE SOURCE
ssd-pool mountpoint /ssd-pool local
ssd-pool mounted yes -

Maar geregeld is deze ineens niet meer gemount waardoor mijn samba shares ineens niet meer werken.
Een zfs set mountpoint lost het probleem wel weer op maar erg handig is dat natuurlijk niet.

Ik heb hier ook incus containers en virtual machines draaien en deze hebben ook een storage pool op dezelfde locatie maar deze blijft gewoon gemount,

Zou het kunnen liggen aan het feit dat de pool is gemount in /ssd-pool in plaats van /mnt/ssd-pool ?
Of iemand anders tips ?

[RobertMe]

ComTech schreef op dinsdag 20 januari 2026 @ 21:33:
Zou het kunnen liggen aan het feit dat de pool is gemount in /ssd-pool in plaats van /mnt/ssd-pool ?

Als je denkt dat het in /mnt moet, dan zou ZFS on root (dus /) nooit werken Dus nee, dat is niet nodig. En in mijn eigen setup(s) heb ik ook extra pools gemount op andere locaties (dan /mnt) en dat werkt gewoon prima.

Of iemand anders tips ?

Iemand, vast wel Maar ik dus niet.

Edit:
Of nouja, maakt Ubuntu systemd mount units aan? Ligt een beetje aan de opzet of dat wel / niet gebeurd. Dan zou je bv systemctl status ssd-mount.mount kunnen doen om bv uberhaupt te verifieren dat systemd mounts gebruikt worden. En mogelijk dat je daar ook iets terug ziet van dat die inactive is na (automagisch) unmounten?

[ Voor 24% gewijzigd door RobertMe op 20-01-2026 22:40 ]

[FireDrunk]

@ComTech is dat ineens na een reboot? of 'gewoon' door de dag heen?

Bij boot zou het kunnen komen omdat Samba eerder start dan je ZFS pool gemount is, maar die kans is wel erg klein, omdat filesystems eerder gemount zouden moeten worden, tenzij je zelf iets aangepast hebt...

[BladeSlayer1000]

Vandaag is helaas mijn TrueNAS instance uitgevallen, door een onverwacht defect in de UPS. Na het opnieuw opstarten ervan is mijn ZFS health niet goed meer.

Ik heb net gekeken, en er blijkt een checksum error te zijn, op sdc.

smartctl -a /dev/sdc weergeeft het volgende:

code:

=== START OF INFORMATION SECTION ===
Model Family:     WD Blue / Red / Green SSDs
Device Model:     WD Red SA500 2.5 2TB
Serial Number:    24074H4A2F07
LU WWN Device Id: 5 001b44 4a55e736b
Firmware Version: 540400WD
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/6028
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Jan 23 09:59:44 2026 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0002) Does not save SMART data before
                                        entering power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (   2) minutes.
Conveyance self-test routine
recommended polling time:        (   3) minutes.
SCT capabilities:              (0x0035) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       1381
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       13
165 Block_Erase_Count       0x0032   100   100   000    Old_age   Always       -       0 0 198
166 Minimum_PE_Cycles_TLC   0x0032   100   100   000    Old_age   Always       -       34
167 Max_Bad_Blocks_per_Die  0x0032   100   100   000    Old_age   Always       -       80
168 Maximum_PE_Cycles_TLC   0x0032   100   100   000    Old_age   Always       -       102
170 Grown_Bad_Blocks        0x0032   100   100   000    Old_age   Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
173 Average_PE_Cycles_TLC   0x0032   100   100   000    Old_age   Always       -       67
174 Unexpected_Power_Loss   0x0032   100   100   000    Old_age   Always       -       5
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0032   100   100   000    Old_age   Always       -       31 (Min/Max 16/106)
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
230 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   Always       -       0 0 2
232 Available_Reservd_Space 0x0033   100   100   001    Pre-fail  Always       -       100
233 NAND_GB_Written_TLC     0x0032   100   100   000    Old_age   Always       -       137404
234 NAND_GB_Written_SLC     0x0032   100   100   000    Old_age   Always       -       1956
241 Host_Writes_GiB         0x0032   100   100   000    Old_age   Always       -       10319
242 Host_Reads_GiB          0x0032   100   100   000    Old_age   Always       -       9432
244 Temp_Throttle_Status    0x0032   100   100   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      1377         -
# 2  Extended offline    Completed without error       00%      1376         -
# 3  Short offline       Completed without error       00%      1374         -
# 4  Short offline       Completed without error       00%      1370         -
# 5  Short offline       Completed without error       00%      1368         -
# 6  Short offline       Completed without error       00%      1368         -
# 7  Short offline       Completed without error       00%      1367         -
# 8  Short offline       Completed without error       00%      1365         -
# 9  Short offline       Completed without error       00%      1364         -
#10  Short offline       Completed without error       00%      1363         -
#11  Short offline       Completed without error       00%      1363         -
#12  Short offline       Completed without error       00%      1355         -
#13  Short offline       Completed without error       00%      1331         -
#14  Short offline       Completed without error       00%      1323         -
#15  Short offline       Completed without error       00%      1322         -
#16  Short offline       Completed without error       00%      1310         -
#17  Short offline       Completed without error       00%      1286         -
#18  Short offline       Completed without error       00%      1284         -
#19  Short offline       Completed without error       00%      1283         -
#20  Short offline       Completed without error       00%      1282         -
#21  Short offline       Completed without error       00%      1282         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

The above only provides legacy SMART information - try 'smartctl -x' for more

Ik zie geen bijzonderheden hierin, zijn er nog meer dingen die ik kan controleren, of kan ik de zpool clear gebruiken op de foutmelding weg te krijgen?

[FireDrunk]

De uitval kan precies op het moment geweest zijn dat er een bitje naar de disk geschreven werdt.
Dat dat een checksum fout oplevert is alleen maar goed, dat betekend dat ZFS de fout netjes gedetecteerd heeft.

Even een scrub doen, de error clearen, en klaar!

[ComTech]

FireDrunk schreef op woensdag 21 januari 2026 @ 10:12:
@ComTech is dat ineens na een reboot? of 'gewoon' door de dag heen?

Bij boot zou het kunnen komen omdat Samba eerder start dan je ZFS pool gemount is, maar die kans is wel erg klein, omdat filesystems eerder gemount zouden moeten worden, tenzij je zelf iets aangepast hebt...

Het gebeurd zomaar en niet net na een reboot.
Nu gaat het alweer bijna een week goed.

[RobertMe]

Iemand een idee wat hier aan de hand kan zijn?

ZFS has finished a scrub:

eid: 706766
class: scrub_finish
host: server
time: 2026-02-08 17:35:34+0100
pool: rpool
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P
scan: scrub repaired 0B in 00:26:54 with 0 errors on Sun Feb 8 17:35:34 2026
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
nvme-Samsung_SSD_980_1TB_...-part2 ONLINE 1 0 0

errors: No known data errors

sudo zpool status -v rpool
  pool: rpool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P
  scan: scrub repaired 0B in 00:26:54 with 0 errors on Sun Feb  8 17:35:34 2026
config:

        NAME                                              STATE     READ WRITE CKSUM
        rpool                                             ONLINE       0     0     0
          nvme-Samsung_SSD_980_1TB_...-part2  ONLINE       1     0     0

errors: No known data errors

sudo smartctl -a /dev/nvme0n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.63+deb13-amd64] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 980 1TB
Serial Number:                      ...
Firmware Version:                   3B4QFXO7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 1,000,204,886,016 [1.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      5
NVMe Version:                       1.4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1,000,204,886,016 [1.00 TB]
Namespace 1 Utilization:            634,208,632,832 [634 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 d921a464a9
Local Time is:                      Sun Feb  8 17:42:34 2026 CET
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0055):     Comp DS_Mngmt Sav/Sel_Feat Timestmp
Log Page Attributes (0x0f):         S/H_per_NS Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     82 Celsius
Critical Comp. Temp. Threshold:     85 Celsius
Namespace 1 Features (0x10):        NP_Fields

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     5.24W       -        -    0  0  0  0        0       0
 1 +     4.49W       -        -    1  1  1  1        0       0
 2 +     2.19W       -        -    2  2  2  2        0     500
 3 -   0.0500W       -        -    3  3  3  3      210    1200
 4 -   0.0050W       -        -    4  4  4  4     1000    9000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        50 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    15%
Data Units Read:                    133,614,198 [68.4 TB]
Data Units Written:                 201,506,067 [103 TB]
Host Read Commands:                 753,983,584
Host Write Commands:                5,559,063,819
Controller Busy Time:               10,258
Power Cycles:                       166
Power On Hours:                     5,729
Unsafe Shutdowns:                   79
Media and Data Integrity Errors:    1
Error Information Log Entries:      1
Warning  Comp. Temperature Time:    7
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               50 Celsius
Temperature Sensor 2:               56 Celsius
Thermal Temp. 1 Transition Count:   28
Thermal Temp. 2 Transition Count:   1
Thermal Temp. 1 Total Time:         3524

Error Information (NVMe Log 0x01, 16 of 64 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS  Message
  0          1     2  0x0167  0xc502  0x000    780405208     1     -  Unrecovered Read Error

Read Self-test Log failed: Invalid Field in Command (0x002)

Het leest voor mij eigenlijk voornamelijk als een random hickup waarbij een lees actie mislukte? Maar wel gek dat ZFS een error geeft maar geen errors geeft ("errors: No known data errors"). [small]Voorheen met oudere versies had ik regelmatig vage issues door snapshot send & receive. Die werden dan op 0x0 (letterlijk 0x0 dus, is geen placeholder) gemeld in een snapshot. Nu gewoon helemaal niks.

Nieuwe scrub in progess, die is nog zonder nieuwe errors.

Edit:
Overigens ter bevestiging:

Feb 08 17:42:26 server smartd[1467]: Device: /dev/nvme0, NVMe error count increased from 0 to 1 (1 new, 0 ignored, 0 unknown)

De smart error is dus echt van hetzelfde moment en niet oud.

Edit2:
Scrub afgerond, ZED heeft zich weer gemeld, maar is copy/paste. 1 read error op de SSD. Het SMART attribuut staat nog steeds op 1, en het SMART error log staat ook nog steeds op 1.

Ik heb nog een scrub gestart maar dat zal vast niks doen. (Het doet soms wel iets bij de error lijst meen ik, maar die is dus sowieso leeg ).
Maar mocht deze ook "succesvol" zijn ga ik uit van een kosmisch event en gooi ik er een "zpool clear" overheen.

Edit3:
Handmatige scrub-2 is klaar. Situatie is nog hetzelfde. 1 read error volgens ZFS (en pool is ook nog steeds in "error"). SMART attribuut staat nog steeds op 1 (en error log count staat ook nog steeds op 1).

Ik wacht hier nog even de reacties af maar lijkt mij een "random" error die te clearen is en weer vergeten kan worden 🤞🏻. Nee, normaal ben ik niet van de "echte" emojis op GoT. Maar de GoT smilies zit geen gekruiste vingers in

[ Voor 8% gewijzigd door RobertMe op 08-02-2026 18:29 ]

[tweaker76]

Read I/O error in de output van zpool status icm smart error toename denk ik dat dit een indicatie is voor hardware falen. Heeft jouw pool redundantie? Ik zie in zpool status geen mirror of raidz vdevs.

[RobertMe]

tweaker76 schreef op dinsdag 10 februari 2026 @ 15:44:
Read I/O error in de output van zpool status icm smart error toename denk ik dat dit een indicatie is voor hardware falen. Heeft jouw pool redundantie? Ik zie in zpool status geen mirror of raidz vdevs.

Klopt , er is geen redundantie (wel backups / send & receive naar een tweede pool op SATA in hetzelfde systeem, elke 6 uur een offsite backup, en periodiek naar een lokale "NAS").

Gezien ik meerdere keren een scrub heb kunnen doen zonder verdere error (/toename aan errors) lijkt mij juist dat het om een semi random error ging. Wel iets om in de gaten te houden en "zorgelijk". Maar als het nu zo blijft niet perse een issue.
Als de error count (smart of ZFS) bleef oplopen dan was een nieuwe SSD uiteraard al onderweg geweest.

[tweaker76]

RobertMe schreef op dinsdag 10 februari 2026 @ 15:50:
er is geen redundantie (wel backups / send & receive naar een tweede pool op SATA in hetzelfde systeem, elke 6 uur een offsite backup, en periodiek naar een lokale "NAS").

Wat de oorzaak van deze lees error ook mag zijn indien de pool geen redundantie heeft dan kan zfs ook geen data automatisch repareren. Indien relevante data wel voldoende in een backup zit dan zal er in ieder geen data verloren gaan. Nog iets relevants kunnen vinden in logfiles?

code:

sudo dmesg | grep -i nvme
sudo journalctl -k | grep -i nvme

[RobertMe]

tweaker76 schreef op dinsdag 10 februari 2026 @ 17:04:
[...]


Wat de oorzaak van deze lees error ook mag zijn indien de pool geen redundantie heeft dan kan zfs ook geen data automatisch repareren.

Tsja, maar is er wel iets stuk? Want "errors: No known data errors". Die read error counter is een ding, maar kan ook een eenmalige failure zijn waarbij een tweede lees actie (/retry) succesvol was. Maar de "One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected." stelt dus iets heel anders, en dat is dat die dus unrecoverable was. Oftewel: er is geen retry gedaan of die mislukte ook(?).

Nog iets relevants kunnen vinden in logfiles?

code:

sudo dmesg | grep -i nvme
sudo journalctl -k | grep -i nvme

Hmm. Een nieuwe zoektocht geeft nu wel "wat":

Feb 08 17:13:50 server kernel: nvme0n1: I/O Cmd(0x2) @ LBA 780405120, 256 blocks, I/O Error (sct 0x2 / sc 0x81) MORE DNR
Feb 08 17:13:50 server kernel: critical medium error, dev nvme0n1, sector 780405120 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Feb 08 17:13:50 server kernel: 5:185m5:185mzio pool=rpool vdev=/dev/disk/by-id/nvme-Samsung_SSD_980_1TB_...-part2 error=61 type=1 offset=399029501952 size=131072 flags=3145904
Feb 08 17:13:50 server zed[2006708]: eid=705900 class=io pool='rpool' vdev=nvme-Samsung_SSD_980_1TB_...-part2 size=131072 offset=399029501952 priority=4 err=61 flags=0x3000b0 delay=111ms bookmark=28417:33240:0:6101

Maar dit is van 20 minuten voor de mail(s) die ik kreeg v.w.b. de gefaalde scrub en smartd mail. Terwijl er dus wel (ook) iets zed is gelogd.

Overigens heeft journalctl een --grep optie, je hoeft dus niet de boel weer apart door grep te pipen. En als je geen pager wilt (waar pipen voor zorgt) kun je ook --no-pager gebruiken.

[ Voor 7% gewijzigd door RobertMe op 10-02-2026 18:09 ]

[tweaker76]

RobertMe schreef op dinsdag 10 februari 2026 @ 18:05:
Hmm. Een nieuwe zoektocht geeft nu wel "wat":

één specifieke flash‑cel (LBA 780 405 120) kon niet worden gelezen, waardoor zowel de kernel‑driver, ZFS‑kernel‑module als ZED een fout meldden.

Kijk eens of deze sector permanent kapot is:

code:

sudo dd if=/dev/nvme0n1 of=/dev/null bs=512 skip=$((780405120)) count=256

Als dd een I/O‑error geeft, is de sector onherstelbaar. Als het nu slaagt, kan het een glitch geweest zijn. Bekijk ook eens de volledige NVMe‑error‑log:

code:

sudo nvme error-log /dev/nvme0n1

Kijk ook eens of de ssd firmware up to date is.

[RobertMe]

tweaker76 schreef op woensdag 11 februari 2026 @ 00:19:
Kijk eens of deze sector permanent kapot is:

code:

sudo dd if=/dev/nvme0n1 of=/dev/null bs=512 skip=$((780405120)) count=256

Als dd een I/O‑error geeft, is de sector onherstelbaar. Als het nu slaagt, kan het een glitch geweest zijn.

Ik duik hier een later moment even beter in. Maar..., heeft dit nut? HDDs werken al met sector reallocation als een sector stuk is. En SSDs zijn al helemaal dynamisch in de mapping tussen LBAs / "sectoren" en de chips en cellen, i.v.m. wear leveling. Of de sector nu leesbaar is zegt dan eigenlijk dus helemaal niks? Want de firmware kan hem nu mappen naar een andere cel die wel leesbaar is (uiteraard evt gecombineerd met dat die LBA / sector dan opnieuw geschreven zou moeten zijn zodat de data in die LBA weer "leesbaar" is gemaakt). Alleen als die niet gelezen kan worden zegt het dus iets. Als die wél gelezen kan worden kan dat zijn omdat de cel weer gewoon leesbaar is en het een eenmalige fuckup was, maar het kan net zo goed betekenen dat er nieuwe data naar die LBA geschreven is die naar een andere, wel werkende, cel geschreven is.

Bekijk ook eens de volledige NVMe‑error‑log:

code:

sudo nvme error-log /dev/nvme0n1

64 regels, alleen regel 0 is een error. Met exact hetzelfde bericht als wat smartctl ook aangeeft:

.................
 Entry[ 0]
.................
error_count     : 1
sqid            : 2
cmdid           : 0x167
status_field    : 0x6281 (Unrecovered Read Error: The read data could not be recovered from the media)
phase_tag       : 0
parm_err_loc    : 0
lba             : 0x2e8409d8
nsid            : 0x1
vs              : 0
trtype          : 0 (The transport type is not indicated or the error is not transport related)
csi             : 0
opcode          : 0
cs              : 0
trtype_spec_info: 0
log_page_version: 0

Kijk ook eens of de ssd firmware up to date is.

Gezien de SSD al ong 3 jaar perfect draait lijkt me dat niet perse een issue? En voel ik meer voor "if it ain't broken don't fix it. (En ja, er lijkt iets broken te zijn. Maar het zal of een kapotte cel zijn of een random glitch lijkt me. Het voelt niet als een firmware issue dat zich ineens na ~3 jaar manifesteert).

[tweaker76]

Heeft het nut? M.i. is het doel om te achterhalen of je met redelijke zekerheid kan stellen dat de lees fout ‘opgelost’ is, de pool error kan resetten en dit incident kan sluiten. De de dd test kan hierin iets meer duidelijkheid geven: slaagt de test dan is het adres van de defecte cel al omgezet of het was een glitch. Faalt de test dan is het adres nog toegewezen aan een defecte cel. In dit geval zou je met dd kunnen schrijven naar dit adres, het adres zal worden toegekend aan een functionerende cel en de dd lees test kunnen herhalen. Schrijven met dd is destructief en je zal waarschijnlijk je backup moeten raadplegen (pool is niet redundant, overschrijven data zal niet hersteld kunnen worden). Is de dd lees test nu succesvol dan weet je redelijk zeker dat het adres nu aan een correct werkende cel is toegewezen. Verder kan een release note van een eventuele firmware update misschien duidelijkheid geven over mogelijk gelijk gedrag wat jij nu ziet. Je hebt altijd de keus om een evt firmware update toe te passen of juist niet. Ik zou de smart data zeker in de gaten houden.

[ocaj]

tweaker76 schreef op dinsdag 10 februari 2026 @ 17:04:
[...]
indien de pool geen redundantie heeft dan kan zfs ook geen data automatisch repareren.

Hangt er van af. Volgens mij schrijft ZFS veel (alle?) metadata sowieso al dubbel weg, en het staat je natuurlijk vrij om copies=2 te gebruiken. Als het toevallig een error in de metadata is die elders ook nog staat of opnieuw te reconstrueren is, of als je copies=2 gebruikt, dan valt er dus wél wat te repareren, ook als je een enkele schijf en geen mirror of raid gebruikt.