Het grote ZFS topic

[RobertMe]

ZFS 2.1.14 & 2.2.2 zijn uit met daarin (als het goed is) een fix voor de bug waar afgelopen dagen veel over gesproken is.

"Als het goed is" omdat er blijkbaar (nog steeds) geen 100% reproduceerbare testcase voor is. Er is alleen een script dat het probleem relatief snel (binnen minuten) kan triggeren voor velen. En dat script weet het probleem niet meer te veroorzaken.

Verdere uitleg hier: https://gist.github.com/r...9aba3fadc04db18574d30dc73

Updates van alle OSen volgen hopelijk ook snel. Proxmox heeft de individuele patch al eerder toegepast op pvetest & no-subscription (in ieder geval voor 8, 7 weet ik niet) en enterprise zou gisteren geupdate zijn. Bij Debian "zie ik nog niks", bookworm bevat 2.1.11 (-1, dus ook geen bump met Debian patches), bookworm-backports 2.1.13-2 die afgaande op het changelog wel de backported patch bevat, sinds gisteravond. Hopelijk dat de patch dan ook nog doorsijpelt naar de main / updates repo (volledige update naar 2.1.14 of backport van de patch). Arch Linux met een community / 3th party repo voor ZFS bevat 2.2.1 bevat blijkbaar sinds de 28e de patch, en zal ook wel snel formeel geupdate worden naar 2.2.2. Red Hat heb ik geen idee van, maar afgaande op de link is dat in ieder geval niet vatbaar voor het issue getriggerd door cp doordat zij nog coreutils 8 gebruiken en de cp implementatie daarin het issue niet triggert (maar andere software dat uiteraard nog steeds kan).

Het originele probleem bestaat overigens al sinds 0.6.2. Maar het wordt maar zeer incidenteel getriggerd, en dan niet alleen op basis van gebruikte code, er is dus ook geen "als je code X gebruikt gaat het 100% van de tijd fout". Dus nu cp "code X" gebruikt is er een programma waarmee het "vaker" mis gaat, maar het blijft (zeer) incidenteel, en het blijft vaker goed gaan dan fout.

CC @zeroday & @Mars Warrior

[CurlyMo]

@RobertMe Er is ook nog een FreeBSD Die ben je vergeten te vermelden.

[RobertMe]

CurlyMo schreef op vrijdag 1 december 2023 @ 12:03:
@RobertMe Er is ook nog een FreeBSD Die ben je vergeten te vermelden.

Daar heb ik geen affiniteit mee.
Debian, Proxmox & Arch gebruik ik wel (laatste niet meer met ZFS). Waarom ik RHEL benoemd heb weet ik ook niet , nooit gebruikt maar staat wel in die beschrijving . Bij @Mars Warrior was het een collega(?) met Unraid die daadwerkelijk data kwijt was, ook daarvan heb ik niet opgezocht of er een update was.

[Mars Warrior]

RobertMe schreef op vrijdag 1 december 2023 @ 13:29:
[...]

Daar heb ik geen affiniteit mee.
Debian, Proxmox & Arch gebruik ik wel (laatste niet meer met ZFS). Waarom ik RHEL benoemd heb weet ik ook niet , nooit gebruikt maar staat wel in die beschrijving . Bij @Mars Warrior was het een collega(?) met Unraid die daadwerkelijk data kwijt was, ook daarvan heb ik niet opgezocht of er een update was.

Yup. Een collega. Ikzelf gebruik MergerFS/SnapRaid.

Wat ik begrepen heb is dat hij van BTRFS naar ZFS is gegaan voor een deel van zijn data. Dus een hele bups lopen kopiëren. Hij gaat weer terug naar BTRFS in ieder geval en was nu bezig om zijn oude schijven te controleren om te kijken wat daar nog van de corrupte set data op staat...

Unraid heeft een mitigatie in de laatste versie die net uit is, maar daar heeft hij natuurlijk niks aan.

[silverball]

CurlyMo schreef op vrijdag 1 december 2023 @ 12:03:
@RobertMe Er is ook nog een FreeBSD Die ben je vergeten te vermelden.

Krijg toch van deze bug weer de neiging om FreeBSD terug te nemen

[RobertMe]

silverball schreef op vrijdag 1 december 2023 @ 14:27:
[...]

Krijg toch van deze bug weer de neiging om FreeBSD terug te nemen

FreeBSD gebruikt ook OpenZFS dus hetzelfde risico.

[silverball]

RobertMe schreef op vrijdag 1 december 2023 @ 14:48:
[...]

FreeBSD gebruikt ook OpenZFS dus hetzelfde risico.

Oei ik dacht dat het puur een bug was in combinatie met GNU Coreutils, het blijkt complexer dan dat. Nevermind!

[RobertMe]

silverball schreef op vrijdag 1 december 2023 @ 14:51:
[...]

Oei ik dacht dat het puur een bug was in combinatie met GNU Coreutils, het blijkt complexer dan dat. Nevermind!

De ZFS bug zit in alle OpenZFS implementaties. Het daadwerkelijk triggeren van de bug is blijkbaar zeer lastig / komt zeldzaam voor. O.a. dus doordat het alleen in een specifiek code pad voorkomt, maar ook dan is het niet echt 100% te reproduceren. Doordat die nieuwe coreutils versie een ander (/dit specifieke) code pad volgt viel het echter wel veel meer op. Omdat dus elke cp ... een kans had om deze big te triggeren.
In principe had het dus ook best gekund dat cp op FreeBSD hetzelfde zou doen als wat coreutils 9 nu doet en het daardoor op FreeBSD juist al langer zou spelen (maar bv minder aandacht kreeg omdat bv 1% bij BSD omdat dat weer veel minder gebruikers zijn dan bij Linux).

En daarnaast dus dat het geen probleem specifiek met cp is. Het is het code pad dat het probleem geeft, en elk programma kan natuurlijk op die specifieke manier te lezen / schrijven (als ik het nu goed begreep is het probleem niet eens het schrijven, maar het lezen, en kan een copy van ZFS naar bv ext4 ook een corrupt bestand opleveren).

[CurlyMo]

RobertMe schreef op vrijdag 1 december 2023 @ 11:32:
Proxmox heeft de individuele patch al eerder toegepast op pvetest & no-subscription (in ieder geval voor 8, 7 weet ik niet) en enterprise zou gisteren geupdate zijn.

Andere optie is niet updaten. Ik zag dat mij niet bijgewerkte Proxmox nog op coreutils 8 zit.

[RobertMe]

CurlyMo schreef op vrijdag 1 december 2023 @ 16:10:
[...]

Andere optie is niet updaten. Ik zag dat mij niet bijgewerkte Proxmox nog op coreutils 8 zit.

Kan, maar... Dqn ben je nog steeds vatbaar voor de bug. Alleen niet door de kwetsbaarheid in cp. Maar het kan nog steeds zijn dat een ander programma exact hetzelfde lees-gedrag heeft als cp van coreutils 9. Niet updaten betekent dus dat er nog steeds een (zeer gering) risico is dat je hier tegenaan loopt.

En ja, met coreutils 9 is het risico ogenschijnlijk nog steeds klein dat je er tegenaan loopt, en met coreutils 8 dus nog kleiner. Maar het risico zou er niet moeten zijn met ZFS 2.1.14 & 2.2.2. (Noch met ZFS ouder dan 0.6.2?)

Maar... de vraag is natuurlijk ook een beetje hoe betrouwbaar deze aanpassing is en of daar dan geen (ander) issue in zit. Zelf hink ik ook nog op beide gedachten. Ik weet niet of ik getroffen ben, maar denk van niet (en anders is het toch al te laat). En "in alle paniek" updaten naar een versie die "in paniek" gemaakt is wellicht ook weer onverstandig. Liever wachten tot deze patch zich bewezen heeft? En niet weer een nieuw probleem in zit (potentieel). Want ook dat risico is er natuurlijk. Maar als ik het goed begrepen heb hebben ze historisch de "dirty" check nog wel eens gewisseld van A, dat niet goed was, naar B, en IIRC zelfs weer terug naar A omdat B toch ook niet goed was. En is het nu "A of B", de logica van de fix is daaemee nog vrij eenvoudig te volgen. Echter roept het dan wel de vraag op hoe het kan dat deze conclusie de vorige keren niet getrokken is.

[nero355]

RobertMe schreef op vrijdag 1 december 2023 @ 13:29:
Daar heb ik geen affiniteit mee.

Zou je wel moeten doen, want IMHO ondanks de vele Linux trekjes die erin zijn gekomen door de jaren heen nog steeds het meest volledige OS van allemaal !!!

RobertMe schreef op vrijdag 1 december 2023 @ 14:48:
FreeBSD gebruikt ook OpenZFS dus hetzelfde risico.

Op dit soort momenten zou ik nog meer willen dat die merge niet door was gevoerd, maar helaas pindakaas...

[eheijnen]

Is dit alleen op OpenZFS of is er iets bekend dat zich dit ook op Solaris voordoet?

[eheijnen]

Die bug schijnt ook in Solaris ZFS te zitten
https://gist.github.com/r...76734#gistcomment-4776734

[player-x]

Sorry plaatste reactie in het verkeerde draadje

[ Voor 94% gewijzigd door player-x op 06-12-2023 05:33 ]

[Waking_The_Dead]

Waking_The_Dead schreef op zondag 26 november 2023 @ 16:30:
Ik heb een Freenas installatie waar ik een aantal pools op heb. Onlangs is een pool degraded geraakt (mirror, twee schijven van 4TB). Ik heb beslist om de kapotte schijf niet te vervangen maar een nieuwe pool aan te maken in zfs raid met 3 schijven.
De nieuwe pool is in gebruik en de data is gekopieerd maar het lukt me niet om de degraded pool te exporten; ik krijg telkens de melding 'device is busy'. Ook het unmounten van de resterende schijf lukt niet en zelfs een zpool destroy lukt niet (ook niet met de -f optie). Er zijn ook geen shares of symlinks meer actief op die pool.
Herstarten van het systeem leverde niets op.
Vervolgens heb ik gewoon de schijf fysiek uit mijn NAS gehaald omdat ik het zo wel een beetje gehad had en de schijf toch buiten gebruik gesteld wordt. Zonder die schijf start mijn NAS gewoon op en kan ik pingen naar het ip adres maar de web UI is niet bereikbaar. Vervolgens de schijf teruggeplaatst, herstart en de UI is weer bereikbaar. Is het mogelijk dat er ergens config van de UI op die oude pool is opgeslagen? En hoe vind ik zoiets terug?

OK, na lang zoeken heb ik ontdekt dat een van mijn jails een mount point had op die pool. Phew. Het was wel handig geweest dat Freenas dit gewoon even meldt wanneer je een export probeert te doen.

[CurlyMo]

Waking_The_Dead schreef op woensdag 6 december 2023 @ 16:54:
[...]


OK, na lang zoeken heb ik ontdekt dat een van mijn jails een mount point had op die pool. Phew. Het was wel handig geweest dat Freenas dit gewoon even meldt wanneer je een export probeert te doen.

