Het grote ZFS topic

[nero355]

jurroen schreef op donderdag 20 juni 2024 @ 00:28:
De usenet storage van de ISP met gele accenten (die er niet meer is) draaide alleen met die Exos / Seagate DC disks zonder noemenswaardige issues.

En ik heb gewerkt in een grote Datacenter omgeving waar ik ze regelmatig eruit zag vliegen bij meerdere klanten

Later ging bijna iedereen aan de Hitachi/Toshiba HDD's en ineens was er veeeel minder uitval in zowel Hardware RAID als OpenZFS opstellingen

[The-Source]

e-unlimited schreef op woensdag 19 juni 2024 @ 19:06:
[...]


Tip: kijk of je je disks naar 4K native kunt herformatteren.

https://www.truenas.com/c...512e-vs-4kn-drives.42082/

Het betreffen 512e Disks en zou wel als 4kn geformateerd kunnen worden.
Bedankt voor de tip. die ga ik wel meenemen wanneer de disken ga plaatsen.

[jurroen]

nero355 schreef op donderdag 20 juni 2024 @ 15:51:
[...]

En ik heb gewerkt in een grote Datacenter omgeving waar ik ze regelmatig eruit zag vliegen bij meerdere klanten

Later ging bijna iedereen aan de Hitachi/Toshiba HDD's en ineens was er veeeel minder uitval in zowel Hardware RAID als OpenZFS opstellingen

Maf hoe dat kan gaan. Ik heb er zelf 24 in gebruik in mijn homelab (cq home datacenter) - SAS variant. dingen presteren goed en betrouwbaar. Heb tien cold spares liggen, mochten de ZFS pools issues geven heb ik ze zo vervangen

Per 24 uur komt er zo'n 3,5TB binnen. Is puur backups (tertiaire locatie).

[Raven]

nero355 schreef op donderdag 20 juni 2024 @ 15:51:
[...]

En ik heb gewerkt in een grote Datacenter omgeving waar ik ze regelmatig eruit zag vliegen bij meerdere klanten

Specifieke batches? Of is daar geen onderzoek naar gedaan?

[nero355]

Raven schreef op donderdag 20 juni 2024 @ 22:58:
Specifieke batches? Of is daar geen onderzoek naar gedaan?

Willekeurige klanten op willekeurige momenten en ook nog eens verschillende groottes als ik me niet vergis dus verder ook geen onderzoek naar gedaan

[The-Source]

The-Source schreef op donderdag 20 juni 2024 @ 16:52:
[...]

Het betreffen 512e Disks en zou wel als 4kn geformateerd kunnen worden.
Bedankt voor de tip. die ga ik wel meenemen wanneer de disken ga plaatsen.

Om mijzelf maar te quoten. Na eerst via een USB to Sata dongle wat getest te hebben en niet verder kwam (lag achteraf gezien niet aan de dongle) en vervolgens via het nodige google werk openSeaTools aan de praat gekregen op mijn linux host.
Geeft de drive het volgende aan: openSeaChest_Format -d /dev/sg0 --showSupportedFormats

code:

--------------------------------------------------------------------------------
 Logical Block Size  PI-0  PI-1  PI-2  PI-3  Relative Performance  Metadata Size
--------------------------------------------------------------------------------
*               512     Y     N     N     N                   N/A            N/A
--------------------------------------------------------------------------------

En met openSeaChest_Basics --deviceInfo --device /dev/sg0 | grep Size

code:

        Logical Sector Size (B): 512
        Physical Sector Size (B): 4096
        Cache Size (MiB): 256.00

Maar het omzetten naar 4k sector kan dus niet want dan had er dus bij het 1e commando dus ook een 4096 regel moeten staan.
Dus het is niet anders, want als fabrikant tools het niet laat omzetten dan houd het natuurlijk op

in de Exos 12 manual staat overigens ook:

Three conditions must be met before the drive will allow the download operation:
1. The download must be an SED file. A standard (base) drive (non-SED) file will be rejected.
2. The download file must be signed and authenticated.
3. As with a non-SED drive, the download file must pass the acceptance criteria for the drive. For example it must be applicable to
the correct drive model, and have compatible revision and customer status.

Maar support is precies vandaag niet bereikbaar dus zou mij niet verbazen omdat het SED drivers zijn dat je firmware (die wellicht wel 4k heeft) moet aanvragen.

edit:

24-06
Contact gehad met Seagate, geen firmware voor nu. Maar het wordt wel intern "geëscaleerd" waarom het niet mogelijk is. Ondertussen ook verder gezocht voor impact van 512 vs 4Kn, maar als je de juiste ashift wel in 4K blocks wegschrijft is de impact minimaal op een 512e schijf.

[ Voor 24% gewijzigd door The-Source op 24-06-2024 10:04 ]

[nero355]

The-Source schreef op zaterdag 22 juni 2024 @ 14:33:
Na eerst via een USB to Sata dongle wat getest te hebben en niet verder kwam (lag achteraf gezien niet aan de dongle) en vervolgens via het nodige google werk openSeaTools aan de praat gekregen op mijn linux host.

TIP :

Koop een kast voor je PC die een ingebouwde SATA Dockingstation heeft dat je direkt in het moederbord of een losse SATA Controller prikt zoals mijn Xigmatek Elysium

Scheelt je weer knoeien met losse USB SATA Dockingstations/Dongles en of ze wel of niet de volledige HDD doorgeven en zo...

[CrimsonRider]

Ik heb een issue.

Ik heb drie harde schijven, in een enkele pool:

code:

pool: zfspool
 state: ONLINE
  scan: resilvered 2.65M in 00:00:01 with 0 errors on Sun Jul 21 16:10:19 2024
config:

        NAME        STATE     READ WRITE CKSUM
        zfspool     ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Nu begint sdb kuren te vertonen, die wil ik vervangen. Ik heb een nieuwe schijf, maar als ik die erbij prik, heeft Ubuntu 23.10 het lastig om te onthouden welke schijf wat is. Ik had ook geen pool moeten aanmaken met drive letters, maar met id's.

Geen nood. Volgens Google kan ik de pool exporten en dan weer importen.

code:

zpool export zfspool
zpool import -d /dev/disk/by-id zfspool

Maar, dan krijg ik, zoals zoveel mensen de

code:

cannot export 'zfspool': pool is busy

Zelfs na met lsof aan de gang etc. alles handmatig unmounten en wat niet, geen sucess. Dus, dan maar met een live-usb booten. De pool importen, exporten en controleren of hij nu inderdaad op id werkt, klopt allemaal.

Reboot terug Ubuntu in en...... die zet het gewoon weer op /dev/sdb /dev/sdc en /dev/sdd

Wat is nu mijn volgende stap? Moet ik /etc/zfs/zpool.cache weggooien of zoiets? Hoe zorg ik ervoor dat of ik Ubuntu niet langer dat "busy" probleem heb of dat hij niet niet langer /dev/sd* gebruikt herintroduceert?

[CrimsonRider]

En, als antwoord op mijn eigen vraag:

code:

systemctl disable zfs-import-cache.service

Was de oplossing. Die uitzetten. Reboot ubuntu, import - export - import met device ID.

code:

systemctl enable zfs-import-cache.service

om weer tijdens booten op te komen.

[Paul]

CrimsonRider schreef op zondag 21 juli 2024 @ 17:50:
Reboot terug Ubuntu in en...... die zet het gewoon weer op /dev/sdb /dev/sdc en /dev/sdd

Wat is nu mijn volgende stap? Moet ik /etc/zfs/zpool.cache weggooien of zoiets?

Zoals je al gevonden hebt: zoiets ja De /etc van je live-USB is niet dezelfde /etc die Ubuntu-installatie gebruikt, dus moet je zorgen dat de zpool.cache van je Ubuntu-installatie aangepast wordt, niet gebruikt wordt, of niet bestaat. De oplossing die je zelf gevonden hebt lijkt mij de mooiste van de drie, en zorgt ervoor dat je geen live-USB nodig hebt.

[CrimsonRider]

Ja, maar niet ideaal dat niet kunnen offline brengen van de pool. "Busy", waarom dan? Echt, ik kwam er niet achter. En ik vind mezelf redelijk skilled in Linux. Dit had ik moeten kunnen vinden.

Anyways, nachtje resilver en de storage draait weer. Ik heb wel 5 checksum errors opgelopen ergens, dus nu draait ook een scrub.

[willemw12]

Ik heb daar ook last van. Is ongeveer een half jaar geleden bij mij begonnen. Een eenvoudige oplossing: eerst de computer uitzetten en dan pas een disk eruit halen.

[Lennart_1337]

Ben met ZFS aan het experimenteren d.m.v. TrueNAS.
Heb 1 schijf van een 3-schijven mirror pool ge-detached en nu zijn er nog 2 schijven in de pool over.
Dus het is mogelijk om een mirror te downgraden naar minder disken.

