[Sammelthread] ZFS Stammtisch

[gea]

Das Menü macht kein einfaches zfs list sondern wertet für Dateisysteme iSCSI, rsync, s3, acl und weiteres mit aus. Das ist was dauert

 

[kandamir]

So, mal noch eine kurze Rückmeldung. Ich habe am Wochenende den Server noch einmal komplett herunter, um die SATA-Anschlüsse zu prüfen. Mit der Folge, dass danach keine einzige VM mehr starten wollte (es konnte keine Verbindung zur VM aufgebaut werden). Ich habe Stunden damit verbracht, das zu analysieren. Ich war schon kurz davor, ESXi neu zu installieren. Letzter Versuch nach zweimaligem Ausschalten + Server stromlos machen - und die VMs starteten wieder einwandfrei. Und was soll ich sagen: seither ist der Zugriff auf die Pool-Übersicht oder die Filesysteme wieder in ordentlicher Zeit da. Keine Ahnung, was der Kiste quer im Magen lag. Sowas mag ich ja gar nicht, Probleme, die kommen und gehen, ohne dass man erkennen könnte, warum… Napp-It war jedenfalls nicht schuld, sondern offenbar das Blech... 😉

 

[ludwinator]

Du hastest ja im März schon so komische Effekte nach dem ausschalten denk ich, was ist denn da für ne Hardware drunter?
Also Mainboard, Controller etc?

 

[kandamir]

Das Übertragen "sonstiger" Snaps kann Probleme machen. Normalerweise erstellt man mit keep und hold auf dem Ziel eine eigene Snapshot retension policy z.B. je Tag 24 snaps, je woche/monat/jahr xx snaps oder behalte letzte 7 Tage oder letzte 20 Snaps.

Könntest Du darauf bitte noch einmal näher eingehen? „Sonstige“ Snaps sind dann solche Snaps, die nicht vom Replikationsjob erstellt werden? Davon habe ich durchaus einige. Wie spielt das zusammen mit Snaps, die durch einen Autosnap Job erstellt wurden? Szenario wäre ja: Autosnap erstellt häufig und viele Snaps, um versehentlich durchgeführte Veränderungen rückgängig machen zu können. Replikationsjobs für Backup werden hingegen in geringerer Frequenz durchgeführt, als die Autosnap Jobs. Führt das bei Replikationsjobs dann zu Problemen? Und wie ist das dann bei hold/keep in den Replikationsjobs? Wenn nur die letzten x pro Tag/Woche/Monat/Jahr gehalten werden - werden die ältesten dann mit der nächsten Replikation gelöscht? Und was würde mit den Snaps aus dem o.g. Autosnap Job passieren, die ggf. länger leben sollen? Verschwinden die mit dem entfernen eines Replikations-Snaps, der seine Halbwertszeit überschritten hat? Bzw. bleibt die Integrität der Snapshot-Kette dann noch erhalten, wenn ein solcher Snap gelöscht wurde? Also

Manueller-Snap1
Replikations-Snap (veraltetet) -> wird gelöscht
Manueller-Snap2

Sorry für die vielen Fragen…

Beitrag automatisch zusammengeführt: Mittwoch um 08:53

Du hastest ja im März schon so komische Effekte nach dem ausschalten denk ich, was ist denn da für ne Hardware drunter?
Also Mainboard, Controller etc?

Will ich nicht ausschließen. Hardware siehe System in meinem Profil - sollte gepflegt sein. 😉

 

[ludwinator]

OK, also bei der Hardware musst du schon mal damit rechnen, das es so komische Effekte gibt.
Elektronik altert einfach.

 

[kandamir]

Das einzige Fehlverhalten, was ich ggf. auf Hardware schieben würde, wäre das im März berichtete nicht herunterfahren wollen der Napp-It VM. Ich denke inzwischen, dass der damalige Datenverlust des Paperless Docker Containers eher ein Docker Problem war (was ich zugegebenermaßen aber noch nicht verstanden habe…).

Ansonsten zur Hardware selbst: ja, nicht mehr die Jüngste, Spinnweben sind aber noch keine dran und weggerostet ist auch noch nix. 😅 Aber vielleicht sollte ich nach 7 Jahren tatsächlich mal über einen Hardware Refresh nachdenken… Ich werde mal ein wenig stöbern…

 

[gea]

Könntest Du darauf bitte noch einmal näher eingehen? „Sonstige“ Snaps sind dann solche Snaps, die nicht vom Replikationsjob erstellt werden? Davon habe ich durchaus einige. Wie spielt das zusammen mit Snaps, die durch einen Autosnap Job erstellt wurden? Szenario wäre ja: Autosnap erstellt häufig und viele Snaps, um versehentlich durchgeführte Veränderungen rückgängig machen zu können. Replikationsjobs für Backup werden hingegen in geringerer Frequenz durchgeführt, als die Autosnap Jobs. Führt das bei Replikationsjobs dann zu Problemen? Und wie ist das dann bei hold/keep in den Replikationsjobs? Wenn nur die letzten x pro Tag/Woche/Monat/Jahr gehalten werden - werden die ältesten dann mit der nächsten Replikation gelöscht? Und was würde mit den Snaps aus dem o.g. Autosnap Job passieren, die ggf. länger leben sollen? Verschwinden die mit dem entfernen eines Replikations-Snaps, der seine Halbwertszeit überschritten hat? Bzw. bleibt die Integrität der Snapshot-Kette dann noch erhalten, wenn ein solcher Snap gelöscht wurde? Also

Recursive Replikation überträgt alle datasets (auch tieferliegende Dateisysteme, Zvols, Snaps). Das kann manchmal Probleme bereiten wenn man nach der Erstreplikation erwas ändert. Replikations Snaps werden nach der Übertragung umbenannt (mit Hinweis auf die Regel um den Snap zu behalten)

Einfach ausprobieren.

 

[gea]

ZFS Anyraid
Status: Projektidee

Idee: ZFS vdev aus Platten unterschiedlicher Kapazität
Zunächst für Mirrors, dann Raid-Z.

Umsetzung: Klarasystems (waren verantwortlich für OpenZFS Fast Dedup)

Ziel: bessere Nutzung der Kapaazität, kleinste Platte bestimmt nicht mehr die vdev-Größe
also was Richtung Echtzeit Unraid oder Synology SHR

Introducing ZFS AnyRaid, Sponsored by Eshtek — HexOS

At the beginning of this year, we made the decision to invest a substantial chunk of capital to support an open source project for which we have great personal interest. ZFS AnyRaid will give users the ability to mix different sized drives in a pool, a highly-requested feature since our la

hexos.com

https://docs.google.com/document/d/1qRzDdaFujXZCeO0ZGVkhuNLWk8kBdjTiedvb0PiHR98/edit?pli=1&tab=t.0