Gaf lsof geen uitsluitsel?

[Waking_The_Dead]

CurlyMo schreef op woensdag 6 december 2023 @ 18:24:
[...]

Gaf lsof geen uitsluitsel?

Neen, da's het vervelende. Er was geen enkel bestand in gebruik op die pool volgens lsof. Misschien dat ik ergens nog een extra parameter moest opgeven ofzo. Maar goed, ik heb weer iets bijgeleerd :-)

[RobertMe]

Ik wilde hier een WTF vraag gaan stellen, maar... de rubber duck deed perfect zijn werk

Maar om toch niet alle werk voor niks gedaan te hebben: ZFS compression doet perfect zijn werk:

robert@nas:~$ zfs get compression rpool/data/docker/data/networking tank/backup/local/docker/networking
NAME                                 PROPERTY     VALUE           SOURCE
rpool/data/docker/data/networking    compression  on              inherited from rpool
tank/backup/local/docker/networking  compression  off             default
robert@nas:~$ zfs list rpool/data/docker/data/networking tank/backup/local/docker/networking
NAME                                  USED  AVAIL     REFER  MOUNTPOINT
rpool/data/docker/data/networking    3.87G   365G     3.87G  /rpool/data/docker/data/networking
tank/backup/local/docker/networking  40.8G  1.08T     40.8G  /tank/backup/local/docker/networking

Een dataset die op de rpool / "aan live data" 3,87GB gebruikt. In de lokale backup gebruikt die 40GB. En ik had zoiets van "wat is hier aan de hand?!". Backup verwijderd, nieuwe sync gedaan, wederom 40GB. En toen ik hier ging typen dacht ik "zou compression niet aan staan?" en ja hoor. compressratio bevestigd het ook: 10.60x.

[small]For the curious: geen idee hoe of wat. Maar de mongod.log file behorende bij de UniFi installatie is... 38GB. Maar wat ik dan misschien wel gek vind, is dat du de daadwerkelijke size on disk laat zien? Dus een du -hs op de ZFS compressed file zegt 2,5GB, en op de niet ZFS compressed file 38GB. Dan had ik eerder verwacht dat beide 38GB zouden zijn? En alleen met zfs list etc te zien is dat er een dikke afwijking is tussen de bestandsgrotes en de grote in opslag aldus ZFS.

Edit:
(B)lijkt ook een Proxmox dingetje te zijn? Gaat om een Proxmox installatie, waarbij compression op rpool dus al aan staat.

[ Voor 3% gewijzigd door RobertMe op 23-12-2023 19:24 ]

[orvintax]

RobertMe schreef op zaterdag 23 december 2023 @ 19:23:
Ik wilde hier een WTF vraag gaan stellen, maar... de rubber duck deed perfect zijn werk

Maar om toch niet alle werk voor niks gedaan te hebben: ZFS compression doet perfect zijn werk:

robert@nas:~$ zfs get compression rpool/data/docker/data/networking tank/backup/local/docker/networking
NAME                                 PROPERTY     VALUE           SOURCE
rpool/data/docker/data/networking    compression  on              inherited from rpool
tank/backup/local/docker/networking  compression  off             default
robert@nas:~$ zfs list rpool/data/docker/data/networking tank/backup/local/docker/networking
NAME                                  USED  AVAIL     REFER  MOUNTPOINT
rpool/data/docker/data/networking    3.87G   365G     3.87G  /rpool/data/docker/data/networking
tank/backup/local/docker/networking  40.8G  1.08T     40.8G  /tank/backup/local/docker/networking

Een dataset die op de rpool / "aan live data" 3,87GB gebruikt. In de lokale backup gebruikt die 40GB. En ik had zoiets van "wat is hier aan de hand?!". Backup verwijderd, nieuwe sync gedaan, wederom 40GB. En toen ik hier ging typen dacht ik "zou compression niet aan staan?" en ja hoor. compressratio bevestigd het ook: 10.60x.

[small]For the curious: geen idee hoe of wat. Maar de mongod.log file behorende bij de UniFi installatie is... 38GB. Maar wat ik dan misschien wel gek vind, is dat du de daadwerkelijke size on disk laat zien? Dus een du -hs op de ZFS compressed file zegt 2,5GB, en op de niet ZFS compressed file 38GB. Dan had ik eerder verwacht dat beide 38GB zouden zijn? En alleen met zfs list etc te zien is dat er een dikke afwijking is tussen de bestandsgrotes en de grote in opslag aldus ZFS.

Edit:
(B)lijkt ook een Proxmox dingetje te zijn? Gaat om een Proxmox installatie, waarbij compression op rpool dus al aan staat.

Offtopic: 38GB?!! Behoud jij alle logs? Binnenkort eens kijken hoe groot die van mij is. Maar dit lijkt me wel heel erg groot.

[RobertMe]

orvintax schreef op zondag 24 december 2023 @ 15:23:
[...]

Offtopic: 38GB?!! Behoud jij alle logs? Binnenkort eens kijken hoe groot die van mij is. Maar dit lijkt me wel heel erg groot.

offtopic:
Was idd het gevolg van een fuckup waardoor die in een crash loop steeds herstartte of iets dergelijks. Container draaide al maanden niet meer. Maar heb de boel nooit opgeruimd. Om nu erachter te komen dat ik daarmee deze fuckup in stand heb gehouden.
En nog meer offtopic. Heb jaren lang de UniFi Controller lokaal gedraaid met een USG. Begin dit jaar over gestapt naar een zelfbouw router. N daarmee de controller verplaatst naar een VPS (/site verplaatst naar controller die al op VPS draaide). Daarbij was iets mis gegaan, vervolgens weer (tijdelijk) geprobeerd om de lokale aan de praat te krijgen, maar daarbij is toen de hele installatie stuk gegaan. En dan nooit gemerkt dat die log zo vol had gespamd. Container heeft vervolgens ook "nooit meer" gedraaid dus log is ook nooit opgeruimd.
Log zal effectief dus ook een dag of zo beslaan. Gaat niet om een oneindige retentie dus.

[nero355]

RobertMe schreef op zaterdag 23 december 2023 @ 19:23:
Geen idee hoe of wat. Maar de mongod.log file behorende bij de UniFi installatie is... 38GB.

Dat hele MongoDB gebeuren is wat mij betreft één groot mongool gebeuren! /Pun intended!

Ik kwam op een gegeven moment erachter dat er iets van 12 of 14 GB ongeveer aan onnodige oude (corrupte ?!) databases aanwezig waren die waarschijnlijk door de tijd heen zijn ontstaan tijdens upgrades/updates van de UniFi Controller

Gelukkig kwam ik daar achter op het moment dat er 16 van de 32 GB van de mijn microSDXC kaartje in gebruik was i.p.v. op het moment dat er geen ruimte meer over was en het geheel helemaal over de zeik is gegaan!

Echt zoo fijn dat je daar ook meldingen over krijgt... ahum...

[Nopel]

RobertMe schreef op zaterdag 23 december 2023 @ 19:23:
Maar wat ik dan misschien wel gek vind, is dat du de daadwerkelijke size on disk laat zien? Dus een du -hs op de ZFS compressed file zegt 2,5GB, en op de niet ZFS compressed file 38GB. Dan had ik eerder verwacht dat beide 38GB zouden zijn? En alleen met zfs list etc te zien is dat er een dikke afwijking is tussen de bestandsgrotes en de grote in opslag aldus ZFS.

du laat altijd de ruimte zien die een bestand echt inneemt, compressie meegerekend. Als je de 'logische' grootte wil zien, kan je du -h --apparent-size doen.

[SvMp]

Ik zit met een dilemma. Vreemd genoeg kan ik er op internet weinig over vinden.

Ik ben van plan ZFS te gebruiken met Proxmox waarbij de VM's op een mirror (raid1) bestaande uit 2 nieuwe SSD's.

Omdat er veel wordt gezegd over write amplification heb ik een experiment gedaan. Het blijkt erg mee te vallen. Ondanks dat de volblocksize op 8KB staat lijkt er geen probleem op te treden met het feit dat ext4 filesystems met 4KB blokken werken.

Ik heb write amplification gemeten met ext2 en ext4, en met ext2 treedt deze vrijwel niet op (1,0..) en met ext4 2 (2,0...). Dat is heel vreemd. Na lang puzzelen en proberen kwam ik er achter: De write amplification komt doordat de gegevens eerst naar de ZIL gaan en dan naar de schijf. Ik heb dit aangetoond door een SLOG te gebruiken, en dan is de write amplification keurig 1. Vermoedelijk wordt bij het schrijven naar het journal bij ext4 synced writes gebruikt, en daardoor komt alles in de ZIL.

Een aparte SLOG gebruiken levert geen prestatiewinst op als er met SSD's wordt gewerkt. Zonder gebruik van een SLOG bevindt de ZIL zich op de dataschijf zelf. SSD's kunnen beperkt geschreven worden. Ik wil eigenlijk niet dat er eerst naar een ZIL wordt geschreven om binnen 5 seconden de data te dupliceren. In het ideale geval wordt er alleen een link bijgewerkt, maar elk keer wordt een kopie gemaakt. Dat bevestigen alle bronnen, waaronder dit verhelderende artikel over ZIL en SLOG: https://jrs-s.net/2019/05/02/zfs-sync-async-zil-slog/

Ik heb het probleem op kunnen lossen door sync=disabled in te stellen. Er wordt dan niet naar de ZIL geschreven maar rechtstreeks naar de schijf. Dit wordt echter afgeraden.

Ik weet niet wat ik het beste kan doen.

Dit zijn de opties:

1. Accepteren dat alle schrijfacties x2 gaan

2. Afzonderlijke SSD's aanschaffen om als SLOG te dienen. Deze optie heeft niet mijn voorkeur, ik heb geen SATA-aansluitingen meer, kost nog meer geld, en het verplaatst het probleem.

3. sync=disabled wel gebruiken, eventueel met de zfs_txg_timeout op 1 seconde (ipv. 5 seconden), zodat de TXGs zo snel mogelijk worden weggeschreven.

4. Alternatieven?

[ Voor 0% gewijzigd door SvMp op 06-01-2024 11:56 . Reden: correctie raid0 -> raid1 ]

[FireDrunk]

SvMp schreef op vrijdag 5 januari 2024 @ 21:18:
Ik zit met een dilemma. Vreemd genoeg kan ik er op internet weinig over vinden.

Ik ben van plan ZFS te gebruiken met Proxmox waarbij de VM's op een mirror (raid0) bestaande uit 2 nieuwe SSD's.

Je bedoelt RAID1

Omdat er veel wordt gezegd over write amplification heb ik een experiment gedaan. Het blijkt erg mee te vallen. Ondanks dat de volblocksize op 8KB staat lijkt er geen probleem op te treden met het feit dat ext4 filesystems met 4KB blokken werken.