Maar als ik weer een disk probeer toe te voegen moet moet ik ik ineens een zelfde aantal disken toevoegen als er al in de pool zitten, dus dat zijn er 2.

Begrijp ik het goed dat als ik weer terug naar een 3 weg mirror wil ik 2 disken moet toevoegen, en na het resilveren weer 1 disk moet detachen?

Is er een technische redenen dat ZFS op deze manier ontworpen is?

[dcm360]

@Lennart_1337 Waarschijnlijk zet je de pool met die optie om in een striped mirror, in plaats van dat je een disk toevoegt aan de mirror. Een mirror zou je gewoon een enkele schijf aan moeten kunnen toevoegen.

[FireDrunk]

Volgens mij is er onder TrueNAS een verschil tussen een vdev wijzigen en een pool wijzigen.
Een disk aan een mirror toevoegen is een vdev wijziging.

[RobertMe]

Ik ben eens even aan het testen of het voor mij nut zou hebben om wat met een 2,5Gbit/s netwerk gaan te doen, om grote file transfers te versnellen. Alleen heb ik het idee dat mijn ZFS niet lekker mee werkt? Daarom mijn vraag welke snelheden ik zou kunnen verwachten op een single disk (SATA SSD) pool.

Op twee systemen kom ik met hdparm -t /dev/sda uit op in de 500MB/s, wat matcht met de 6.0Gbit/s van SATA. Doe ik echter dd if="groot bestand" of=/dev/zero bs=1M kom ik op het ene systeem uit op ~140MB/s en de ander ~180MB/s. Beide systemen draaien op een Intel N5105 CPU die op dat moment naar 100% lijkt te gaan (maar wachten op I/O telt ook als CPU verbruik meen ik?). Wat wel verschillend is is dat op de eerste, blijkbaar, compression aan staat (met een ratio van 1.0 dus "doet niks" ) en op de ander niet. Ik verwacht dat dat een deel van het verschil mogelijk verklaard? SSDs zijn respectievelijk een Sansung 870 EVO en een wat oudere WD Blue. Dus if anything zou ik verwachten dat het eerste systeem iets sneller zou kunnen zijn? Met gelijke settings v.w.b. compression.

Edit:
Of zou ik alsnog tegen de limieten van de CPU aanlopen v.w.b. controleren checksums etc? Geen idee of dat aan de orde kan zijn. Het is natuurlijk wel een relatieve low end CPU maar ook niet echt slecht.

Edit2:
Ook maar even de "grote bak" aangeslingerd. 3x draaiend roest,2x shucked WD Elements 1x Toshiba, in RAIDZ1. hdparm -t komt uit op 200, 270, 200 (ik gok dat de Toshba de middelste is Die is ook 7200RPM en de WD Elements voor zover mij bekend 5400RPM). Lezen van een groot bestand komt uit op 210MB/s zoiets. CPU verbruik, op een Intel i3 9100 schiet wel omhoog maar geen "4x 100%". Ook hier met compression aan (/"on", de ander stond expliciet op lz4) en een "compressratio" van 1.00 .

[ Voor 23% gewijzigd door RobertMe op 10-08-2024 11:07 ]

[RobertMe]

RobertMe schreef op zaterdag 10 augustus 2024 @ 10:30:
Ik ben eens even aan het testen of het voor mij nut zou hebben om wat met een 2,5Gbit/s netwerk gaan te doen, om grote file transfers te versnellen. Alleen heb ik het idee dat mijn ZFS niet lekker mee werkt? Daarom mijn vraag welke snelheden ik zou kunnen verwachten op een single disk (SATA SSD) pool.

Op twee systemen kom ik met hdparm -t /dev/sda uit op in de 500MB/s, wat matcht met de 6.0Gbit/s van SATA. Doe ik echter dd if="groot bestand" of=/dev/zero bs=1M kom ik op het ene systeem uit op ~140MB/s en de ander ~180MB/s. Beide systemen draaien op een Intel N5105 CPU die op dat moment naar 100% lijkt te gaan (maar wachten op I/O telt ook als CPU verbruik meen ik?). Wat wel verschillend is is dat op de eerste, blijkbaar, compression aan staat (met een ratio van 1.0 dus "doet niks" ) en op de ander niet. Ik verwacht dat dat een deel van het verschil mogelijk verklaard? SSDs zijn respectievelijk een Sansung 870 EVO en een wat oudere WD Blue. Dus if anything zou ik verwachten dat het eerste systeem iets sneller zou kunnen zijn? Met gelijke settings v.w.b. compression.

