Storage-Unterschiede beim Abkoppeln benennen statt pauschal zu melden

Die Abhaengigkeit vom Quell-Snapshot ist eine Ceph-Eigenheit. Bisher meldete
flatten alles andere pauschal als "kein Ceph-Datentraeger" - das klingt nach
Einschraenkung, ist bei LVM-thin aber das Gegenteil.

Nachgemessen auf local-lvm: ein Thin-Snapshot teilt sich die Bloecke im Pool
(256 MB Nutzdaten liegen dort nur einmal), ist aber trotzdem eigenstaendig -
Quell-Snapshot und Original liessen sich loeschen, waehrend der Klon existiert,
und seine Pruefsumme blieb unveraendert. Dort gibt es also weder geschuetzte
Snapshots noch etwas zu flatten.

  lvmthin   nicht noetig, Klon ist von sich aus unabhaengig
  zfspool   nicht moeglich, ginge nur ueber zfs send | zfs recv
  rbd       noetig fuer den Dauerbetrieb
  lvm dick  PVE kann dort gar keine Snapshots

Der Hinweis in der Zusammenfassung richtet sich jetzt ebenfalls nach dem
Storage-Typ, statt immer zum Flatten zu raten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -702,10 +702,52 @@ Maschine als verwaist gelten. Ohne Elternteil wird nichts von selbst entfernt,
 und der Schutz eines Snapshots wird nur gelöst, wenn wirklich kein Klon mehr
 daran hängt.
 
-Bei anderen Storages sieht es anders aus: **LVM-thin**-Klone sind ohnehin
-unabhängig (der Thin-Pool zählt die Blöcke, das Original darf weg), bei **ZFS**
-hängt der Klon am Snapshot und ließe sich nur per `zfs send | zfs recv` lösen —
-das macht `flatten` nicht und meldet die Datenträger als nicht behandelt.
+### Und wenn die Maschine nicht auf Ceph liegt?
+
+Das ganze Thema „Abhängigkeit vom Quell-Snapshot" ist eine **Ceph-Eigenheit**.
+Andere Storages verhalten sich anders:
+
+| Storage | Klon aus Snapshot | Hängt am Quell-Snapshot? | `flatten` |
+|---|---|---|---|
+| `rbd` (Ceph) | `rbd clone`, sofort | **ja** — Snapshot wird geschützt und unlöschbar | nötig für den Dauerbetrieb |
+| `lvmthin` | `lvcreate -s`, sofort | **nein** | nicht nötig |
+| `zfspool` | `zfs clone`, sofort | ja | nicht möglich (nur `zfs send \| zfs recv`) |
+| `lvm` (dick) | — | — | PVE kann dort gar keine Snapshots |
+| `dir`, `nfs`, `cifs` | — | — | kein Klon aus qcow2-Snapshots möglich |
+
+**LVM-thin ist in diesem Punkt sogar angenehmer als Ceph.** Ein Thin-Snapshot
+ist ein eigenständiges Volume, das sich mit anderen nur die Blöcke im Pool
+teilt — nachgemessen:
+
+```
+Belegung im Thin-Pool nach dem Klonen (256 MB Nutzdaten):
+  data              <19.84g   1.26 %      ← Pool hält die Daten nur EINMAL
+  snap_..._wdhtest    1.00g
+  vm-9998-disk-0      1.00g  25.00 %      Klon
+  vm-9999-disk-0      1.00g  25.00 %      Original
+
+Quell-Snapshot löschen, während der Klon existiert   → erlaubt
+Original löschen                                     → erlaubt
+Prüfsumme des Klons danach                           → unverändert
+```
+
+Also: platzsparend geteilt **und** trotzdem frei löschbar. Es gibt dort weder
+das Problem mit geschützten Snapshots noch etwas zu flatten — `flatten` meldet
+solche Datenträger entsprechend als „nicht nötig".
+
+Der Preis ist ein anderer: `lvmthin` ist **lokaler** Speicher. Die
+Wiederherstellung muss auf demselben Node laufen wie das Original;
+`pvesnap-recovery` prüft das und lehnt einen anderen Node ab. Mit Ceph ist sie
+dagegen auf jedem Node des Clusters startbar.
+
+Und ein Warnhinweis, der für Thin-Pools genauso gilt wie für Ceph: Läuft der
+**Thin-Pool** voll, stehen alle Volumes darin. Überprovisionierung im Blick
+behalten.
+
+Bei **ZFS** hängt der Klon wie bei Ceph am Snapshot, aber `zfs promote` würde
+die Abhängigkeit nur umdrehen statt auflösen. Echte Unabhängigkeit ginge dort
+nur über eine Vollkopie per `zfs send | zfs recv` — das macht `flatten` nicht
+und sagt es auch so.
 
 ### Der Arbeitsspeicher kommt mit