Ik heb write amplification gemeten met ext2 en ext4, en met ext2 treedt deze vrijwel niet op (1,0..) en met ext4 2 (2,0...). Dat is heel vreemd. Na lang puzzelen en proberen kwam ik er achter: De write amplification komt doordat de gegevens eerst naar de ZIL gaan en dan naar de schijf. Ik heb dit aangetoond door een SLOG te gebruiken, en dan is de write amplification keurig 1. Vermoedelijk wordt bij het schrijven naar het journal bij ext4 synced writes gebruikt, en daardoor komt alles in de ZIL.

Write amplification is zoals je zelf concludeerd al niet zo heel lang een issue meer. Ik ga er niet vanuit dat je top of the line iops nodig hebt, want dan moet je sowieso geen ZFS gebruiken. Dat is gewoon geen snelheidsmonster.

Een aparte SLOG gebruiken levert geen prestatiewinst op als er met SSD's wordt gewerkt. Zonder gebruik van een SLOG bevindt de ZIL zich op de dataschijf zelf. SSD's kunnen beperkt geschreven worden. Ik wil eigenlijk niet dat er eerst naar een ZIL wordt geschreven om binnen 5 seconden de data te dupliceren. In het ideale geval wordt er alleen een link bijgewerkt, maar elk keer wordt een kopie gemaakt. Dat bevestigen alle bronnen, waaronder dit verhelderende artikel over ZIL en SLOG: https://jrs-s.net/2019/05/02/zfs-sync-async-zil-slog/

ZIL is inderdaad een write (ahead) only log, en met ssds inderdaad eigenlijk overbodig. Er zijn wat uitzonderingen als je read optimized en write optimized ssds mixed.

Ik heb het probleem op kunnen lossen door sync=disabled in te stellen. Er wordt dan niet naar de ZIL geschreven maar rechtstreeks naar de schijf. Dit wordt echter afgeraden.

Als je weet wat je doet is dat geen probleem. Ik heb op bijna al mijn filesystems sync uit staan. Ergste wat er kan gebeuren is dat je de 'in-flight' data kwijt raakt. Dat is voor die filesystems voor mij geen issue.

Ik weet niet wat ik het beste kan doen.

Dit zijn de opties:

1. Accepteren dat alle schrijfacties x2 gaan

2. Afzonderlijke SSD's aanschaffen om als SLOG te dienen. Deze optie heeft niet mijn voorkeur, ik heb geen SATA-aansluitingen meer, kost nog meer geld, en het verplaatst het probleem.

3. sync=disabled wel gebruiken, eventueel met de zfs_txg_timeout op 1 seconde (ipv. 5 seconden), zodat de TXGs zo snel mogelijk worden weggeschreven.

4. Alternatieven?

Dat ligt aan je doel, gaat het je om consistentie of om performance. Als consistentie belangrijk is, kies gewoon de default en zet de recordsize op de blocksize van je VMs en zet SLOG uit. Dan haal je geen topprestaties maar blijft alles prima veilig.

Wil je iets meer snelheid zet je sync uit voor de filesystems die het kunnen hebben. Jou punt met snellere txgs kan.

Je kan ook nog overwegen een UPS te kopen, dan is de kans dat je 'in-flight' data kwijt raakt, nog weer wat kleiner.

SLOG voor een SSD pool zou ik altijd afraden.

[SvMp]

FireDrunk schreef op zaterdag 6 januari 2024 @ 08:45:
[...]

Je bedoelt RAID1

Idd. Gewijzigd

[...]

Write amplification is zoals je zelf concludeerd al niet zo heel lang een issue meer. Ik ga er niet vanuit dat je top of the line iops nodig hebt, want dan moet je sowieso geen ZFS gebruiken. Dat is gewoon geen snelheidsmonster.

Het issue is dat ik gewone consumenten SSD' s heb (870 EVO). Ik vind dubbele belasting wel degelijk een issue. Het probleem is dat ext4 op een vm voor elk bestand dat wordt geschreven sync writes naar het onderliggende device doet, wat zorg voor een voortdurende amplification x2. Performance is geen issue, gezien de upgrade vanuit een situatie met draaiende schijven.

Dat ligt aan je doel, gaat het je om consistentie of om performance. Als consistentie belangrijk is, kies gewoon de default en zet de recordsize op de blocksize van je VMs en zet SLOG uit. Dan haal je geen topprestaties maar blijft alles prima veilig.

Wil je iets meer snelheid zet je sync uit voor de filesystems die het kunnen hebben. Jou punt met snellere txgs kan.

Je kan ook nog overwegen een UPS te kopen, dan is de kans dat je 'in-flight' data kwijt raakt, nog weer wat kleiner.

SLOG voor een SSD pool zou ik altijd afraden.

