Het grote ZFS topic

[RobertMe]

GioStyle schreef op donderdag 29 augustus 2024 @ 20:22:
Met raid1 ben ik (waarschijnlijk) wel beter beschermd tegen bijvoorbeeld bitrot en ik heb er eigenlijk geen omkijken naar.

ZFS ondersteund tegenwoordig (2.2?) een "corrective receive" als ik mij vergis. Daarmee kun je een bestaand snapshot opnieuw sturen en daarmee "bitrot corrigeren". Zelf de feature overigens niet gebruikt en niet heel erg in verdiept.

Scenario 1: nvme ssd van 4TB met zfs on root plus een losse nvme ssd 4TB die door middel van script/syncoid snapshots kopieert van plek a naar plek b.

Scenario 2: twee nvme ssd's van 4TB in raid1 zfs on root.

Wat zouden jullie doen?

Dit is trouwens slechts één van de backup strategieën, niet de enige.

RAID is geen backup. Ik zou beginnen met de vraag "wil ik de uptime verhogen en doordraaien in het geval van uitval van 1 disk?". Als het antwoord daarop "ja" is dan RAID1 / RAIDZ. Als het antwoord daarop "nee" is zou ik ook neigen naar losse pool en snapshots syncen.

[RobertMe]

Wellicht dat iemand hier het antwoord op deze vraag weet. Maar wat zijn de gevolgen van bv het doen van een "chown" (/rechten wijzigen) op een groot bestand in combinatie met snapshots? Wordt dan alleen een kopieetje getrokken (Copy on Write) van de metadata (/alleen dat deel?) of gaat ie dan doodleuk alles kopiëren? Zeg maar het idee van "stel je hebt 800GB aan bestanden op een 1TB HDD, en je doet voor allemaal de rechten wijzigen, is de disk dan groot genoeg?".

Edit:
En na het versturen bedenk ik mij... dat er natuurlijk meer metadata is, zoals een access time. En na het lezen van een file wordt er ook geen volledig kopietje getrokken. Dus bij het wijzigen van de rechten zal dat ook wel niet het geval zijn

[ Voor 21% gewijzigd door RobertMe op 30-08-2024 14:41 ]

[FireDrunk]

Copy-on-write gaat over de bits die veranderd zijn, niet de hele file.
Snapshot logica is zich niet (echt) bewust van het filesystem erbovenop

Je conclusie klopt

[willemw12]

Copy-on-write creëert alleen nieuwe data blokken, en misschien ook metadata blokken, die gewijzigd zijn, niet alle blokken van een bestand.

[ Voor 202% gewijzigd door willemw12 op 30-08-2024 14:52 ]

[RobertMe]

FireDrunk schreef op vrijdag 30 augustus 2024 @ 14:33:
Copy-on-write gaat over de bits die veranderd zijn, niet de hele file.

Ik neem aan block size / record size / .... Per bits zou anders wel heel veel administratie kosten

Maar helder. Een chown heeft geen enorme invloed op de benodigde diskspace.

* RobertMe gaat zich maar eens beraden om de Proxmox bak die intussen puur NAS is om te toveren tot NAS. (lees: reinstall met Debian, en de RAIDZ pool daar weer aan hangen, met dan benodigde "chowns" om rechten op orde te krijgen omdat files nu veelal "hoge uids / gids" hebben doordat ze vanuit een LXC zijn aangemaakt en die dus een ander id space hebben).

[FireDrunk]

RobertMe schreef op vrijdag 30 augustus 2024 @ 14:47:
[...]

Ik neem aan block size / record size / .... Per bits zou anders wel heel veel administratie kosten

Maar helder. Een chown heeft geen enorme invloed op de benodigde diskspace.

* RobertMe gaat zich maar eens beraden om de Proxmox bak die intussen puur NAS is om te toveren tot NAS. (lees: reinstall met Debian, en de RAIDZ pool daar weer aan hangen, met dan benodigde "chowns" om rechten op orde te krijgen omdat files nu veelal "hoge uids / gids" hebben doordat ze vanuit een LXC zijn aangemaakt en die dus een ander id space hebben).

Dat soort acties (chowns, chmod etc) kosten idd geen ruimte.

Over je users: met die reden heb ik een Ansible playbook waarmee ik alle interne users aanmaak met vaste UID's.
Dat maakt een herinstallatie een stuk makkelijker.

1. Install OS.
2. Draai ansible.
3. Importeer ZFS pool.
4. Draai een docker stack deploy vanaf mijn Projects directory op mijn pool.
5. Gas op die lollie

[RobertMe]

FireDrunk schreef op vrijdag 30 augustus 2024 @ 14:50:
Over je users: met die reden heb ik een Ansible playbook waarmee ik alle interne users aanmaak met vaste UID's.
Dat maakt een herinstallatie een stuk makkelijker.

1. Install OS.
2. Draai ansible.
3. Importeer ZFS pool.
4. Draai een docker stack deploy vanaf mijn Projects directory op mijn pool.
5. Gas op die lollie