Edit:
Of zou ik alsnog tegen de limieten van de CPU aanlopen v.w.b. controleren checksums etc? Geen idee of dat aan de orde kan zijn. Het is natuurlijk wel een relatieve low end CPU maar ook niet echt slecht.

Edit2:
Ook maar even de "grote bak" aangeslingerd. 3x draaiend roest,2x shucked WD Elements 1x Toshiba, in RAIDZ1. hdparm -t komt uit op 200, 270, 200 (ik gok dat de Toshba de middelste is Die is ook 7200RPM en de WD Elements voor zover mij bekend 5400RPM). Lezen van een groot bestand komt uit op 210MB/s zoiets. CPU verbruik, op een Intel i3 9100 schiet wel omhoog maar geen "4x 100%". Ook hier met compression aan (/"on", de ander stond expliciet op lz4) en een "compressratio" van 1.00 .

Found it. Helemaal niet er aan gedacht dat het bestand, op alle drie de systemen, op een (native) encrypted pool staat .

Met dd if=/dev/urandom of=test.img bs=1M count=4096 nu een bestand gegenereerd dat mooi exact 4.0GiB groot is. Dit staat nu op een niet encrypted dataset, en lezen gaat dan met ~490MB/s. Kopieer ik het bestand naar de native encrypted pool dan kom ik uit op ~140MB/s. Dus de native encryption is het "issue". En als ik bij het lezen van de niet encrypted dataset naar htop kijk dan is dat ook een stuk vriendelijker voor het CPU gebruik (lees: geen 4 cores op 100% maar wat spikes tot 50% hier en daar die net zo goed kunnen komen door overige zaken die op het systeem draaien).

[RobertMe]

RobertMe schreef op zaterdag 10 augustus 2024 @ 15:17:
[...]

Found it. Helemaal niet er aan gedacht dat het bestand, op alle drie de systemen, op een (native) encrypted pool staat .

Met dd if=/dev/urandom of=test.img bs=1M count=4096 nu een bestand gegenereerd dat mooi exact 4.0GiB groot is. Dit staat nu op een niet encrypted dataset, en lezen gaat dan met ~490MB/s. Kopieer ik het bestand naar de native encrypted pool dan kom ik uit op ~140MB/s. Dus de native encryption is het "issue". En als ik bij het lezen van de niet encrypted dataset naar htop kijk dan is dat ook een stuk vriendelijker voor het CPU gebruik (lees: geen 4 cores op 100% maar wat spikes tot 50% hier en daar die net zo goed kunnen komen door overige zaken die op het systeem draaien).

En nog wat verder zitten zoeken

Op Reddit kwam ik deze thread tegen: https://www.reddit.com/r/..._io_performance_with_and/ waarin iemand een performance vergelijking heeft gedaan tussen gewoon plain ZFS, LUKS met daarop ZFS, en ZFS met native encryption. En de read performance daarop is ook dramatisch. Waarvoor die "toen", 2 jaar terug, ook een bug report bij OpenZFS heeft aangemaakt: https://github.com/openzfs/zfs/issues/13736 . Alleen is dat zonder verdere reactie vanuit de ZFS devs (sure, open source, al dan niet vrijwilligers, een reactie hoeft niet, maar anderzijds zijn "we" ook al 2 jaar verder, en zou iets van een reactie wellicht netjes geweest zijn, al is het maar een netjese variant van "deal with it"). De reporter trekt daarbij ook de conclusie (die al dan niet klopt) dat mogelijk de data op het moment dat deze van de MRU naar de MFU (respectievelijk most recently / frequently used) gaat gedecrypt wordt en opnieuw geencrypt. Dat zou ook verklaren waarom de performance uit zijn tests semi identiek is aan een schrijf test, ondanks dat die aan het lezen is.

Wat mijn dan alleen opvalt is dat als ik de file lees, met ~140MB/s, ik die ~140MB/s ook zie in iostat, de "echte". Dat zpool iostat de "degraded" performance rapporteert kan ik nog in komen, immers is dat de snelheid waarmee uiteindelijk de data gelezen wordt van de pool/dataset. Maar met iostat zelf aan de disk zou ik dan nog steeds verwachten dat die of op full beans (~500MB/s) leest, of niet (omdat het uit ARC komt), of dat ik ook zie dat die vol aan de CPU trekt en het uiteindelijk "CPU limited" is. En ik zie wel iets van CPU verbruik van dd (~10%), maar dus niet die "100%" wat wel de load op de cores is.