Performance is niet het belangrijkste issue. Consistentie en het ontzien van de SSD. Dat laatste is geen onderwerp in documentatie over ZFS, want ze gaan uit van enterprise grade appatuur (ECC RAM + enterprise SSD's). De werkelijkheid is een goedkoop moederbordje met heel veel RAM en een verzameling goedkope SSD's.

Probleem van sync uitzetten is dat de filesystems door de vm's worden gemarkeerd als 'clean' terwijl dit alleen werkelijk het geval is als het host-systeem de gelegenheid krijgt om die transacties weg te schrijven. Volgens mij kun je daar hele nare problemen mee krijgen.

Ik heb nog wat aanvullende mogelijkheden:
- Mijn bootdisk is een 512GB NVMe SSD. Proxmox start vanaf een gewone ext4 en heeft bijna geen ruimte nodig. Ik kan deze SSD voor de helft gebruiken voor een SLOG, aangezien een pool en dus ook een SLOG ook op een partitie kan. Die SSD is een stuk sneller dan de twee EVO's. Consequentie is dat ik na een paar jaar deze misschien zal moeten vervangen, maar het kan ook meevallen.
- Op de vm's ext4 zo tunen dat er zo weinig mogelijk sync writes naar het device worden gedaan.

[ Voor 18% gewijzigd door SvMp op 06-01-2024 12:28 ]

[CurlyMo]

@SvMp andere optie is je er niet zo druk om te maken.

[A1AD]

** opgelost, zie edits onderaan **

Ik heb een standaard rpool op Debian met 2 encrypted datasets: rpool/srv en rpool/test
De srv dataset wordt manueel unlocked mbv een paswoord post boot, de test dataset heeft een unlockkey in de srv dataset. In de srv dataset komt een script dat de toekomstige datasets unlocked.

Omdat de rpool gemount wordt at boot en dus ook de srv en test datasets en het systeem vervolgens wacht op een wachtwoord prompt om verder te gaan, heb ik voor test en srv de ZFS eigenschap "canmount" op "noauto" gezet.

Ik weet niet zeker of dit de juiste manier is, maar hierna start het systeem wel volledig. srv en test worden niet gemount en er wordt niet achter een wachtwoord gevraagd.

Van wat ik kan vinden op het internet zorgt de noauto ervoor dat de datasets niet automatisch worden gemount en negeren ze het zfs mount -a command. Manueel en expliciet mounten zou nog steeds moeten werken.

Maar ik krijg de dataset niet manueel gemount. En heb een ander paar ogen nodig.

code:

ls /srv
ls: kan geen toegang krijgen tot '/srv': Bestand of map bestaat niet

zfs get some datasetinfo rpool/srv
NAME       PROPERTY    VALUE       SOURCE
rpool/srv  mountpoint  /srv        inherited from rpool
rpool/srv  keystatus  available    -
rpool/srv  mounted   no       -
rpool/srv  canmount  noauto    local

zfs mount rpool/srv 
# no error message or output

ls / -l | grep srv
drwxr-xr-x   2 root root    2 21 jan 11:54 srv

zfs get mounted rpool/srv
NAME       PROPERTY  VALUE    SOURCE
rpool/srv  mounted   no       - 

zfs list | grep srv
rpool/srv              232K   193G      232K  /srv

zfs mount | grep srv
...

Ik krijg geen foutmelding bij mounten, /srv folder staat er opeens wel, maar dataset is niet gemount.

Wat doe ik fout? Het is de eerste keer dat ik ZFS-encryptie gebruik in plaats van LUKS.

Edit: hmm lijkt op dit

So it appears that the actual fix for this problem is to load encryption keys not by running zfs load-key on the command line, but by running systemctl start zfs-load-key@<encryption root>. After that, the service is active and the mount will succeed.

Edit 2:

code:

systemctl start zfs-load-key@rpool/srv
zfs mount rpool/srv

> Is de juiste volgorde, niet echt logisch maar ok, het werkt wel...

[ Voor 15% gewijzigd door A1AD op 21-01-2024 12:22 ]

[nero355]

A1AD schreef op zondag 21 januari 2024 @ 12:02:
Edit: hmm lijkt op dit

[...]

Edit 2:

code:

systemctl start zfs-load-key@rpool/srv
zfs mount rpool/srv

> Is de juiste volgorde, niet echt logisch maar ok, het werkt wel...

Dat is dus het hele probleem tegenwoordig sinds SystemD zijn intrede heeft gemaakt :

Je wordt er steeds meer afhankelijk van, want anders worden er dingen in de verkeerde volgorde opgestart/ingeladen en krijg je allerlei rare resultaten...

Iets dergelijks ervaar ik ook met bijvoorbeeld VLAN Interfaces en ben dus ook van plan om het geheel de volgende keer helemaal via SystemD op te zetten i.p.v. DHCPCD voor het netwerk gedeelte en SystemD die OpenSSH Server en dergelijke opstart, want als je dat niet doet dan wordt het wel of niet hebben van SSH toegang een soort Russisch Roulette nadat je systeem opstart!

[RobertMe]

A1AD schreef op zondag 21 januari 2024 @ 12:02:

code:

systemctl start zfs-load-key@rpool/srv
zfs mount rpool/srv

> Is de juiste volgorde, niet echt logisch maar ok, het werkt wel...

Wat doet de systemd unit dan? I.e., wat is de output van systemctl cat zfs-load-key@rpool/srv. En dan voornamelijk de ExecStart regel (let even op dat er geen passphrase in staat, maar dat zou niet mogen). Bij mij, voor dataset rpool/user, is dat /sbin/zfs load-key "rpool/user". Met een password dat uit een pipe komt (systemd-ask-password), in een loop zit voor 5 retries, en een check vooraf zodat die niet een load probeert (naar PW vraagt) als de key al geladen is

[A1AD]

RobertMe schreef op zondag 21 januari 2024 @ 15:52:
[...]

Wat doet de systemd unit dan? I.e., wat is de output van systemctl cat zfs-load-key@rpool/srv. En dan voornamelijk de ExecStart regel (let even op dat er geen passphrase in staat, maar dat zou niet mogen). Bij mij, voor dataset rpool/user, is dat /sbin/zfs load-key "rpool/user". Met een password dat uit een pipe komt (systemd-ask-password), in een loop zit voor 5 retries, en een check vooraf zodat die niet een load probeert (naar PW vraagt) als de key al geladen is

(het is rpool/bds geworden ipv rpool/srv)

code:

ExecStart=/bin/sh -euc '[ "$$(/sbin/zfs get -H -o value keystatus "rpool/bds")" = "unavailable" ] || exit 0;for i in 1 2 3; do systemd-ask-password --id="zfs:rpool/bds" "Enter passphrase for rpool/bds:" |/sbin/zfs>

edit: nu de volledige

code:

ExecStart=/bin/sh -euc '[ "$$(/sbin/zfs get -H -o value keystatus "rpool/bds")" = "unavailable" ] || exit 0;for i in 1 2 3; do systemd-ask-password --id="zfs:rpool/bds" "Enter passphrase for rpool/bds:" |/sbin/zfs load-key "rpool/bds" && exit 0;done;exit 1'

[ Voor 14% gewijzigd door A1AD op 21-01-2024 22:02 ]

[RobertMe]

A1AD schreef op zondag 21 januari 2024 @ 19:12:
[...]


(het is rpool/bds geworden ipv rpool/srv)

code:

ExecStart=/bin/sh -euc '[ "$$(/sbin/zfs get -H -o value keystatus "rpool/bds")" = "unavailable" ] || exit 0;for i in 1 2 3; do systemd-ask-password --id="zfs:rpool/bds" "Enter passphrase for rpool/bds:" |/sbin/zfs>

Er was een pager actief waardoor de regel niet compleet is, net waar het interessant wordt. Gooi er even een | grep ExecStart achter en de pager is er ook meteen af

[A1AD]

RobertMe schreef op zondag 21 januari 2024 @ 21:55:
[...]

Er was een pager actief waardoor de regel niet compleet is, net waar het interessant wordt. Gooi er even een | grep ExecStart achter en de pager is er ook meteen af

Urgh, was me niet opgevallen, zie edit.

[RobertMe]

A1AD schreef op zondag 21 januari 2024 @ 19:12:
edit: nu de volledige

code:

ExecStart=/bin/sh -euc '[ "$$(/sbin/zfs get -H -o value keystatus "rpool/bds")" = "unavailable" ] || exit 0;for i in 1 2 3; do systemd-ask-password --id="zfs:rpool/bds" "Enter passphrase for rpool/bds:" |/sbin/zfs load-key "rpool/bds" && exit 0;done;exit 1'

Exact wat ik al schreef dus
Als de keystatus unavailable is doet die (tot 3 keer) systemd-ask-password --id="zfs:rpool/bds" "Enter passphrase for rpool/bds:" |/sbin/zfs load-key "rpool/bds". Dat effectief dus gelijk is aan cat <file met passphrase> | zfs load-key "rpool/bds" / echo -n <passphrase> | zfs load-key rpool/bds wat effectief dus weer hetzelfde zou moeten zijn als zfs load-key rpool/bds.

Enige wat ik mij dan kan bedenken: doe je de load-key als root? Of als een normale user (met delegated permissions)?

[A1AD]

RobertMe schreef op maandag 22 januari 2024 @ 08:04:
[...]
Enige wat ik mij dan kan bedenken: doe je de load-key als root? Of als een normale user (met delegated permissions)?

Beide. Hier wordt het uitgelegd.

If the dataset is encrypted and zfs-mount-generator is enabled, the generated mount unit gets a strong dependency on the generated service that loads the encryption key:

BindsTo=[e-mail]

BindsTo has the effect that the depending unit (the mount) will be stopped, if the bound service is stopped. In other words: if the zfs-load-key@ service for the mount has not been started, filesystem will be immediately unmounted by systemd.

[ Voor 40% gewijzigd door A1AD op 22-01-2024 15:15 ]

[RobertMe]

A1AD schreef op maandag 22 januari 2024 @ 15:14:
[...]


Beide. Hier wordt het uitgelegd.


[...]

Hmm, nja, ok. Dat is wel onverwacht ja. Hij faalt dus niet stilletjes maar wordt onmiddellijk geunmount.

Ergo: geen zfs mount foo/bar gebruiken, maar systemctl start foo-bar.mount. En die start dan automatisch de respectievelijke load-key service.

[ Voor 6% gewijzigd door RobertMe op 22-01-2024 15:38 ]

[jb044]

Ehm, het is wellicht een domme vraag maar is het normaal dat een scrub in eerste instantie als de brandweer gaat en dan uiteindelijk dagen bezig is met de laatste paar %?

Op dit moment is een scrub al een paar dagen bezig, in eerste instantie gaf ie aan +/- een halve dag nodig te hebben voor een RAIDZ1 array van 5 18TB Toshiba disks. En dat leek ie ook aardig waar te maken, maar nu zit ie al dagen op 97%+ en er is wel progressie maar ik zie vooral de scan en issue snelheden langzaam teruglopen en de total counters tergend langzaam wat oplopen. Voor wat het waard is het gaat om 1 pool met flink wat volumes waarvan een aantal encrypted.

[FireDrunk]

jb044 schreef op dinsdag 27 februari 2024 @ 07:45:
Ehm, het is wellicht een domme vraag maar is het normaal dat een scrub in eerste instantie als de brandweer gaat en dan uiteindelijk dagen bezig is met de laatste paar %?

Nee, eerder andersom. Begin gaat langzaam, verderop snel.

Op dit moment is een scrub al een paar dagen bezig, in eerste instantie gaf ie aan +/- een halve dag nodig te hebben voor een RAIDZ1 array van 5 18TB Toshiba disks. En dat leek ie ook aardig waar te maken, maar nu zit ie al dagen op 97%+ en er is wel progressie maar ik zie vooral de scan en issue snelheden langzaam teruglopen en de total counters tergend langzaam wat oplopen. Voor wat het waard is het gaat om 1 pool met flink wat volumes waarvan een aantal encrypted.

Wat is de status van de pool? En zitten er errors in je kernel logs over trage IO of iets in die richting?

[jb044]

code:

❯ zpool status
  pool: data
 state: ONLINE
  scan: scrub in progress since Sat Feb 24 14:03:25 2024
    47.6T / 48.9T scanned at 208M/s, 47.5T / 48.8T issued at 208M/s
    0B repaired, 97.34% done, 01:49:01 to go
config:

    NAME                                                    STATE     READ WRITE CKSUM
    data                                                    ONLINE       0     0     0
      raidz1-0                                              ONLINE       0     0     0
        wwn-0x5000039c38d210bd                              ONLINE       0     0     0
        wwn-0x5000039c18d15b17                              ONLINE       0     0     0
        wwn-0x5000039c38d165e0                              ONLINE       0     0     0
        wwn-0x5000039c38d165f0                              ONLINE       0     0     0
        wwn-0x5000039c38d165ef                              ONLINE       0     0     0
    logs
      nvme-SAMSUNG_MZ1L23T8HBLA-00A07_S667NE0T621525-part4  ONLINE       0     0     0
    spares
      scsi-SATA_TOSHIBA_MG09ACA1_53R0A02YFJDH               AVAIL

errors: No known data errors

Kan niks vinden in dmesg over io problemen, maar dat kan aan mij liggen. Hij heeft dit wel eerder gedaan en uiteindelijk voltooid ie .... met 0 errors Maar vind het nu wel erg lang duren.

[FireDrunk]

jb044 schreef op dinsdag 27 februari 2024 @ 08:36:

code:

❯ zpool status
  pool: data
 state: ONLINE
  scan: scrub in progress since Sat Feb 24 14:03:25 2024
    47.6T / 48.9T scanned at 208M/s, 47.5T / 48.8T issued at 208M/s
    0B repaired, 97.34% done, 01:49:01 to go
config:

    NAME                                                    STATE     READ WRITE CKSUM
    data                                                    ONLINE       0     0     0
      raidz1-0                                              ONLINE       0     0     0
        wwn-0x5000039c38d210bd                              ONLINE       0     0     0
        wwn-0x5000039c18d15b17                              ONLINE       0     0     0
        wwn-0x5000039c38d165e0                              ONLINE       0     0     0
        wwn-0x5000039c38d165f0                              ONLINE       0     0     0
        wwn-0x5000039c38d165ef                              ONLINE       0     0     0
    logs
      nvme-SAMSUNG_MZ1L23T8HBLA-00A07_S667NE0T621525-part4  ONLINE       0     0     0
    spares
      scsi-SATA_TOSHIBA_MG09ACA1_53R0A02YFJDH               AVAIL

errors: No known data errors

Kan niks vinden in dmesg over io problemen, maar dat kan aan mij liggen. Hij heeft dit wel eerder gedaan en uiteindelijk voltooid ie .... met 0 errors Maar vind het nu wel erg lang duren.

Met een gemiddelde snelheid van 200MB/s zou het 68h duren om je pool te scrubben, dat is niet heel ver van wat je nu haalt toch?

Misschien is sinds de wijziging dat scrubs synchro(o)n(er) geworden zijn er iets mis met de progress...
Je kan best wat tunen aan scrubs, zie hier: https://openzfs.github.io...e%20Parameters.html#scrub

Het kan zijn dat hij dus 97% van de data heeft 'gefetched', maar nog niet daadwerkelijk heeft gescrubbed.
Dan is de progressiebar misschien wat krom.

Als je in je kernel IO nog steeds gewoon 200MB/s ziet van zfs_txg (ofzoiets), zou ik hem gewoon nog lekker laten ratelen.

---
Ter referentie:

  scan: scrub repaired 0B in 11:14:51 with 0 errors on Sun Feb 11 11:39:02 2024

shenron  76.4T  27.9T  48.5T        -         -     0%    36%  1.00x    ONLINE  -

Dat is dus ~700MB/s gemiddeld over de hele scrub. 200MB/s klinkt een beetje langzaam...
Ik heb 6 schijven in RAIDZ2, zou vrijwel even snel moeten zijn als 5 in RAIDZ1, of je moet hele trage SMR schijven hebben.

[ Voor 8% gewijzigd door FireDrunk op 27-02-2024 12:15 ]

[jb044]

Die 700/800 MB is idd waar ie mee begon, disks doen max +/- 270MB/s en zijn gelukkig niet SMR. iotop doet vermoeden dat het gestagneerd is, dwz zie niet of nauwelijks activiteit op zfs processen nog. Systeem is ook niet geheel idle, maar toch zie ik een trend: hij begint heel snel en stagneert bijna op het einde.

Zal die link eens volgen straks, nu aan het werk

[jb044]

Ik zie nog wel voortgang nog, alleen heel erg laaangzaam Wat opties betreft kan me niet herinneren daar ooit actief mee geprutst te hebben, wel met de l2arc die ik eerst aan de Samsung nvme had toebedeeld en die uiteindelijk voor mijn use case toch weinig meerwaarde bleek te hebben.

[FireDrunk]

L2ARC en SLOG worden niet gebruikt in scrubs voor zover ik weet. Dus dat zou geen effect moeten hebben.

[jb044]

Het leeft weer:

code:

❯ zpool status
  pool: data
 state: ONLINE
  scan: scrub in progress since Sat Feb 24 14:03:25 2024
    48.6T / 48.9T scanned, 47.8T / 48.8T issued at 1.01G/s
    0B repaired, 97.76% done, 00:18:22 to go
config:

    NAME                                                    STATE     READ WRITE CKSUM
    data                                                    ONLINE       0     0     0
      raidz1-0                                              ONLINE       0     0     0
        wwn-0x5000039c38d210bd                              ONLINE       0     0     0
        wwn-0x5000039c18d15b17                              ONLINE       0     0     0
        wwn-0x5000039c38d165e0                              ONLINE       0     0     0
        wwn-0x5000039c38d165f0                              ONLINE       0     0     0
        wwn-0x5000039c38d165ef                              ONLINE       0     0     0
    logs
      nvme-SAMSUNG_MZ1L23T8HBLA-00A07_S667NE0T621525-part4  ONLINE       0     0     0
    spares
      scsi-SATA_TOSHIBA_MG09ACA1_53R0A02YFJDH               AVAIL

errors: No known data errors

[jb044]

Kennelijk is die counter couranter dan jij en ik dachten. Met 1GB/s gemiddeld was ie natuurlijk al lang klaar geweest

[jb044]

code:

scan: scrub repaired 0B in 3 days 03:56:49 with 0 errors on Tue Feb 27 18:00:14 2024

oftewel 187,5 MB/s gemiddeld. Het wisselt natuurlijk adhv wat ik er precies mee doe maar normaal gesproken is de zfs array veel sneller...

[jb044]

Wat ik me nog bedacht een klein gedeelte van de volumes zijn encrypted, zou dat het kunnen zijn? Andere is fragmentatie, de zfs plugin van cockpit geeft 3% aan.

[FireDrunk]

jb044 schreef op dinsdag 27 februari 2024 @ 23:24:

code:

scan: scrub repaired 0B in 3 days 03:56:49 with 0 errors on Tue Feb 27 18:00:14 2024

oftewel 187,5 MB/s gemiddeld. Het wisselt natuurlijk adhv wat ik er precies mee doe maar normaal gesproken is de zfs array veel sneller...

Encryptie maakt niets uit volgens mij, evenals fragmentatie. Die 1GB/s is 'issued', niet effectief. Dat is een beetje complex... Heeft te maken met de nieuwe manier van scrubben.
Issued is een beetje als: opgevraagd om te gaan scrubben, maar is nog niet verwerkt.

[ocaj]

Mij viel van de week op dat scrubben juist zo veel sneller is geworden.
Omdat de scrub bij mij voorheen bijna anderhalve dag duurde, de harde schijven dan druk aan het seeken waren en de ventilators op volle toeren draaiden ben ik wat terughoudender met scrubs. Vorige keer was in april 2023 en toen deed hij 200MB/s over 25,1TB, 1 dag , 11h41. Ik denk dat ik toen nog zfs 2.0.4 had.

Vorige week mijn Proxmox naar 8.1 ge-upgrade, inclusief ZFS 2.2.2. Scrub is nu echt heel veel sneller. Inmiddels zit er 28,1TB in mijn pool, maar hij was echt serieus sneller klaar, iets meer dan 1 dag, 1h46, oftewel 310MB/s. Ook waren de harde schijven nu vrijwel stil en heb ik geen fans gehoord.

Dus die nieuwe manier van scrubben waar @FireDrunk het over heeft is echt wel een hele goede verbetering !

(mijn pool draait met 3x 12TB RaidZ in een HP Microserver Gen10)

[player-x]

Heeft er iemand al gespeeld met RAIDZ Expansion, ben benieuwd wat de ervaringen er mee zijn.

[Bontje Blauw]

Greetings,

Ik ben bezig met een thuisserver en ben nog zoekende m.b.t. SSD's, HDD's, to ZFS or not.

Kan ik een ZFS pool maken van enkel SSD's of gaan die dan snel degraderen?
Kleinere 2.5" HDD's zijn SMR en ik lees dat dat niet goed werkt met ZFS of RAID opstellingen. Correct?
Is er verschil met SMR disks tussen een Mirror en een Raid pool? Kunnen SMR disks onder voorwaarden wel?
Beschikbaar is 4x SATA en beperkte ruimte (SFF);
- 3x 2.5" en 1 M.2 SATA of,
- 1x 3.5"+ 1x 2.5" + M.2 SATA

Ik heb aan 4 tot 6 TB genoeg en ik kijk nu naar 4x 2TB SSD's of 2 x 2.5" HDD's + 1 SSD en dan HDD's als mirror draaien. SSD's zou dan in RAID1 pool kunnen.

Denkrichting is nu Proxmox + Windows VM + Linux VM + NAS/data share en wat containers. En dat op een ZFS Pool vanwege data integriteit.

En heeft iedereen hier een UPS er voor hangen of op een of andere andere manier stroomuitval ondervangen?

[FireDrunk]

Bontje Blauw schreef op donderdag 11 april 2024 @ 21:34:
Greetings,

Ik ben bezig met een thuisserver en ben nog zoekende m.b.t. SSD's, HDD's, to ZFS or not.

Kan ik een ZFS pool maken van enkel SSD's of gaan die dan snel degraderen?

Dat kan prima, ZFS zorgt niet voor noemenswaardig snellere slijtage.

Kleinere 2.5" HDD's zijn SMR en ik lees dat dat niet goed werkt met ZFS of RAID opstellingen. Correct?

Het werkt wel, maar is een stuk langzamer in een aantal gevallen. Vooral scrubs en resilvers duren langer. Random IO is ook erg traag. Maar daar moet je ook geen disks voor gebruiken

Is er verschil met SMR disks tussen een Mirror en een Raid pool? Kunnen SMR disks onder voorwaarden wel?

Het kan met beide, alleen is het gewoon wat langzaam.

Beschikbaar is 4x SATA en beperkte ruimte (SFF);
- 3x 2.5" en 1 M.2 SATA of,
- 1x 3.5"+ 1x 2.5" + M.2 SATA

Ik heb aan 4 tot 6 TB genoeg en ik kijk nu naar 4x 2TB SSD's of 2 x 2.5" HDD's + 1 SSD en dan HDD's als mirror draaien. SSD's zou dan in RAID1 pool kunnen.

Misschien beginnen met een mirror van 2x4TB SSDs. Dan kan je later nog uitbreiden naar een raidz1 pool van 3 of 4 stuks.
4TB is op dit moment per TB niet veel duurder dan 2 volgens mij.

Denkrichting is nu Proxmox + Windows VM + Linux VM + NAS/data share en wat containers. En dat op een ZFS Pool vanwege data integriteit.

Proxmox is zelf ook linux, dus je kan best wat op het host os. Ik vind het altijd een beetje zonde om een hele linux vm op te tuigen voor een paar shares (als dat je plan is).
Ook dingen als Docker kunnen prima op de host.

En heeft iedereen hier een UPS er voor hangen of op een of andere andere manier stroomuitval ondervangen?

Lang niet iedereen, maar ik wel. Een vrij simpele UPS. Kost een paar watt stroomverbruik.

[willemw12]

Een pool van SSDs met redundantie (RAIDZ1 vdevs, ...) voor een thuisserver, hoe zinvol is dat? Zeker als je live/online backups hebt. Misschien vanwege performance, omdat het hier om SATA SSDs gaat?

[ Voor 8% gewijzigd door willemw12 op 14-04-2024 07:38 ]

[jb044]

Sorry, weer een vraag

Enige tijd geleden een spare ingezet om een defecte hdd te vervangen, uiteindelijk de spare definitief in de RAIDZ-1 array van 5 disks opgenomen en een nieuwe identieke hdd als spare ingezet. Eind goed al goed, dacht ik Nu viel mij op dat dit alles kennelijk een reboot niet overleefde, zpool status gaf aan dat de spare (gerefereerd als SATA_TOSHIBA_MG09ACA1_<serie nummer>) UNAVAILABLE was. Uiteindelijk de spare verwijderd, opnieuw toegevoegd met zijn disk_id en een force rebuild van /etc/zfs/zpool.cache gedaan. Nu lijkt het een reboot wel te overleven.

Vraag is in dit geval: hoe had ik het moeten doen, een nieuwe spare aan de storage pool toevoegen?

PS reden dat ik met serie nummers werk, of zou willen werken is dat het voor mij de manier was om de disks in de juiste volgorde in mijn systeem te hebben hangen. Genummerd 1 t/m 6 in mijn case, het zou wat jammer zijn als ik bij disk failure de verkeerde disk ga vervangen Serie nummers staan letter geprint op de disks zelf.

[CurlyMo]

@jb044 wat je beter kan doen is geen spare gebruiken maar standaard een hoger redundantie niveau kiezen. Dan ben je standaard beter beschermd. Behalve natuurlijk als je al op RAIDZ3 zit.

[jb044]

Wat ik online las was dat als je een serie disks tegelijk besteld, de kans dat als er 1 faalt er korte tijd later meer gaan falen vrij groot is. Vandaar raidz1 en een hot spare.

Wat ik niet durf te zeggen of online tijd anders is voor een disk dan actief gebruik.

[CurlyMo]

jb044 schreef op zaterdag 13 april 2024 @ 10:32:
Wat ik online las was dat als je een serie disks tegelijk besteld, de kans dat als er 1 faalt er korte tijd later meer gaan falen vrij groot is. Vandaar raidz1 en een hot spare.

Wat ik niet durf te zeggen of online tijd anders is voor een disk dan actief gebruik.

Je kan natuurlijk ook altijd een RAIDZ2 of 3 maken met een disk redundantie missende en deze later toevoegen. Voor het batches verhaal kan je ook je schijven bij verschillende winkels halen of met tussenpozen.

Je ondervind nu het nadeel van de voor jouw gekozen strategie.

[ Voor 5% gewijzigd door CurlyMo op 13-04-2024 11:52 ]

[Freeaqingme]

CurlyMo schreef op zaterdag 13 april 2024 @ 10:26:
@jb044 wat je beter kan doen is geen spare gebruiken maar standaard een hoger redundantie niveau kiezen. Dan ben je standaard beter beschermd. Behalve natuurlijk als je al op RAIDZ3 zit.

Kleine toevoeging daarop: Spares zijn vooral handig als je meerdere raidz's (of mirrors) hebt. Stel dat je 22 disks hebt, dan kan je 3 raidz2's maken met 1 spare. Zou er dan 1 disk stuk gaan, dan kan je die spare toevoegen aan de raidz waarvan de disk stukgegaan is.

[GioStyle]

Kan iemand mij een beetje op weg helpen?

Mijn backupstrategie is bijna compleet. Ik probeer het 3:2:1 principe te hanteren. Dat betekent dus dat ik een kopie buitenhuis' moet gaan bewaren. Dat is op zich geen probleem, maar ik wil deze schijf wel zo beveiligen dat mocht het schijfje in verkeerde handen vallen dat diegene er niets mee kan.

Nu kan je met ZFS een dataset encrypten. Bijvoorbeeld:

code:

zfs send tank/test@snap1 | zfs recv -o encryption=on -o keyformat=passphrase -o keylocation=prompt

Is het echt zo simpel?

Mijn enige doel is dat mijn dataset beveiligd is zodat een vreemde geen toegang heeft tot mijn data.

[RobertMe]

GioStyle schreef op zondag 14 april 2024 @ 18:53:
Kan iemand mij een beetje op weg helpen?

Mijn backupstrategie is bijna compleet. Ik probeer het 3:2:1 principe te hanteren. Dat betekent dus dat ik een kopie buitenhuis' moet gaan bewaren. Dat is op zich geen probleem, maar ik wil deze schijf wel zo beveiligen dat mocht het schijfje in verkeerde handen vallen dat diegene er niets mee kan.

Nu kan je met ZFS een dataset encrypten. Bijvoorbeeld:

code:

zfs send tank/test@snap1 | zfs recv -o encryption=on -o keyformat=passphrase -o keylocation=prompt

Is het echt zo simpel?

Mijn enige doel is dat mijn dataset beveiligd is zodat een vreemde geen toegang heeft tot mijn data.

Of dit comando werkt weet ik niet. Maar receiven op een destination die encrypted is zal inderdaad de encryptie on the fly toepassen.

"Nadeel" is wel dat het verkeer niet versleuteld is (tenzij je een versleuteld transport gebruikt zoals SSH, maar dan nog is de data over ee pipe niet encrypted). Wil je dat wel encrypted hebben moet de source ook encrypted zien en dan een raw send doen. Dan worden de bitjes 1-op-1 over gestuurd met behoud van encryptie en compressie etc.

[GioStyle]

RobertMe schreef op zondag 14 april 2024 @ 19:29:
[...]

Of dit comando werkt weet ik niet. Maar receiven op een destination die encrypted is zal inderdaad de encryptie on the fly toepassen.

"Nadeel" is wel dat het verkeer niet versleuteld is (tenzij je een versleuteld transport gebruikt zoals SSH, maar dan nog is de data over ee pipe niet encrypted). Wil je dat wel encrypted hebben moet de source ook encrypted zien en dan een raw send doen. Dan worden de bitjes 1-op-1 over gestuurd met behoud van encryptie en compressie etc.

Het gaat hier om een simpele externe 2.5" 5TB schijfje die ergens anders dan thuis bewaard gaat worden. Lokaal is de boel niet encrypted, maar de data op dat schijfje moet dat wel zijn, omdat het eventueel in verkeerde handen zou kunnen vallen. Ik wilde alles gaan uitproberen, maar probleem is alleen dat ik het schijfje iets te goed heb opgeborgen, ik weet niet meer waar dat ding is.

[RobertMe]

GioStyle schreef op maandag 15 april 2024 @ 20:34:
[...]


Het gaat hier om een simpele externe 2.5" 5TB schijfje die ergens anders dan thuis bewaard gaat worden. Lokaal is de boel niet encrypted, maar de data op dat schijfje moet dat wel zijn, omdat het eventueel in verkeerde handen zou kunnen vallen.

Als je de backup zelf lokaal maakt maakt de veiligheid van de overdracht niet uit inderdaad. Mijn offside backup is wel online. Maar de data die encrypted wordt opgeslagen gaat ook "raw" over de lijn.

Ik wilde alles gaan uitproberen, maar probleem is alleen dat ik het schijfje iets te goed heb opgeborgen, ik weet niet meer waar dat ding is.

Wel veilig, kan die ook niet in verkeerde handen vallen

[d3vlin]

Wellicht goed om te noemen in deze context:
https://github.com/openzfs/openzfs-docs/issues/494
https://www.reddit.com/r/...developer_for_the_native/
https://www.phoronix.com/news/OpenZFS-Encrypt-Corrupt

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

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

[ Voor 97% gewijzigd door d3vlin op 29-04-2024 09:33 ]

[RobertMe]

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

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

Ik heb zelf op twee systemen native encryption in gebruik, waarbij beide raw senden naar een remote systeem. En een van die twee is inderdaad bugged waarbij na een send potentieel een van de (bestaande) snapshots als corrupted wordt gemarkeerd. Maar dat is dan op de vage locatie <0x0>. Dus lijkt nergens te zijn? Als het snapshot verwijderd is is de error na een (dubbele*) scrub ook weer weg. Enige mij bekende probleem dat hierdoor kan ontstaan is als het laatst verzonden snapshot "corrupt" raakt. In dat geval werkt een incremental send niet meer. (Evt kan dan wel dat snapshot verwijderd worden en een send & receive (met rollback) naar het meest recente common snapshot).

* Dubbele scrub omdat het gedrag van ZFS is om errors eenmalig te "bewaren" na een scrub. En pas na de daarop volgende scrub de errors die na de vorige scrub weg waren ook niet meer worden weergegeven.

[d3vlin]

RobertMe schreef op donderdag 18 april 2024 @ 09:17:
Ik heb zelf op twee systemen native encryption in gebruik, waarbij beide raw senden naar een remote systeem.

Jammer, ik dacht dat raw (-w) juist minder (of geen) problemen gaf. Gebruik dat zelf ook al geruime tijd probleemloos. Hoe ik het nu inschat is native encryption prima te gebruiken maar kun je send/receive dus beter niet doen. Gelukkig zijn daar, alhoewel minder elegant, wel alternatieven voor.

[ Voor 26% gewijzigd door d3vlin op 22-04-2024 17:33 ]

[jurroen]

d3vlin schreef op zondag 21 april 2024 @ 10:08:
[...]


Jammer, ik dacht dat raw (-w) juist minder (of geen) problemen gaf. Gebruik dat zelf ook al geruime tijd probleemloos. Hoe ik het nu inschat is native encryption prima te gebruiken maar kun je send/receive dus beter niet doen. Gelukkig zijn daar, alhoewel minder elegant, wel alternatieven voor.

Misschien interessant leesvoer: https://arstechnica.com/g...penzfs-native-encryption/

[d3vlin]

jurroen schreef op zaterdag 27 april 2024 @ 22:38:
[...]

Misschien interessant leesvoer: https://arstechnica.com/g...penzfs-native-encryption/

Ja dat is een mooie bloemlezing van Jim (en zijn tools sanoid/syncoid zijn top). Maar dateert nog van voor de shitstorm over native encryption en send/receive.

[ Voor 5% gewijzigd door d3vlin op 29-04-2024 07:59 ]

[FireDrunk]

"Die shitstorm" viel toch achteraf gezien wel mee? Er bleek een hele oude bug in te zitten die pas gehit werd op het moment dat er een nieuwere versie van de toolchain gebruikt werd.
Achteraf gezien hebben toch maar vrij weinig mensen er last van gehad?

In elke software ontstaan bugs en als je niet te aggressief de laatste versie gebruikte heb je de bug helemaal nooit in je code gehad?

[RobertMe]

FireDrunk schreef op maandag 29 april 2024 @ 08:21:
"Die shitstorm" viel toch achteraf gezien wel mee? Er bleek een hele oude bug in te zitten die pas gehit werd op het moment dat er een nieuwere versie van de toolchain gebruikt werd.
Achteraf gezien hebben toch maar vrij weinig mensen er last van gehad?

Volgens mij verwijs je nu naar een bug die helemaal niks met native encryption te maken heeft maar een algemeen issue was / leek met ZFS 2.2

[FireDrunk]

RobertMe schreef op maandag 29 april 2024 @ 09:03:
[...]

Volgens mij verwijs je nu naar een bug die helemaal niks met native encryption te maken heeft maar een algemeen issue was / leek met ZFS 2.2

ah, zou kunnen. Ik zie idd best wat turmoil over native encryption. Ik gebruik het zelf nu denk ik een jaar zonder issues. Inclusief syncoid auto backup offsite.

Restore test moeten we wel nog een keer doen

[RobertMe]

FireDrunk schreef op maandag 29 april 2024 @ 20:17:
[...]

ah, zou kunnen. Ik zie idd best wat turmoil over native encryption. Ik gebruik het zelf nu denk ik een jaar zonder issues. Inclusief syncoid auto backup offsite.

Nouja, ik heb dus een systeem dat met Proxmox 6 of 7 is begonnen (denk 6, vrij direct daarna kwam 7 uit en geupgrade) en daarop werkt native encryption dik prima. Vorig jaar een systeem met Debian Bookworm opgetuigd, en die heeft dus issues. Regelmatig dat na een send de metadata van een snapshot corrupt is waarna daarop volgende sends ook weer falen. Niet fataal (tot nu toe ), en het corrupte snapshot kan "gewoon" gedestroyed worden (wat bij frequent & hourly snapshots dus sowieso regelmatig gebeurt) waarna de eventueel gevaalde syncs weer worden ingehaald. En na een (dubbele) scrub zie je er niks meer van.

[GioStyle]

Ondertussen heb ik mijn backupschijfje gevonden.

En met onderstaande regel kan ik mijn datasets encrypted bewaren:

code:

zfs send tank1/test@snap1 | zfs recv tank2/backup_encypted -o encryption=on -o keyformat=passphrase -o 
keylocation=file:///keyfile

Ik had eerder 'keylocation=prompt' gebruikt, maar dat gaf een foutmelding.

[ph0t0nix]

Die foutmelding kwam waarschijnlijk door het feit dat stdin in dit geval al bezet is (vanwege de pipe). Daardoor kan de prompt geen input lezen.

[GioStyle]

ph0t0nix schreef op dinsdag 7 mei 2024 @ 20:36:
Die foutmelding kwam waarschijnlijk door het feit dat stdin in dit geval al bezet is (vanwege de pipe). Daardoor kan de prompt geen input lezen.

Dat is correct.

[d3vlin]

GioStyle schreef op dinsdag 7 mei 2024 @ 19:40:
Ondertussen heb ik mijn backupschijfje gevonden.

En met onderstaande regel kan ik mijn datasets encrypted bewaren:

code:

zfs send tank1/test@snap1 | zfs recv tank2/backup_encypted -o encryption=on -o keyformat=passphrase -o 
keylocation=file:///keyfile

Ik had eerder 'keylocation=prompt' gebruikt, maar dat gaf een foutmelding.

Bewaren wel, maar zo gaat de data dus unencrypted over de pijp (pun intended ). Dat is nou net het mooie van raw (-w).

[GioStyle]

d3vlin schreef op donderdag 9 mei 2024 @ 12:11:
[...]


Bewaren wel, maar zo gaat de data dus unencrypted over de pijp (pun intended ). Dat is nou net het mooie van raw (-w).

I get that, maar in mijn geval is dat niet zo relevant. Er wordt lokaal een backup gemaakt van datasets die niet encrypted zijn.

[ocaj]

Ik heb een vreemd probleem. Ik maak met enige regelmaat backups van mijn proxmox-server op losse USB-schijven.

Ik had laatst weer een nieuwe schijf in gebruik genomen, daar keurig een initële backup op gemaakt (diverse zfs send/receive). Nu wil ik weer een incrementele backup maken, maar hij ziet de hele schijf niet echt meer.

Schijf wordt herkend door het OS. gdisk laat ook keurig zien dat er 1 ZFS-partitie op staat:

code:

root@pve:~# gdisk -l /dev/sde
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sde: 9767541167 sectors, 4.5 TiB
Model: Expansion HDD   
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 137BDFEA-2D4B-2F45-B863-22297C629928
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 9767541133
Partitions will be aligned on 2048-sector boundaries
Total free space is 2412 sectors (1.2 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      9767524351   4.5 TiB     BF01  zfs-8987df3e2b647561
   9      9767524352      9767540735   8.0 MiB     BF07

Normaal is het een kwestie van "zpool import backup", maar dan ziet hij de pool niet.
Met zpool import -s zie ik hem wel:

code:

root@pve:~# zpool import -s
   pool: backup
     id: 5444492203842587287
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

    backup      ONLINE
      sde       ONLINE
root@pve:~# zpool import backup
cannot import 'backup': no such pool available
root@pve:~# zpool import 5444492203842587287
cannot import '5444492203842587287': no such pool available

De suggesties van zpool import -s dat hij zowel op naam als op identifier te importeren zou zijn werkt helaas niet.
Iemand enig idee wat hier aan de hand is en wat ik er aan kan doen?

[ph0t0nix]

Vreemd... Lukt het wel om deze pool op een andere machine te importeren?

Of expliciet de optie

code:

-d /dev/sde

meegeven?

[ocaj]

Nee, dat lukt ook niet. Maar net kwam ik er achter dat het wél lukt als ik /dev/sde1 gebruik, dus rechtstreeks de zfs-partitie ipv het hele device.
Voor de zekerheid loopt er nu even een scrub, om te kijken of de data ok is.

Nog nooit eerder meegemaakt.
Ik maak mijn backupschijven altijd aan met een simpel "zpool create backup sde". zpool regelt dan de partitionering en tot nu toe kon ik ze altijd gewoon importeren met een "zpool import backup".

Volgende week eens testen met een andere backup-schijf die ik recent gemaakt heb. (zijn mijn offsite-backups die in mijn locker op mijn werk liggen en die ik met enige regelmaat mee naar huis neem om te updaten)

[The-Source]

Ik ga mij binnenkort (als alle hardware gaat werken ) ook begeven in de ZFS + Proxmox VE wereld.
En nu is mijn plan om boot / VM's van een M2 NVME 2TB te laten draaien.
Daarbij een 8x 12TB RAID-Z2 data pool (dus 72TB unformatted)
Betreft een thuis situatie en eigenlijk niet extreem veel load verwacht maar wellicht dat ik ook nog wel met Ollama (AI) bezig ga.
Is het verstandig om een deel van de M2 (gen4 x4) te reserveren voor L2ARC? Server krijgt voorlopig 64GB ecc RAM en het wordt dus niet mogelijk om 1GB ram per TB schijf ruimte aan te houden. Zat meer aan 400MB per TB te denken. Is dat te weinig of zou het zelf nog minder mogen?

[nero355]

The-Source schreef op donderdag 13 juni 2024 @ 14:01:
Ik ga mij binnenkort (als alle hardware gaat werken ) ook begeven in de ZFS + Proxmox VE wereld.

Noem eens al die hardware op dan

En nu is mijn plan om boot / VM's van een M2 NVME 2TB te laten draaien.

Is het verstandig om een deel van de M2 (gen4 x4) te reserveren voor L2ARC?

Ik zou dat lekker opsplitsen

Daarbij een 8x 12TB RAID-Z2 data pool (dus 72TB unformatted)

LEKKER!!!

Server krijgt voorlopig 64GB ecc RAM en het wordt dus niet mogelijk om 1GB ram per TB schijf ruimte aan te houden.
Zat meer aan 400MB per TB te denken.

Is dat te weinig of zou het zelf nog minder mogen?

Zou ik me niet druk om maken, tenzij je van plan bent Deduplication te gaan gebruiken!

[Streamert]

The-Source schreef op donderdag 13 juni 2024 @ 14:01:
Ik ga mij binnenkort (als alle hardware gaat werken ) ook begeven in de ZFS + Proxmox VE wereld.
En nu is mijn plan om boot / VM's van een M2 NVME 2TB te laten draaien.
Daarbij een 8x 12TB RAID-Z2 data pool (dus 72TB unformatted)
Betreft een thuis situatie en eigenlijk niet extreem veel load verwacht maar wellicht dat ik ook nog wel met Ollama (AI) bezig ga.
Is het verstandig om een deel van de M2 (gen4 x4) te reserveren voor L2ARC? Server krijgt voorlopig 64GB ecc RAM en het wordt dus niet mogelijk om 1GB ram per TB schijf ruimte aan te houden. Zat meer aan 400MB per TB te denken. Is dat te weinig of zou het zelf nog minder mogen?

Persoonlijk zou ik, en ik ken jouw budget uiteraard niet, voor een mirror van 2 X NVME-SSD's gaan, dat is performance technisch en uit redundantie een betere keuze. Met 64 GB RAM heb je m.i. niet perse L2ARC nodig. Mocht dit wel zo zijn, kun je altijd nog een een 1TB M2 reepje toevoegen. Wat betreft je 12TB pool, zou ik kiezen voor RAIDZ of RAIDZ2. Voor backup kun je een goedkoop pc'tje gebruiken met bijv. 1 of 2 HD's en met ZFS send/receive.

[The-Source]

nero355 schreef op donderdag 13 juni 2024 @ 15:30:
[...]

Noem eens al die hardware op dan


Zou ik me niet druk om maken, tenzij je van plan bent Deduplication te gaan gebruiken!

AMD 8700g met ASUS Prime X670 mobo.
Maar gecombineerd met de ECC ram (2x 32GB) ging hij zelfs niet booten met 1 DIMM erin. Vandaag komt er een nieuwe PSU binnen om de oudere PSU uit te sluiten. Dus eerst booten is stap 1, dan een dag ofzo memtest draaien voordat er ook maar iets geïnstalleerd gaat worden.

Dedup ga ik niet gebruiken, ook al zal het vast wat ruimte gaan besparen, weet ik dat ik op file niveau weinig /geen duplicaten heb. Natuurlijk werkt dedup op bit / sector niveau maar dan nog vind ik het niet nodig om de investering die je aan ram kwijt ben te verantwoorden.
HDD's 8x Seagate Exos X12 ST12000NM012712TB SED 512e (hebben drive encryptie maar daarvoor niet gekocht, maar was gewoon goede prijs)
Deze disks mag je overigens "onbeperkt aantal" in 1 chassis stoppen.

[dylan111111]

The-Source schreef op donderdag 13 juni 2024 @ 15:51:
[...]

AMD 8700g met ASUS Prime X670 mobo.
Maar gecombineerd met de ECC ram (2x 32GB) ging hij zelfs niet booten met 1 DIMM erin. Vandaag komt er een nieuwe PSU binnen om de oudere PSU uit te sluiten. Dus eerst booten is stap 1, dan een dag ofzo memtest draaien voordat er ook maar iets geïnstalleerd gaat worden.

Dedup ga ik niet gebruiken, ook al zal het vast wat ruimte gaan besparen, weet ik dat ik op file niveau weinig /geen duplicaten heb. Natuurlijk werkt dedup op bit / sector niveau maar dan nog vind ik het niet nodig om de investering die je aan ram kwijt ben te verantwoorden.
HDD's 8x Seagate Exos X12 ST12000NM012712TB SED 512e (hebben drive encryptie maar daarvoor niet gekocht, maar was gewoon goede prijs)
Deze disks mag je overigens "onbeperkt aantal" in 1 chassis stoppen.

Deduplication kan je wel flink wat ruimte gaan besparen. Ik bewaar backups 31 dagen van 12 lxc containers en 3 vm's. Nu zijn de VM's 32GB en de LXC van 500MB tot 10GB en veranderd er niet super veel op een dag maar het bespaard wel veel opslag ruimte op deze manier.

In plaats van 39GB zou het anders 2142GB aan ruimte in nemen.

[orvintax]

dylan111111 schreef op donderdag 13 juni 2024 @ 16:14:
[...]


Deduplication kan je wel flink wat ruimte gaan besparen. Ik bewaar backups 31 dagen van 12 lxc containers en 3 vm's. Nu zijn de VM's 32GB en de LXC van 500MB tot 10GB en veranderd er niet super veel op een dag maar het bespaard wel veel opslag ruimte op deze manier.

In plaats van 39GB zou het anders 2142GB aan ruimte in nemen.

[Afbeelding]

Als ik me niet vergis heeft OP het over dedup op ZFS niveaeu. De Proxmox Backup Server (PBS) dedup is wat anders en werkt niet op dat niveau.

[The-Source]

Inderdaad zfs dedup is zover ik het begrijp wat ik gelezen heel erg memory afhankelijk en eenmaal aan kan je het niet zonder data behoud weer uitzetten. Maar correct me if I'm wrong
System gaat nu even een uurtje is 20 memtest draaien en dan maar eens zien wat of dat goed is gegaan.

[d3vlin]

Voor zfs dedup wil je naast voldoende ram (arc) vooral een special vdev op nvme voor de ddt. 50+TB aan data met ~1.5 dedup ratio gaat prima met 256GB ram (minder ook wel denk ik) en 1TB aan special vdev.

Met dedup opgeslagen data blijft gededupliceerd als je dedup daarna weer uit zet. Om de data weer ongededupliceerd (gedupliceerd? ) op te slaan moet je een nieuwe vdev aanmaken en de data daarheen zfs senden, daarna de vdev met dedup data verwijderen.

Inderdaad goed afwegen of je use case opweegt tegen de extra overhead, maar het kan zeker.

[ Voor 61% gewijzigd door d3vlin op 14-06-2024 05:39 ]

[nero355]

The-Source schreef op donderdag 13 juni 2024 @ 15:51:
AMD 8700g met ASUS Prime X670 mobo.
Maar gecombineerd met de ECC ram (2x 32GB) ging hij zelfs niet booten met 1 DIMM erin. Vandaag komt er een nieuwe PSU binnen om de oudere PSU uit te sluiten. Dus eerst booten is stap 1, dan een dag ofzo memtest draaien voordat er ook maar iets geïnstalleerd gaat worden.

AMD en ECC i.c.m. zulke hardware is wat mij betreft nog steeds niet echt helemaal 100% zeker weten uiteindelijk ook daadwerkelijk ECC functionaliteit hebben en combineer dat nog eens met de kieskeurigheid van ASUS moederborden wat RAM modules betreft en je hebt één groot feest...

Dedup ga ik niet gebruiken, ook al zal het vast wat ruimte gaan besparen, weet ik dat ik op file niveau weinig /geen duplicaten heb. Natuurlijk werkt dedup op bit / sector niveau maar dan nog vind ik het niet nodig om de investering die je aan ram kwijt ben te verantwoorden.

Zeg ook niet dat je het moet doen, maar puur waarom je het gerust kan negeren

HDD's 8x Seagate Exos X12 ST12000NM012712TB SED 512e (hebben drive encryptie maar daarvoor niet gekocht, maar was gewoon goede prijs)

Het is dat je ze al hebt, maar heel eerlijk gezegd zou ik nooit voor Seagate kiezen en al helemaal niet voor modellen met NM in hun modelcode en HDD's die 512e doen zou ik ook negeren...

Deze disks mag je overigens "onbeperkt aantal" in 1 chassis stoppen.

Sinds wanneer is dat een ding


"Last but not least..."

Welke SSD's was je van plan te gaan gebruiken ??

[The-Source]

nero355 schreef op donderdag 13 juni 2024 @ 22:27:
[...]

AMD en ECC i.c.m. zulke hardware is wat mij betreft nog steeds niet echt helemaal 100% zeker weten uiteindelijk ook daadwerkelijk ECC functionaliteit hebben en combineer dat nog eens met de kieskeurigheid van ASUS moederborden wat RAM modules betreft en je hebt één groot feest...


[...]

Zeg ook niet dat je het moet doen, maar puur waarom je het gerust kan negeren


[...]

Het is dat je ze al hebt, maar heel eerlijk gezegd zou ik nooit voor Seagate kiezen en al helemaal niet voor modellen met NM in hun modelcode en HDD's die 512e doen zou ik ook negeren...


[...]

Sinds wanneer is dat een ding


"Last but not least..."

Welke SSD's was je van plan te gaan gebruiken ??

Ok lekker positief allemaal, maar RAM van de support lijst gehaald en ja Asus heeft daar heel weinig ecc ram als getest erop staan kwam ik achter.
Deze 'ssd' uitvoering: Transcend 250S 2TB
De data die ik naar deze server ga schrijven is grotendeels 1 malig. VMs die ik wil ga draaien wil ik wel op de m2 hebben. Backups hiervan weer p de disks.
Deze specifieke schijven komen overigens heel erg goed uit de rapporten van datacentra mbt uitval. Dat geld niet per definitie grotere of kleinere formaten uit dezelfde serie.
En je moet eens in de specs duiken van hdd's wat ik voorheen ook niet staat maar wel sinds kort is dat een hoop "nas" schijven maar maximaal 8 stuks in 1 cabinet/ behuizing mogen zitten omdat de disk anders gaat resoneren met een andere schijf.
De Seagate exos lijn kan zijn spin snelheid blijkbaar niet in vaste stappen maar "onbeperkt" veranderen

[silverball]

nero355 schreef op donderdag 13 juni 2024 @ 22:27:
[...]

AMD en ECC i.c.m. zulke hardware is wat mij betreft nog steeds niet echt helemaal 100% zeker weten uiteindelijk ook daadwerkelijk ECC functionaliteit hebben en combineer dat nog eens met de kieskeurigheid van ASUS moederborden wat RAM modules betreft en je hebt één groot feest...

Dit is inderdaad zo vreselijk jammer aangezien Zen dit wel ondersteund in principe. Mijn bordje ook; in de handleiding staat dat ECC ondersteund is, in de UEFI kan het aangezet worden, het werkt niet, ASsrock zegt dat er geen formele ondersteuning voor is en helpt mij niet.

ECC hoort gewoon bij een workstation IMO, het zou fijn zijn dat dit gewoon werkt met comsumer/ prosumer hardware.

[nero355]

The-Source schreef op donderdag 13 juni 2024 @ 23:18:
Ok lekker positief allemaal

Tja, sorry, maar je hebt gewoon de verkeerde hardware gekozen IMHO

Deze 'ssd' uitvoering: Transcend 250S 2TB

VMs die ik wil ga draaien wil ik wel op de m2 hebben.

Dat is dus ook een SSD die het met een beetje pech niet lang gaat uithouden i.c.m. zulk gebruik !!

Zoek eerdere adviezen op zowel in dit topic als het Proxmox Topic en overweeg één of meerdere van die modellen te kopen

En je moet eens in de specs duiken van hdd's wat ik voorheen ook niet staat maar wel sinds kort is dat een hoop "nas" schijven maar maximaal 8 stuks in 1 cabinet/ behuizing mogen zitten omdat de disk anders gaat resoneren met een andere schijf.
De Seagate exos lijn kan zijn spin snelheid blijkbaar niet in vaste stappen maar "onbeperkt" veranderen

Interessant! Thnx!

silverball schreef op vrijdag 14 juni 2024 @ 10:25:
Dit is inderdaad zo vreselijk jammer aangezien Zen dit wel ondersteund in principe. Mijn bordje ook; in de handleiding staat dat ECC ondersteund is, in de UEFI kan het aangezet worden, het werkt niet, ASsrock zegt dat er geen formele ondersteuning voor is en helpt mij niet.

ECC hoort gewoon bij een workstation IMO, het zou fijn zijn dat dit gewoon werkt met comsumer/ prosumer hardware.

Wat dat betreft vind ik het ook vreselijk jammer dat hardware in het algemeen bizar duurder is geworden en je niet meer een beetje leuk HEDT/Server/Workstation spul kan aanschaffen voor relatief normale prijzen...

[Raven]

nero355 schreef op donderdag 13 juni 2024 @ 22:27:
[...]

Het is dat je ze al hebt, maar heel eerlijk gezegd zou ik nooit voor Seagate kiezen en al helemaal niet voor modellen met NM in hun modelcode en HDD's die 512e doen zou ik ook negeren...

En wat als je met hba's zit die van voor het 4k era zijn? Dan heb je niet veel keus dan 512n/512e.

NM ...... "Nearline" aldus Google?

[nero355]

Raven schreef op vrijdag 14 juni 2024 @ 17:17:
En wat als je met hba's zit die van voor het 4k era zijn? Dan heb je niet veel keus dan 512n/512e.

Alles vanaf de 2008 dan wel de 2308 moet dat toch gewoon aan kunnen

Desnoods nadat je de firmware hebt geüpgrade naar de laatste versie ?!

[Raven]

nero355 schreef op vrijdag 14 juni 2024 @ 19:00:
[...]

Alles vanaf de 2008 dan wel de 2308 moet dat toch gewoon aan kunnen

Desnoods nadat je de firmware hebt geüpgrade naar de laatste versie ?!

Perc H310's (heb ik hier liggen voor nog steeds niet afgemaakte diy-NAS) ondersteund dat volgens veel bronnen niet, al beweert een enkeling van wel

Wat is er overigens mis met NM drives?

[nero355]

Raven schreef op vrijdag 14 juni 2024 @ 19:12:
Perc H310's (heb ik hier liggen voor nog steeds niet afgemaakte diy-NAS) ondersteund dat volgens veel bronnen niet, al beweert een enkeling van wel

Tot nu toe niks over gelezen eerlijk gezegd, maar de H310 van Dell is op een 2008 gebaseerd geloof ik en die is ondertussen behoorlijk oud geworden dus misschien tijd om minimaal een 2308 of 3008 te gebruiken ?!

Wat is er overigens mis met NM drives?

Elke extreme uitval waarbij Seagate HDD's betrokken waren had NM in de codenaam/modelnaam of hoe je dat ook noemt dus ik ben daar niet echt een voorstander van ondertussen...

[Raven]

nero355 schreef op zaterdag 15 juni 2024 @ 14:22:
[...]

Tot nu toe niks over gelezen eerlijk gezegd, maar de H310 van Dell is op een 2008 gebaseerd geloof ik en die is ondertussen behoorlijk oud geworden dus misschien tijd om minimaal een 2308 of 3008 te gebruiken ?!

Mwah, als ze werken, plus er zijn genoeg 512e drives.

nero355 schreef op zaterdag 15 juni 2024 @ 14:22:
[...]

Elke extreme uitval waarbij Seagate HDD's betrokken waren had NM in de codenaam/modelnaam of hoe je dat ook noemt dus ik ben daar niet echt een voorstander van ondertussen...

Ah op die manier. Maar staat NM dan ook gelijk aan Exos / NAS-specifieke drives?

[nero355]

Raven schreef op zaterdag 15 juni 2024 @ 17:36:
Maar staat NM dan ook gelijk aan Exos / NAS-specifieke drives?

Bestond al voordat ze met die naamgeving kwamen en zelfs nog voordat er opeens NAS specifieke HDD's op de markt verschenen IIRC

Overigens vind ik dat hele "NAS HDD's gedoe" ook maar een beetje onzin en is denk ik meer op de markt gekomen toen er opeens flink werd gesjoemeld met HDD's qua wat er precies in zat aan hardware...

[The-Source]

nero355 schreef op zaterdag 15 juni 2024 @ 17:57:
[...]

Bestond al voordat ze met die naamgeving kwamen en zelfs nog voordat er opeens NAS specifieke HDD's op de markt verschenen IIRC

Overigens vind ik dat hele "NAS HDD's gedoe" ook maar een beetje onzin en is denk ik meer op de markt gekomen toen er opeens flink werd gesjoemeld met HDD's qua wat er precies in zat aan hardware...

Dat nas schijven heeft dus met meer zaken te maken. Zoals ook het aantal schijven per behuizing. Meeste nas schijven hebben een maximum 8 of hoger. Datacenter editie schijven van al snel naar 24 of hoger. De genoemde exos is categorie datacenter. Dat daar dan ook NM in artikel naam zit zegt niets over de rest van de schijf.

[nero355]

The-Source schreef op zaterdag 15 juni 2024 @ 20:08:
Dat nas schijven heeft dus met meer zaken te maken. Zoals ook het aantal schijven per behuizing. Meeste nas schijven hebben een maximum 8 of hoger. Datacenter editie schijven van al snel naar 24 of hoger. De genoemde exos is categorie datacenter. Dat daar dan ook NM in artikel naam zit zegt niets over de rest van de schijf.

Ik hoop het voor je in dit geval, maar ik blijf er liever zo ver mogelijk bij vandaan!

[e-unlimited]

The-Source schreef op donderdag 13 juni 2024 @ 15:51:
[...]

AMD 8700g met ASUS Prime X670 mobo.
Maar gecombineerd met de ECC ram (2x 32GB) ging hij zelfs niet booten met 1 DIMM erin. Vandaag komt er een nieuwe PSU binnen om de oudere PSU uit te sluiten. Dus eerst booten is stap 1, dan een dag ofzo memtest draaien voordat er ook maar iets geïnstalleerd gaat worden.

Dedup ga ik niet gebruiken, ook al zal het vast wat ruimte gaan besparen, weet ik dat ik op file niveau weinig /geen duplicaten heb. Natuurlijk werkt dedup op bit / sector niveau maar dan nog vind ik het niet nodig om de investering die je aan ram kwijt ben te verantwoorden.
HDD's 8x Seagate Exos X12 ST12000NM012712TB SED 512e (hebben drive encryptie maar daarvoor niet gekocht, maar was gewoon goede prijs)
Deze disks mag je overigens "onbeperkt aantal" in 1 chassis stoppen.

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

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

[jurroen]

nero355 schreef op zaterdag 15 juni 2024 @ 21:54:
[...]

Ik hoop het voor je in dit geval, maar ik blijf er liever zo ver mogelijk bij vandaan!

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