Dat is niet perse het probleem. Het probleem is de id mapping. In de LXC container is root wel user 0. Maar files in de LXC aangemaakt door root zijn op de host "in werkelijkheid" aangemaakt door zeg user 1.000.000, en user 1.000 in de LXC container is dan dus 1.001.000. Als ik LXC "weg haal" moet ik dus allemaal die uids/gids aanpassen zodat ze op de host correct 0 en 1.000 zijn.

[RobertMe]

Terugkomende op mijn avontuur met de performance van ZFS op een N5105 systeem (/CPU zonder AVX support) met encrypted datasets:

RobertMe schreef op vrijdag 16 augustus 2024 @ 22:39:

Op de N5105 komt echter helemaal naar boven (er staan nog 2 ZFS methods boven de aes_* methods) de gcm_pclmulqdq_mul method. En daarop Googlen DuckDuckGo-en leidt naar deze PR: https://github.com/openzfs/zfs/pull/14531 (die helaas al lange tijd erg stil is). Blijkbaar kan ZFS gebruik maken van de AVX instructieset v.w.b het afhandelen van de encryptie. Alleen... is AVX niet altijd aanwezig, en dus (ook) niet op de N5105, maar wel op de i3 9100. Deze PR voegt vervolgens support toe voor SSE4.1 en levert ook een forse performance boost op afgaande op basis van de reacties. Alleen, is de PR dus al voor lange tijd erg stil, zeg maar PR is ingediend eind februari '23, en de laatste actie van de dev is maart '23.

RobertMe schreef op zondag 18 augustus 2024 @ 16:00:
Nu nog even denken of ik mijn twee systemen met de N5105 ga "patchen" met de pull request voor SSE 4.1 ondersteuning. Snelheid zou daarmee om en nabij gelijk zijn aan de AVX gebaseerde implementatie. Maar uiteraard wel met "risico" dat de PR buggy is. En dat laatste ben ik uiteraard wat huiverig voor. Maar, kijkende naar de PR is er op zijn minst 1 iemand die sinds november deze code al draait op zijn "productie" systeem (wat vast ook een DIY NAS achtig systeem is).

~1,5e week terug op een ouder systeem (6th gen Intel i5, laptop) wat geëxperimenteerd met die PR. Uiteraard voornamelijk wat "random" stuff gedaan op de sse4.1 implementatie, maar ook een beetje vergeleken met de AVX implementatie en de pclmulqdq (whatever that might be ) implementatie. Was echt een verschil van dag en nacht. De pclmulqdq variant haalde maar ~130MB/s, terwijl zowel de AVX als SSE4.1 implementatie over de 500MB/s gingen (meen rond de 550MB/s). Verschil tussen AVX en SSE4.1 was ook maar marginaal, minder dan 10MB/s. Wat mij eerder binnen de foutmarge lijkt te vallen.

Vervolgens op het "doosje" met minder belangrijke, maar wel encrypted, data maar eens ZFS 2.2.5 geïnstalleerd (Debian Bookworm bevat 2.1.11, 2.2.5 staat in backports). Dit omdat de PR alleen op 2.2 toe te passen was (of anders gezegd, niet te applyen was op 2.1.11, anders had ik dat wel gedaan). Dat heb ik vervolgens een weekje laten "rammelen" en gaf geen problemen (ging ook niet vanuit, maar just to be sure). Vervolgens vanmorgen de build met die PR er op gezet, en het werkt nog . Performance winst valt me wat tegen, ~150MB/s => 260MB/s. Maar dit blijkt een andere oorzaak te hebben, dezelfde test op een niet encrypted dataset haalt namelijk ook maar om en nabij dezelfde snelheid (~290MB/s max).

Vraag ik mij alleen af waar dat vandaan komt. Met een hdparm -t /dev/sda (of nvme0n1) haal ik wel een veel hogere snelheid, van resp. ~500MB/s en 1000MB/s. Dus het lijkt mij niet dat de fysieke link (SATA / NVME) de beperking is. Maar ik heb zo'n vermoeden dat hdparm -t heel wat zaken omzeilt (als in: doet sowieso al niks met filesystem, maar zal vast ook gewoon van het block device lezen zonder uberhaupt al te veel interactie met enige "storage" interface te hebben vermoed ik).

Edit:
Voor de duidelijkheid: die ~290MB/s leessnelheid voor de unencrypted dataset (en ~260MB/s voor aes-256-gcm encrypted dataset) is naar de SATA disk, wat een SSD is, waarvan hdparm -t aangeeft dat de ruwe snelheid wel "iets" hoger ligt (~dubbele op 500MB/s).

Nu ook even getest naar de NVME schrijf (unencrypted dataset): en uhm, hetzelfde, ~290MB/s Dus de veel snellere interface levert geen hogere snelheden op blijkbaar.