Edit:
De klassieke top geeft meer info dan htop (mogelijk in htop ook configureerbaar, kwam ook nu pas er achter dat je in htop een regel met ZFS info (ARC, MFU, MRU sizes) kunt krijgen ). En tijdens het lezen is schiet meteen 3x z_rd_int naar 90%+. Dus het CPU verbruik zal gok ik ergens in de kernel (/kernel thread) zitten en daardoor niet zichtbaar onder dd.
Dan zal de "traagheid" van de CPU dus de I/O limiteren waardoor die effectief met ~140MB/s leest ondanks dat de lees acties in kleinere blokjes wel veel sneller zullen zijn. Alleen is die met een interval van 1 sec dus niet 1s vol aan het lezen maar is die in die ene seconde maar voor zeg 33% met IO bezig en de overige 66% is de CPU de beperking. Gok ik dan.

Edit2:
En htop heeft inderdaad een "Hide kernel threads" optie die aan stond (by default?). F2 voor setup => ("Display options" => "Hide kernel options". En voor ZFS stats ook F2 => "Meters" => 3x pijltje naar rechts (navigeren naar "Available meters") => "ZFS ARC" (enter) => met pijltjes kolom en positie in kolom selecteren => enter.

[ Voor 16% gewijzigd door RobertMe op 10-08-2024 21:49 ]

[ComTech]

Ik ben bezig om een TrueNas NAS op te zetten lukt prima alleen moet ik nu even wat verplaatsten van een tijdelijke disk naar een nieuwe pool.
Replication task gestart van een dataset maar nu geeft hij sending 1 van 3 (omdat er 3 snapshot van zijn).
De dataset is ongeveer 1 TiB maar gaat hij nu 3x die 1 TiB overzetten?
Er zit tussen de snapshot weinig verschil in data paar Gb is er soms bijgekomen.

[FireDrunk]

Als het goed is niet, ZFS is slim genoeg om een diff tussen Snapshots te syncen.

[RobertMe]

FireDrunk schreef op woensdag 14 augustus 2024 @ 20:41:
Als het goed is niet, ZFS is slim genoeg om een diff tussen Snapshots te syncen.

Technisch is de data er natuurlijk ook maar 1x. De nieuwere snapshots bevatten alleen de nieuwe / gewijzigde files, door Copy on Write. Op de disk zijn de snapshots dus uberhaupt "zo klein". En met een recursive of incremental sync kan die dus min of meer een op een de data van de ene disk naar de andere overzetten (wat dan weer niet zo is tenzij je een raw send doet).

[ComTech]

Het is gelukt nadat hij het 1e snapshot had verzonden ging de 2e en 3e ineens heel snel en was hij klaar.
Daarna nog de samba share aangepast en de rechten en alles werkte zoals eerst.
Best handig.

Heb ik alleen nog een uitdaging ik heb bij de nieuwe pool ook een mirror Log gemaakt van 2 nvme's.
Nu wil ik deze vervangen voor andere SSD's maar kan niet eerst een nieuwe erbij zetten (maar 2 M.2 aansluitingen).
Wat is de beste methode dan?
1 SSD offline zetten, server uit nieuwe SSD erin en die weer aan de pool toevoegen en dat herhalen als de resilvering klaar is?

[RobertMe]

ComTech schreef op woensdag 14 augustus 2024 @ 22:11:
Het is gelukt nadat hij het 1e snapshot had verzonden ging de 2e en 3e ineens heel snel en was hij klaar.
Daarna nog de samba share aangepast en de rechten en alles werkte zoals eerst.
Best handig.

Heb ik alleen nog een uitdaging ik heb bij de nieuwe pool ook een mirror Log gemaakt van 2 nvme's.
Nu wil ik deze vervangen voor andere SSD's maar kan niet eerst een nieuwe erbij zetten (maar 2 M.2 aansluitingen).
Wat is de beste methode dan?
1 SSD offline zetten, server uit nieuwe SSD erin en die weer aan de pool toevoegen en dat herhalen als de resilvering klaar is?

Een ZIL? Heb er zelf geen ervaring mee, maar dat is toch puur voor performance? En (dus) optioneel? Dan zou ik er voor kiezen om het tijdelijk helemaal uit te zetten/disks verwijderen (waarbij ZFS neem ik aan zo slim is om het eerst te syncen naar de daadwerkelijke pool/disks voordat die "akkoord" gaat met verwijderen), vervolgens afsluiten, nieuwe SSDs plaatsen, en opnieuw toevoegen.

Een voor een vervangen zal ook best kunnen, maar dan heb je twee keer downtime etc terwijl het effectief waarschijnlijk niks tot "niet veel" oplevert?,

[ComTech]

RobertMe schreef op woensdag 14 augustus 2024 @ 22:55:
[...]

Een ZIL? Heb er zelf geen ervaring mee, maar dat is toch puur voor performance? En (dus) optioneel? Dan zou ik er voor kiezen om het tijdelijk helemaal uit te zetten/disks verwijderen (waarbij ZFS neem ik aan zo slim is om het eerst te syncen naar de daadwerkelijke pool/disks voordat die "akkoord" gaat met verwijderen), vervolgens afsluiten, nieuwe SSDs plaatsen, en opnieuw toevoegen.

Een voor een vervangen zal ook best kunnen, maar dan heb je twee keer downtime etc terwijl het effectief waarschijnlijk niks tot "niet veel" oplevert?,

Het was een zil inderdaad, ik heb hem helemaal verwijderd voor mijn use case levert het waarschijnlijk niet veel op.
Ik maak wel een SSD pool erbij voor snelle opslag
Heb jaren geleden met ZFS geprutst dus het is weer even zoeken wat de goede opties zijn.

[FireDrunk]

Ik heb redelijk veel gebruik gemaakt van ZIL en L2ARC. Uiteindelijk heb ik ze beide weggedaan.

ZIL is leuk, maar de hoeveelheid writes op je SSD zijn echt gigantisch, en de winst is voor thuis beperkt, tenzij je een echte dikke bak aan VM's op een harddisk pool hebt draaien.
Voor niet kritische filesystems zoals bijvoorbeeld films en tv series ben je veel beter af met gewoon sync op disabled zetten. Dat is nog sneller dan een ZIL.

L2ARC is beperkt leuk voor thuis als je wat data uit wil kunnen lezen terwijl je disks in standby staan.
Verder wordt je L2ARC erg zwaar belast voor films en series. Alles sequentiele writes gaan er namelijk vrolijk overheen. Dus elke GB die naar je pool gaat, gaat ook naar je L2ARC voor het MRU (most recently used) cache.

Dat is voor een paar VM's op een harddisk pool vaak niet zo'n ramp, maar voor een terrabytes groot filesystem waar je gigabytes overheen tilt erg onhandig.

Liever een groter ARC dan een L2ARC, maar dat kost wat meer geld uiteraard.

Voor snelle storage is een SSD only pool in bijna alle gevallen een betere optie.

[ Voor 4% gewijzigd door FireDrunk op 15-08-2024 11:42 ]

[ph0t0nix]

FireDrunk schreef op donderdag 15 augustus 2024 @ 11:42:
Verder wordt je L2ARC erg zwaar belast voor films en series. Alles sequentiele writes gaan er namelijk vrolijk overheen. Dus elke GB die naar je pool gaat, gaat ook naar je L2ARC voor het MRU (most recently used) cache.

Dat klopt volgens mij niet. De L2ARC (en de ARC zelf) is een read cache. Writes hebben daar niks te zoeken, die gaan (evt. ook via de SLOG) direct naar disk.

[FireDrunk]

ph0t0nix schreef op donderdag 15 augustus 2024 @ 20:30:
[...]

Dat klopt volgens mij niet. De L2ARC (en de ARC zelf) is een read cache. Writes hebben daar niks te zoeken, die gaan (evt. ook via de SLOG) direct naar disk.

Hoe denk je dat een read cache gevuld wordt, magie?

Maar zonder dollen, l2arc word belast totdat je caches vol zitten. Als je hem instelt op meer MFU zullen er minder writes op gebeuren dan met MRU, maar writes zullen er altijd gebeuren.

Volle caches gaan evicten op basis van een policy. Bij zfs is dat by default 50% mru / 50% mfu.

Als je dat niet aanpast gaat alle data bestemd voor filesystems waar l2 caching aan staat door je l2arc heen.

[ Voor 37% gewijzigd door FireDrunk op 15-08-2024 20:38 ]

[RobertMe]

RobertMe schreef op zaterdag 10 augustus 2024 @ 10:30:
Ik ben eens even aan het testen of het voor mij nut zou hebben om wat met een 2,5Gbit/s netwerk gaan te doen, om grote file transfers te versnellen. Alleen heb ik het idee dat mijn ZFS niet lekker mee werkt? Daarom mijn vraag welke snelheden ik zou kunnen verwachten op een single disk (SATA SSD) pool.

Op twee systemen kom ik met hdparm -t /dev/sda uit op in de 500MB/s, wat matcht met de 6.0Gbit/s van SATA. Doe ik echter dd if="groot bestand" of=/dev/zero bs=1M kom ik op het ene systeem uit op ~140MB/s en de ander ~180MB/s. Beide systemen draaien op een Intel N5105 CPU die op dat moment naar 100% lijkt te gaan (maar wachten op I/O telt ook als CPU verbruik meen ik?). Wat wel verschillend is is dat op de eerste, blijkbaar, compression aan staat (met een ratio van 1.0 dus "doet niks" ) en op de ander niet. Ik verwacht dat dat een deel van het verschil mogelijk verklaard? SSDs zijn respectievelijk een Sansung 870 EVO en een wat oudere WD Blue. Dus if anything zou ik verwachten dat het eerste systeem iets sneller zou kunnen zijn? Met gelijke settings v.w.b. compression.

Edit:
Of zou ik alsnog tegen de limieten van de CPU aanlopen v.w.b. controleren checksums etc? Geen idee of dat aan de orde kan zijn. Het is natuurlijk wel een relatieve low end CPU maar ook niet echt slecht.

Edit2:
Ook maar even de "grote bak" aangeslingerd. 3x draaiend roest,2x shucked WD Elements 1x Toshiba, in RAIDZ1. hdparm -t komt uit op 200, 270, 200 (ik gok dat de Toshba de middelste is Die is ook 7200RPM en de WD Elements voor zover mij bekend 5400RPM). Lezen van een groot bestand komt uit op 210MB/s zoiets. CPU verbruik, op een Intel i3 9100 schiet wel omhoog maar geen "4x 100%". Ook hier met compression aan (/"on", de ander stond expliciet op lz4) en een "compressratio" van 1.00 .

En nog maar eens wat in gedoken. perf top geeft ook wat leuke inzichten. Ten eerste wordt op alle 3 de systemen (2x N5105, 1x i3 9100) AES-NI gebruikt, wat blijkt uit het gebruik van de aes_*intel methodes die hiermee boven komen drijven. Leuke extra: op beide N5105 systemen AES uit gezet, op 1 leek het mogelijk wat extra performance te geven, alleen... is de BIOS optie daarna * poof * gone. Met een "Load optimized defaults" (+ save + reboot) komt die wel weer terug. Maar anders echt helemaal weg uit de lijst met opties.
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.

---

Verder kom ik er nu achter dat op het oude systeem (i3 9100) blijkbaar aes-256-ccm gebruikt wordt, en op de nieuwe systemen (2x N5105 dan) wordt aes-256-gcm gebruikt. Snelle zoektocht lijkt te duiden op dat gcm eigenlijk beter is (al langere tijd?). Vraag ik me toch af waarom dat ene systeem aes-256-ccm gebruikt

[ph0t0nix]

FireDrunk schreef op donderdag 15 augustus 2024 @ 20:34:
[...]
Hoe denk je dat een read cache gevuld wordt, magie?

Door reads natuurlijk . Op een systeem waar wel read splaatsvinden maar bijna geen writes (naar de gewone disks in de vdevs), zou L2ARC gewoon gevuld worden (er vinden dus wel writes naar de L2ARC disk(s) plaats).

Misschien begrijpen we elkaar verkeerd? Ik triggerde op deze zin van je:

Dus elke GB die naar je pool gaat, gaat ook naar je L2ARC voor het MRU (most recently used) cache.

De L2ARC word gevuld met data "onderuit" de ARC, data die vermoedelijk bijna op het punt van eviction uit de ARC staat. Op https://klarasystems.com/articles/openzfs-all-about-l2arc/ staat een goede uitleg. Bijvoorbeeld:

In short, the L2ARC is continually fed with blocks that are near eviction from ARC. If the ARC evicts blocks faster than L2ARC is willing to write them, those blocks simply don’t get cached at all—which is probably fine, since extremely rapid ARC evictions generally mean a streaming workload is underway, and those blocks likely aren’t crucial to keep cached in the first place. Caching only a fraction of what is being evicted ensures we don’t write data to the cache just to replace it with different data in a few minutes.

Eerder schreef je ook:

Als je dat niet aanpast gaat alle data bestemd voor filesystems waar l2 caching aan staat door je l2arc heen.

Dat betwijfel ik dus.

Liever een groter ARC dan een L2ARC, maar dat kost wat meer geld uiteraard.

Daar ben ik het dan wel weer helemaal mee eens. Uit het eerder gelinkte artikel:

When should I use L2ARC?

For most users, the answer to this question is simple—you shouldn’t. The L2ARC needs system RAM to index it—which means that L2ARC comes at the expense of ARC. Since ARC is an order of magnitude or so faster than L2ARC and uses a much better caching algorithm, you need a rather large and hot working set for L2ARC to become worth having.

[FireDrunk]

ph0t0nix schreef op vrijdag 16 augustus 2024 @ 23:05:
[...]

Door reads natuurlijk . Op een systeem waar wel read splaatsvinden maar bijna geen writes (naar de gewone disks in de vdevs), zou L2ARC gewoon gevuld worden (er vinden dus wel writes naar de L2ARC disk(s) plaats).

Misschien begrijpen we elkaar verkeerd? Ik triggerde op deze zin van je:

[...]

De L2ARC word gevuld met data "onderuit" de ARC, data die vermoedelijk bijna op het punt van eviction uit de ARC staat. Op https://klarasystems.com/articles/openzfs-all-about-l2arc/ staat een goede uitleg. Bijvoorbeeld:

[...]


Eerder schreef je ook:

[...]

Dat betwijfel ik dus.


[...]

Daar ben ik het dan wel weer helemaal mee eens. Uit het eerder gelinkte artikel:

[...]

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.

[ph0t0nix]

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.

Dan zijn we het helemaal eens .

En, inderdaad, ook ik heb in de thuissituatie (en zelfs professioneel) weinig tot geen voordeel van een L2ARC gezien.

[RobertMe]

RobertMe schreef op vrijdag 16 augustus 2024 @ 22:39:
Verder kom ik er nu achter dat op het oude systeem (i3 9100) blijkbaar aes-256-ccm gebruikt wordt, en op de nieuwe systemen (2x N5105 dan) wordt aes-256-gcm gebruikt. Snelle zoektocht lijkt te duiden op dat gcm eigenlijk beter is (al langere tijd?). Vraag ik me toch af waarom dat ene systeem aes-256-ccm gebruikt

Hierop terugkomende. Tot OpenZFS 0.8.4 was aes-256-ccm de default, vanaf 0.8.4 is aes-256-gcm de default. Gezien 0.8.4 in mei 2020 is uitgekomen en dit systeem draait sinds ~januari 2020 zal dit dus de reden te zijn.

Nu even een testje gedaan, op de NVME mirror. En zonder encryptie haal ik daarop ~880MB/s, met aes-256-gcm ~775MB/s (best netjes dus), met aes-256-ccm maar ~230MB/s. Dus intussen maar eens een send / receive aan het doen

Waarbij het GCM deel dus wel een AVX gebaseerde implementatie heeft die dus veel sneller is dan "gewoon" (met uhm, traditionele instructieset en gebeuren?), en CCM dus niet. Wat dus het (enorme) snelheidsverschil verklaart.

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

Edit:
Oei, load van 12, 13, op een 4 core systeem .
Misschien stoppen en aan mijn desktop hangen, dan heeft die 14 cores (20 virtuele)

[ Voor 4% gewijzigd door RobertMe op 18-08-2024 16:52 ]

[GioStyle]

Ik draai hier thuis een servertje met zfs on root op een nvme ssd van 4TB. Lokaal op de server maak ik door middel van script/syncoid backups op een 2.5" 4TB ssd. Echter heb ik deze ssd verkocht en ben ik van plan om een tweede nvme ssd van 4TB aan te schaffen en hoogstwaarschijnlijk dezelfde merk en type ssd. Echter twijfel ik tussen raid1 en mijn huidige backup strategie.

Met mijn huidige backup strategie heb ik meer flexibiliteit en kan ik me meer PEBCAK veroorloven. Stel ik verwijder per ongeluk een snapshot die ik niet had moeten verwijderen, dan heb ik mijn tweede dataset nog als backup. Met raid1 ben ik deze snapshot gewoon kwijt, dus raid1 is in mijn ogen niet echt een backup. Met raid1 ben ik (waarschijnlijk) wel beter beschermd tegen bijvoorbeeld bitrot en ik heb er eigenlijk geen omkijken naar.

Dus kortgezegd:

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.

[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