ZFS scrubbing bei virtuellem PBS

[herzkerl]

Wie sinnvoll ist es, das ZFS scrubbing in einem virtualisierten PBS (auf Proxmox VE – in unserem Fall via Ceph, bei unseren Kunden via ZFS) in der VM ebenfalls laufen zu lassen? Da sollte doch von "außen" schon alles soweit passen, dass man sich die Ressourcen dafür sparen kann, oder irre ich mich?

 

[dcsapak]

wenn es außerhalb ein zfs/ceph gibt, würde ich nicht empfehlen in der vm ein zfs zu verwenden. cow fs auf cow fs macht alles sehr langsam + die write amplification multipliziert sich
verify drin würde ich dann trotzdem laufen lassen (auch ein zfs/ceph kann mal kaputt gehen, zb bit rot)

 

[herzkerl]

wenn es außerhalb ein zfs/ceph gibt, würde ich nicht empfehlen in der vm ein zfs zu verwenden. cow fs auf cow fs macht alles sehr langsam + die write amplification multipliziert sich

Also dem virtuellen PBS lieber eine neue virtuelle Disk geben mit ext4, und dann die Datastores umziehen?

verify drin würde ich dann trotzdem laufen lassen (auch ein zfs/ceph kann mal kaputt gehen, zb bit rot)

Dagegen sollte ja aber eigentlich das scrubbing "draußen" dann helfen, oder nicht?

 

[Dunuin]

Also dem virtuellen PBS lieber eine neue virtuelle Disk geben mit ext4, und dann die Datastores umziehen?

Jup. Oder besser gleiche eine virtuelle Disk mit ext4 je Datastore.

Dagegen sollte ja aber eigentlich das scrubbing "draußen" dann helfen, oder nicht?

Ja. Scrubbing hat aber keine Ahnung von PBS. Das guckt nur, ob noch alles genau so ist, wie als es geschrieben wurde. PBS Verify guckt aber z.B. auch, ob noch alle Chunk-Dateien existieren. Wäre z.B. blöd, wenn es da mal einen Bug gibt und das GC zu viele Chunk-Dateien löscht. ZFS Scrub sagt dann, "Alles an Daten heil", weil für ZFS die Blöcke, auf denen die Chunks lagen, ordnungsgemäß gelöscht wurden und ZFS daher nicht mehr interessieren. Ein PBS Verify würde da dann meckern, wenn eine Index-Datei Chunks referenziert aber die Chunks fehlen oder defekt sind.

 

[herzkerl]

Jup. Oder besser gleiche eine virtuelle Disk mit ext4 je Datastore.

Was wäre hier der Vorteil – außer, dass man die Disks dann einzeln auf andere PVE-Datastores verschieben könnte?

Ja. Scrubbing hat aber keine Ahnung von PBS. Das guckt nur, ob noch alles genau so ist, wie als es geschrieben wurde. PBS Verify guckt aber z.B. auch, ob noch alle Chunk-Dateien existieren. Wäre z.B. blöd, wenn es da mal einen Bug gibt und das GC zu viele Chunk-Dateien löscht. ZFS Scrub sagt dann, "Alles an Daten heil", weil für ZFS die Blöcke, auf denen die Chunks lagen, ordnungsgemäß gelöscht wurden und ZFS daher nicht mehr interessieren. Ein PBS Verify würde da dann meckern, wenn eine Index-Datei Chunks referenziert aber die Chunks fehlen oder defekt sind.

Das stimmt natürlich, guter Punkt... Meistens lasse ich nur beim Erstellen (also beim Kunden direkt) einen Verify laufen. Dort werden die Backups aber oft auch nicht länger als 30 Tage aufbewahrt (bisher) – und zusätzlich haben wir noch das Offsite-Backup. Dort läuft kein zusätzlicher Verify, aber durch den PBS-eigenen Sync weiß ich ja zumindest mal, dass alle Chunks da sind.

 

[Dunuin]

Was wäre hier der Vorteil – außer, dass man die Disks dann einzeln auf andere PVE-Datastores verschieben könnte?

Wenn ein Kunde seine Backups haben will kannst du ihm einfach die ganze virtuelle Disk aushändigen.
PBS berechnet nicht selbst wieviel Platz ein Datastore belegt sondern gibt nur die Daten vom Dateisystem aus. Willat du da wissen wie groß dein Datastore ist, sollte dein Datastore sein eigenes Dateisystem haben.
Hast du kein Dateisystem was Quotas kann, dann kannst du die Datastore-Größe über die Größe der virtuellen Disk begrenzen.