Edit2:
Hmm, misschien meet ik ook verkeerd. Lekker lomp een 4GB file aanmaken met dd if=/dev/urandom of=test.img bs=1k count=4M en daarna lezen met dd if=test.img of=/dev/null bs=1k met dus deze resultaten. Vervolgens doe ik nu "hetzelfde" met bs=4k en haal ik op de NVME disk "ineens" ~760MB/s. Lijkt dus dat ZFS een stuk efficiënter is met 4K lees acties. Les voor de volgende keer dus: netjes fio gebruiken

[ Voor 11% gewijzigd door RobertMe op 31-08-2024 07:38 ]

[ph0t0nix]

Een block size van 1k is ook echt een doemscenario voor I/O. Kijk maar eens naar de resultaten voor 4k vs. 1MB in de SSD reviews hier op tweakers.net.

[RobertMe]

ph0t0nix schreef op zaterdag 31 augustus 2024 @ 15:37:
Een block size van 1k is ook echt een doemscenario voor I/O. Kijk maar eens naar de resultaten voor 4k vs. 1MB in de SSD reviews hier op tweakers.net.

Yeah, 4k was al veel beter, nog meer opschroeven (naar dus xMB) levert nog meer performance op. Vandaag nog wat geprutst en blijft dan toch complexe materie en wat onvoorspelbaar (vast ook dat met schrijven testen er nogal veel variabelen zijn met SLC cache naar TLC, twee runs achter elkaar die compleet anders zijn, ...).

offtopic:
Wat ook nog een leuke ontdekking was was dat de NVME drive niet op full beans draait. "LinkSta" is wel 8GT/s maar maar op 2x. Waardoor bv ook een hdparm -t blijft steken op ~1,Gbit/s, terwijl de Tweakers review op ~2Gbit/s uit komt.

Belangrijkste is in ieder geval dat de SSE implementatie voor GCM het encryptie gebeuren een heeel stuk sneller maakt. Nu kan ik eens gaan nadenken over een 2,5Gbit/s setup. Tussen router (die ook download), NAS (met "permanente" opslag) en "mini servertje" (met "cache" voor als NAS uit staat). Router is een TopTon systeem, met N5105, met 4x 2,5Gbit/s dus okay(ish, tenzij ik naar 10Gbit/s wil gaat ). NAS is het Proxmox systeem dat begon als server, daar zit een Fujitsi bord in met i3 9100 dus moet ik een "netwerk upgrade" op doen voor 2,5Gbit/s of 10Gbit/s. Servertje is ook een mini PCtje met N5105, maar maar 1Gbit/s en zou dan een USB adapter aan moeten (waarmee 10Gbit/s eigenlijk is uitgesloten. Weet niet eens of die 10Gbit/s zou kunnen halen, laat staan of je 10Gbit/s over ethernet moet willen / of SFP+ kan).
Alhoewel ik ook met het idee speel om laatste te vervangen. Gesoldeerd RAM, "komt alleen Home Assistant op dus 8GB is voldoende", intussen staat " alles" er op en is 8GB een issue. En wat andere dingetjes v.w.b. beperkingen (geen AVX instructieset bv dus ). Router boeit me niet zo om experimentele ZFS te draaien zolang alleen encrypted dataset kan sneuvelen. Servertje staan ook backups op van PCs dus wil ik toch wat meer supported hebben.
/rant

[FireDrunk]

ph0t0nix schreef op zaterdag 31 augustus 2024 @ 15:37:
Een block size van 1k is ook echt een doemscenario voor I/O. Kijk maar eens naar de resultaten voor 4k vs. 1MB in de SSD reviews hier op tweakers.net.

En toch is de grap dat de gemiddelde machine echt amper I/O's van meer dan een paar KB voor zijn kiezen krijgt. Ik zit tijdens een download eens te kijken met `blktrace`, maar de allergrootste IO die ik *heel* af en toe lang zie komen is 2000 blocks.

De meeste requests zijn 8,16 of soms 64 blocks groot, af en toe een 100+ request, maar meer eigenlijk niet.
Dat gaat daarna dus maal je sector size (in het geval van disks vaak 512bytes), ssd's mogelijk wat vaker 4k.

En dan doet deze pool in mijn systeem op dit moment dus uitsluitend sequentieel werk en staan ZFS Sync writes uit voor bijna alle filesystems. De ideale workload voor grote I/O's dus.

Uit de summary:

553MB gelezen dmv 17313 IO's = ~32k io size
3262MB geschreven dmv 9735 IO/s = ~300k io size

Valt me niet eens heel erg tegen.

Mijn ZFS Recordsize is overigens 128k, dat zou eigenlijk wel op 1MB mogen.

[ Voor 10% gewijzigd door FireDrunk op 01-09-2024 13:25 ]

[RobertMe]

Wellicht offtopic, wellicht niet, zullen we wel zien

Nu ik wat met lees- & schrijfsnelheden etc bezig was ook de smart data van mijn disks bekeken. En nu blijkt dus dat 1 van mijn drives op ~1,5 jaar 55TB aan data geschreven heeft, wat ik best fors vind. En intussen blijkt dat deze ook elke dag met (minimaal?) 100G oploopt (als in: 55.xTB waarbij x elke dag (minimaal?) 1 oploopt). Alleen... wordt er vrij constant maar een 300GB aan opslag gebruikt. En ik heb ook niet het idee dat er zoveel data geschreven wordt. Sure, er draaien "wat databases" (voornamelijk voor Home Assistant en aanverwanten). Maar met een zpool iostat rpool 1 zie ik continue een aantal K (byte/s? bit/s?) met soms "uitschieters" van 2, 3, 4M. Dat lijkt mij nu niet zo spectaculair? (om bij elkaar op 100GB uit te komen). Er worden wel snapshots gemaakt (en weer opgeruimd uiteraard), maar ook dat lijkt mij niet direct zo schokkend op het aantal writes/... die gedaan worden? En backups die dit systeem ook binnen haalt worden niet naar de rpool geschreven. Dus het is ook niet dat er periodiek gigabytes aan data worden binnengehaald (en tegelijkertijd oude snapshots verwijderd en daardoor geen toename in gebruik).

Intussen ook eens iotop geinstalleerd en bekeken. En enige wat mij daaraan opvalt is dat er ogenschijnlijk continue wat IO is van, waarschijnlijk s6-log in deze Docker container (met DSMR Reader). Maar kijkende naar de docs doet die alleen iets met stdin naar een output schrijven en uiteindleijk zie ik nergens files waar die naartoe schrijft (o.a. op basis van lsof -p <pid van een zo'n log proces>).

Als ik docker tijdelijk volledig stop (als in systemctl stop docker.service) dan zakt zpool iostat rpool 1 ook naar 0 writes en blijft daar ook vrij constant op. Maar dat verbaasd mij niet heel veel gezien ik "alles" in Docker heb draaien en dit dus een groter aantal processen stopt waaronder dus meerdere databases en soorten databases. Maar ik kan/wil dit niet voor uren doen, dus ik kan niet even een dagje docker stoppen en kijken of er dan nog steeds ~100GB per dag geschreven wordt.

Wat ik nu als absolute hack even heb geprobeerd is een bash scriptje in tmux draaien om zpool iostat rpool 1 continue te draaien en naar een file (op de andere pool ) te schrijven. Zodat ik kan pogen te achterhalen of er periodiek (/eens in de zoveel uur / eens per dag / ...) niet alsnog ergens iets is dat veel doet schrijven achter elkaar.
Het "scriptje" daarbij is gewoon lekker lomp:

while true
do
  date >> /tank/iostat.txt
  zpool iostat rpool 1 1800 >> /tank/iostat.txt
done

Waarbij ik dus iostat elke seconde, 1800x, laat outputten naar het bestand en dan vooraf even de (datum &) tijd naar de file laat schrijven zodat ik een grof idee heb waarbij de output hoort (en dat dan oneindig herhalen).

Edit:
Misschien moet ik ook een vraag stellen
Zijn er handigere manier om zoiets te achterhalen? 100GB lijkt mij voor mijn "use case" ook niet normaal. Tenzij anderen aangeven nog veel meer te schrijven op een systeem dat niet continu (veel) IO genereert. (als in: ik kan mij niet indenken dat dit veroorzaakt wordt door primair Home Assistant die data naar InfluxDB & Postgresql schrijft, zeker niet op basis van de "elke 5 - 10 seconden wordt er 2/3/4M geschreven en daartussen minder dan 1M", terwijl voor 100GB per 24 uur er elk uur 4GB geschreven moet worden). Maar ik laat mij ook graag uit mijn droom helpen als 100GB per ~24 uur wel normaal is

Edit2:
Hmm, misschien is het wel "normaal". Dit is in mijn mini PCtje / serverjte. In 2020 heb ik een Proxmox bak opgezet waar deze services op draaide. De "originele" NVME SSD heeft momenteel 93TB geschreven, en dat is sinds ~zomer 2020. Eind 2021 heb ik er nog een NVME SSD bij gezet, in mirror, en deze heeft 50TB geschreven. Waarbij de Proxmox bak sinds begin / halverwege 2023 grotendeels "uit dienst" is (1. services draaien er niet meer op. 2. staat veel uit). Dus de een heeft dan op ~1,5 jaar 24/7 draaien + ~1,5 jaar "incidenteel" draaien (+ minder services) 50TB aan data geschreven en de ander op ~1,5 jaar 55TB. En dat is dan inclusief dat er nu meer services draaien en bv een SyncThing die ik gebruik voor "backups" van PC op de Proxmox bak naar een HDD pool schreef en niet naar de rpool mirror, en in dit nieuwe systeem wel naar de rpool schrijft. Dus dat deze ("iets") meer data schrijft is wel te verwachten.

[ Voor 21% gewijzigd door RobertMe op 06-09-2024 21:57 ]

[GioStyle]

@RobertMe

Sinds begin april heb ik een nieuwe nvme ssd van 4TB in mijn servertje. Hierop draait Debian met Docker.

Smartctl geeft aan:

code:

Data Units Read:                    27,974,288 [14.3 TB]
Data Units Written:                 38,922,880 [19.9 TB]

Iedereen draait natuurlijk andere containers. Wat ik heb gedaan is zoveel mogelijk logs uit te zetten in bijvoorbeeld Home Assistant en waar mogelijk 'health checks' uit te schakelen. Maar is het trouwens erg? Elke nvme ssd die ik in mijn handen heb gehad is inmiddels alweer vervangen door een andere exemplaar. Ik heb een ssd die ik puur gebruik om mee te downloaden en na 150TB staat de gezondheid nog op 77%. Zelfs die ssd gaat nog jaren mee.

[RobertMe]

@GioStyle, erg niet perse. Ik dacht alleen dat het nogal veel was, niet perse in relatie met levensduur, maar uberhaupt. Maar lijkt dan toch enigszins te kloppen als ik het beredeneer. (en jij schrijft nog meer )

[XiMMiX]

@RobertMe lsof -p <PID> is een moment opname en laat geloof ik ook alleen de files die het betreffende PID open heeft zien, niet van child processen.
Je zou strace kunnen proberen om te zien welke syscalls een proces doet

bv: strace -f -e trace=file -p <PID>

-f zorgt ervoor dat ook syscalls van child process getoond worden
-e trace=file betekent een filter voor alleen filesystem syscalls.

Wat die 100G per dag betreft. Dat is ook ongeveer wat mijn proxmox machine tegenwoordig doet (ongeveer 30 LXC containers + 2 VMs) op zfs mirror (2 SSDs). Ik vind het ook veel, maar ik vind het niet genoeg om tijd te spenderen aan het zoeken waar het aan ligt. (Ik heb in 2020 door wat problemen met elasticsearch en daarna timescaledb in 6 maanden tijd onbedoeld 600TB geschreven naar een SSD, dus 100G per dag ben ik niet ontevreden mee.)

[Habana]

Vandaag een oud servertje/nas (ITX met een i5-3470 cpu) nog met ZFSGuru erop uit de kast gehaald, vijf HDD’s a 2TB die erin zaten deden het nog, bijna als nieuw 12jaar vers, alle Data nog aanwezig ook.
Opnieuw in gebruik genomen met TrueNas scale, kleine SSD erin en Import Pool gedaan, en alles kwam weer tot leven, Scrub Scan 0 Errors,
Zat wel even een uurtje te klooien met de mappen om die zichtbaar te maken in PopOs, zucht? even mijn pc opnieuw booten en alles werd zichtbaar, moet je maar weten als leek.. haha..
Al met al toch een leuke middag..

ps: kunnen die HDD’s in Truenas ook in Spindown?

Gevonden denk ik: Storage / Disk Health / manage Disk / Disk edit / HDD Standby? = Always On

In HDD standby en Advanced Power Management wat zijn de juiste/beste instelling voor Spindown in deze? Advies graag...

Spindown bespaard in mijn geval maar 18Watt van de 50Watt, niet echt de moeite.. maar geheel uitzetten en aanzetten als het nodig is,

[ Voor 6% gewijzigd door Habana op 25-10-2024 22:59 ]

[Ravefiend]

Hier na al die jaren nog steeds TrueNAS Core op mijn home server omdat ik ook zo'n fan ben van ZFS, maar wanneer migreer ik dan toch beter over naar TrueNAS Scale? 🙃

[orvintax]

Habana schreef op donderdag 24 oktober 2024 @ 00:05:
Vandaag een oud servertje/nas (ITX met een i5-3470 cpu) nog met ZFSGuru erop uit de kast gehaald, vijf HDD’s a 2TB die erin zaten deden het nog, bijna als nieuw 12jaar vers, alle Data nog aanwezig ook.
Opnieuw in gebruik genomen met TrueNas scale, kleine SSD erin en Import Pool gedaan, en alles kwam weer tot leven, Scrub Scan 0 Errors,
Zat wel even een uurtje te klooien met de mappen om die zichtbaar te maken in PopOs, zucht? even mijn pc opnieuw booten en alles werd zichtbaar, moet je maar weten als leek.. haha..
Al met al toch een leuke middag..

ps: kunnen die HDD’s in Truenas ook in Spindown?

Gevonden denk ik: Storage / Disk Health / manage Disk / Disk edit / HDD Standby? = Always On

In HDD standby en Advanced Power Management wat zijn de juiste/beste instelling voor Spindown in deze? Advies graag...

Je hebt het inderdaad goed gevonden. Wat de juiste/beste instellingen hiervoor zijn is volledig afhankelijk van jouw usecase en wensen. Weet wel (als ik me niet vergis) dat je disks sequentieel opstarten. Ze beginnen dus niet allemaal tegelijk te draaien als je iets nodig hebt. Daarnaast wil je ook niet dat ze te vaak aan/uit gaan want dat is het stukje waarbij de meeste disks kapot gaan. Wederom als ik me niet vergis.

[orvintax]

Ravefiend schreef op donderdag 24 oktober 2024 @ 09:09:
Hier na al die jaren nog steeds TrueNAS Core op mijn home server omdat ik ook zo'n fan ben van ZFS, maar wanneer migreer ik dan toch beter over naar TrueNAS Scale? 🙃

Als je TrueNAS voornamelijk voor storage gebruikt kun je denk ik net zo goed blijven op Core, dan heeft Scale in mijn ogen niet veel meerwaarde. IXSystems heeft gezegt dat ze het nog blijven ondersteunen.

[GioStyle]

orvintax schreef op vrijdag 25 oktober 2024 @ 15:32:
[...]

Als je TrueNAS voornamelijk voor storage gebruikt kun je denk ik net zo goed blijven op Core, dan heeft Scale in mijn ogen niet veel meerwaarde. IXSystems heeft gezegt dat ze het nog blijven ondersteunen.

Scale is in het algemeen zuiniger en zuiniger te krijgen, omdat Scale gebaseerd is op Linux. Core is volgens mij gebaseerd op FreeBSD.

[Habana]

orvintax schreef op vrijdag 25 oktober 2024 @ 15:28:
[...]

Je hebt het inderdaad goed gevonden. Wat de juiste/beste instellingen hiervoor zijn is volledig afhankelijk van jouw usecase en wensen. Weet wel (als ik me niet vergis) dat je disks sequentieel opstarten. Ze beginnen dus niet allemaal tegelijk te draaien als je iets nodig hebt. Daarnaast wil je ook niet dat ze te vaak aan/uit gaan want dat is het stukje waarbij de meeste disks kapot gaan. Wederom als ik me niet vergis.

Wel een beetje zitten spelen met Spindown, totaal verbruik is 50Watt en 18Watt minder met Spindown en die oude i5-3470 en 5x HDD’s, niet de zuinigste combo denk ik.

S.M.A.R.T moet dan wel uitgeschakeld worden anders werkt het niet, omdat die de schijven regelmatig blijft aanroepen dus Spindown werkt dan niet.

Deze Nass is maar bijzaak voor mij dus gaat hij uit en als ik hem nodig heb zet ik hem wel aan.
Maar moet zeggen TrueNas Scale zie er prima uit en werkt goed lekker overzichtelijk en niet al te moeilijk om er in thuis te geraken.

[willemw12]

Er is een smartd.conf "-n POWERMODE" (nocheck) configuratie optie waarmee je spin-ups veroorzaakt door smartd kan voorkomen of reduceren, bijv. configuratie regel: "DEVICESCAN -a -n standby,q ...".

[vanaalten]

Vandaag has ik spontaan de behoefte om een file (/etc/passwd) in een snapshot te bekijken, maar:

code:

# cd /.zfs/snapshot/zfs-auto-snap_monthly-2024-01-01-0552/
bash: cd: /.zfs/snapshot/zfs-auto-snap_monthly-2024-01-01-0552/: Too many levels of symbolic links

Met wat google lijkt dit probleem een bekend iets te zijn, met een workaround: de snapshot mounten.

Daar begon de frustratie dus. Want, als ik eerlijk ben, snap ik niet goed wat ik heb opgezet en hoe ik nu precies die snapshot kan mounten.

Achtergrond: ZFS-on root. Debian 'stable' machine, tijd geleden opgezet d.m.v. wat HowTo's die ik van internet geplukt heb. ZFS versie: 2.1.11-1

Als ik een overzicht van het ZFS filesystem opvraag, exclusief alles met een legacy mountpoint (voornamelijk docker-dingen):

code:

 # zfs list | grep -v legacy
NAME                                                                                         USED  AVAIL     REFER  MOUNTPOINT
bpool                                                                                        256M   575M       96K  /boot
bpool/BOOT                                                                                   254M   575M       96K  none
bpool/BOOT/debian                                                                            253M   575M      135M  /boot
rpool                                                                                        899G   899G      192K  /
rpool/ROOT                                                                                  62.7G   899G      192K  none
rpool/ROOT/debian                                                                           62.7G   899G     14.4G  /
rpool/home                                                                                   701G   899G      228G  /home
rpool/home/root                                                                             45.8G   899G     29.2G  /root
rpool/home/sabnzbd                                                                           390G   899G      334G  /home/sabnzbd
rpool/opt                                                                                   8.95G   899G     1.15G  /opt
rpool/swap                                                                                  4.25G   903G      108K  -
rpool/tmp                                                                                    696K   899G      696K  /tmp
rpool/var                                                                                    121G   899G      192K  /var
rpool/var/cache                                                                             89.8G   899G     89.8G  /var/cache
rpool/var/lib                                                                               14.2G   899G      192K  /var/lib
rpool/var/lib/docker                                                                        14.2G   899G     66.5M  /var/lib/docker
rpool/var/lib/nfs                                                                            356K   899G      356K  /var/lib/nfs
rpool/var/log                                                                               16.9G   899G     1.81G  /var/log
rpool/var/spool                                                                             75.8M   899G     5.04M  /var/spool
rpool/var/tmp                                                                               45.9M   899G     45.9M  /var/tmp

...dan snap ik vooral het begin niet: zowel bpool als bpool/BOOT/debian hebben /boot als mountpoint /boot; zowel rpool als rpool/ROOT/debian hebben / als mountpoint. Hoe zit dat?

Als ik het met trial&error probeer, dan lijkt:

code:

mount -t zfs rpool@zfs-auto-snap_monthly-2024-01-01-0552 /mnt/zfs

het juiste commando te zijn, maar zou het ook graag snappen. Ook waarom ik die hele subdirectory van /rpool/ROOT en /rpool/ROOT/debian heb gemaakt, dat ziet er op het oog nutteloos uit.

(en een volgend punt is dat die snapshot dan weer leeg lijkt te zijn... )

[FireDrunk]

vanaalten schreef op maandag 11 november 2024 @ 13:35:
Vandaag has ik spontaan de behoefte om een file (/etc/passwd) in een snapshot te bekijken, maar:

code:

# cd /.zfs/snapshot/zfs-auto-snap_monthly-2024-01-01-0552/
bash: cd: /.zfs/snapshot/zfs-auto-snap_monthly-2024-01-01-0552/: Too many levels of symbolic links

Met wat google lijkt dit probleem een bekend iets te zijn, met een workaround: de snapshot mounten.

Daar begon de frustratie dus. Want, als ik eerlijk ben, snap ik niet goed wat ik heb opgezet en hoe ik nu precies die snapshot kan mounten.

Achtergrond: ZFS-on root. Debian 'stable' machine, tijd geleden opgezet d.m.v. wat HowTo's die ik van internet geplukt heb. ZFS versie: 2.1.11-1

Als ik een overzicht van het ZFS filesystem opvraag, exclusief alles met een legacy mountpoint (voornamelijk docker-dingen):

code:

 # zfs list | grep -v legacy
NAME                                                                                         USED  AVAIL     REFER  MOUNTPOINT
bpool                                                                                        256M   575M       96K  /boot
bpool/BOOT                                                                                   254M   575M       96K  none
bpool/BOOT/debian                                                                            253M   575M      135M  /boot
rpool                                                                                        899G   899G      192K  /
rpool/ROOT                                                                                  62.7G   899G      192K  none
rpool/ROOT/debian                                                                           62.7G   899G     14.4G  /
rpool/home                                                                                   701G   899G      228G  /home
rpool/home/root                                                                             45.8G   899G     29.2G  /root
rpool/home/sabnzbd                                                                           390G   899G      334G  /home/sabnzbd
rpool/opt                                                                                   8.95G   899G     1.15G  /opt
rpool/swap                                                                                  4.25G   903G      108K  -
rpool/tmp                                                                                    696K   899G      696K  /tmp
rpool/var                                                                                    121G   899G      192K  /var
rpool/var/cache                                                                             89.8G   899G     89.8G  /var/cache
rpool/var/lib                                                                               14.2G   899G      192K  /var/lib
rpool/var/lib/docker                                                                        14.2G   899G     66.5M  /var/lib/docker
rpool/var/lib/nfs                                                                            356K   899G      356K  /var/lib/nfs
rpool/var/log                                                                               16.9G   899G     1.81G  /var/log
rpool/var/spool                                                                             75.8M   899G     5.04M  /var/spool
rpool/var/tmp                                                                               45.9M   899G     45.9M  /var/tmp

...dan snap ik vooral het begin niet: zowel bpool als bpool/BOOT/debian hebben /boot als mountpoint /boot; zowel rpool als rpool/ROOT/debian hebben / als mountpoint. Hoe zit dat?

Als ik het met trial&error probeer, dan lijkt:

code:

mount -t zfs rpool@zfs-auto-snap_monthly-2024-01-01-0552 /mnt/zfs

het juiste commando te zijn, maar zou het ook graag snappen. Ook waarom ik die hele subdirectory van /rpool/ROOT en /rpool/ROOT/debian heb gemaakt, dat ziet er op het oog nutteloos uit.

(en een volgend punt is dat die snapshot dan weer leeg lijkt te zijn... )

Meerdere filesystems kunnen hetzelfde mountpoint hebben. Alleen kunnen ze dan niet tegelijk actief zijn, want dan mount je ze over elkaar heen.

In theorie kan je dingen over elkaar heen mounten in linux, maar dat is echt vragen om problemen

Die directories onder het pad van snapshots worden volgens mij vrij snel automatisch gemaakt door ZFS, ookal wordt er nooit wat gemaakt omdat het legacy mountpoints bevat.

[RobertMe]

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

Mijn idee nu is:

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

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

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

[willemw12]

Laatste nog gedaan "zpool detach POOL_NAME DEVICE_NAME" van een mirror. Een "zpool status" gaf daarna nog steeds geen enkele fout weer.

Met een "zpool status" kun je de POOL_NAME en DEVICE_NAME namen vinden in de "NAME" kolom. Bij mij kon ik de namen zelfs invullen m.b.v. tab-completion.

[ Voor 27% gewijzigd door willemw12 op 26-11-2024 20:18 ]

[RobertMe]

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

Mijn idee nu is:

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

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

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

Tegen mijn verwachting in werd ondanks de USB dock de SSD ook herkent middels een ata-WD..... Via die route geattached, resilver laten lopen, vervolgens de oude gedetached en nog een zpool online -e tank ata-WD... om gebruik te maken van de extra ruimte en dat was het in zoverre. Lees: afsluiten, SSD wisselen, opstarten en klaar. Export => import was dis niet nodig doordat de disk al herkend werd op basis van een id dat niet zou veranderen tussen de USB dock vs direct aan SATA.
Enige "verrassing" was dat die niet automatisch deed expanden, en een zpool set autoexpand=on tank dat ook niet oploste (maar een zpool online -e tank ata-WD-... dus wel).

[Snow_King]

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

Mijn idee nu is:

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

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

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

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

[RobertMe]

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

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

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

[Snow_King]

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

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

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

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

[menn0]

Zfs NAS en pool stonden uit.

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

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

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

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

[FireDrunk]

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

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

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

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

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

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

[RobertMe]

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

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

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

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

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

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

[Habana]

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

[Mystic Spirit]

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

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

de output van is lsblk is:

code:

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

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

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

[GioStyle]

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

code:

zpool get autoexpand

Autoexpand aanzetten:

code:

zpool set autoexpand=on pool

[Mystic Spirit]

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

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

[ph0t0nix]

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

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

[Mystic Spirit]

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

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

[GorgeousMetal]

Software-update: OpenZFS 2.3.0

[jimmy87]

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

[FireDrunk]

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

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

[RobertMe]

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

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

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

[vanaalten]

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

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

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

[FireDrunk]

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

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

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

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

[nero355]

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

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

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

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

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

[FireDrunk]

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

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

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

Het wisselt.

[RobertMe]

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

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

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

[nero355]

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

Komt iemand dit toevallig bekend voor?

Brainfart :

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


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

[RobertMe]

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

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

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

[RobertMe]

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

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

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

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

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

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

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

[orvintax]

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

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

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

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

[RobertMe]

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

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

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

[orvintax]

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

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

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

[nero355]

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

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

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

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

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

Echt irritant dat soort dingen

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

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

[RobertMe]

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

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

Iemand hier dus toevallig ervaring met een dergelijke opzet?

[nero355]

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

Iemand hier dus toevallig ervaring met een dergelijke opzet?

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

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

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

[RobertMe]

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

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

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

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

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

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

---

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

[dcm360]

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

[RobertMe]

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

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

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

[nero355]

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

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

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

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

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

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

Denk ik...

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

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

[RobertMe]

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

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

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

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

[silverball]

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

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

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

[RobertMe]

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

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

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

[pimlie]

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

[silverball]

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

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

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

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

[pimlie]

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

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

[silverball]

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

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

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

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

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

[d3vlin]

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

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

[pimlie]

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

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

[d3vlin]

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

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

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

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

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

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

[FireDrunk]

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

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

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

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

[silverball]

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

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

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

[RobertMe]

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

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

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

[silverball]

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

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

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

[pimlie]

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

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

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

[Uberprutser]

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

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

[Mars Warrior]

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

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

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

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

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

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

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

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

[dylan111111]

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

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

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

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

[pimlie]

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

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

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

[HyperBart]

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

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

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

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

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

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

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

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

[pimlie]

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

[Uberprutser]

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


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

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

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

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

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

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

[dcm360]

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

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

[Mars Warrior]

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

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

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

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

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

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

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

[dcm360]

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

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

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

[Mars Warrior]

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

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

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

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

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

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

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

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

[dcm360]

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

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

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

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

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

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

[Mars Warrior]

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

Aha!

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

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

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

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

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

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

[Uberprutser]

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

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

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

[sOid]

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

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

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

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

Graag advies

[d3vlin]

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

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

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

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

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

[orvintax]

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

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

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

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

Graag advies

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

[HyperBart]

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

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

Ik vind dat altijd enorm confronterend

[d3vlin]

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

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

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

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

[RobertMe]

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

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

[dcm360]

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

[RobertMe]

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

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

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

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

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

[dcm360]

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

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

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

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

[RobertMe]

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

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

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

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

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

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