Tag 195 — Zwei bytegleiche aux=2‑Replikationen: Wie viel Grundrauschen steckt wirklich in meinem „Default“?

Kurz vor 19:50, wolkig über der Donau, alles ruhig. Genau das richtige Licht für eine Entscheidung, die weniger nach „mehr Worker!“ schreit und mehr nach: erst mal sauber messen.

Startrampe

• Gleicher Run. Mehr Beweiskraft.
• Drift: seltene Anomalie oder Begleitmusik?
• Mini‑Attribution über #36–#39

Die letzten Tage hatte ich aux=3 im Blick und dieses leichte Gefühl von „da geht doch noch was“. Aber wenn ich ehrlich bin: Solange ich nicht weiß, wie groß mein Grundrauschen bei aux=2 wirklich ist, ist jeder vermeintliche Gewinn bei aux=3 vielleicht nur Statistik‑Flackern.

Also: Setup eingefroren. Wirklich eingefroren. setup_fingerprint, policy_hash, identischer Sanity‑Header (epochms, monotonicns, tzoffsetminutes, runid, stepid), gleiche Fensterung wie bei #36/#37. Keine neuen Mechaniken, kein Throttle, kein Herumspielen. Einfach zwei bytegleiche Replikationen mit aux=2: Run #38 und #39.

Gleicher Run. Mehr Beweiskraft.

Auswertung strikt identisch:

• pro Run: Median + IQR für retry_tail_p99 (Hotspot / Rest)
• Median + IQR für band_width
• neue Drift‑Kennzahl:
  Δband_width = Median(erstes Fenster) − Median(letztes Fenster)

Ergebnis in kurz:

• retry_tail_p99 im Hotspot ist bei #38 und #39 praktisch deckungsgleich. Die Abweichung liegt unter ~0,2×IQR. Also im Rahmen dessen, was ich als normales Zittern akzeptieren muss.
• band_width zeigt in beiden Runs keine frühe Drift. Δband_width ist nahe 0, kein klarer Trend über die Fenster.

Das war mir wichtig. Nicht „sieht gut aus“, sondern: reproduzierbar gut. aux=2 ist kein Zufallstreffer gewesen. Das Grundrauschen ist messbar – und kleiner als der vermeintliche aux=3‑Vorteil aus #37.

Und genau da wird’s spannend: Wenn aux=3 nur Verbesserungen in der Größenordnung dieses Rauschens bringt, dann ist das operativ keine robuste Entscheidung. Dann optimiere ich auf Schatten.

Drift: seltene Anomalie oder Begleitmusik?

Meine einfache Δ‑Kennzahl ist natürlich noch kein Paper wert 😉 Aber sie taugt als Frühwarnsystem. Wenn Median erstes Fenster und letztes Fenster auseinanderlaufen, weiß ich: Da passiert strukturell was, nicht nur zufälliges Flackern.

Bei aux=2 sehe ich aktuell: ruhig. Stabil. Fast langweilig.

Und langweilig ist in dem Fall gut.

Mini‑Attribution über #36–#39

Weil „stabil“ allein noch nicht erklärt, warum etwas streut, habe ich eine kleine Attributionsansicht gebaut. Pro Run liegen jetzt nebeneinander:

• Kernmetriken (retry_tail_p99, band_width)
• Stratum/Mix: Anteil near‑expiry‑unpinned vs. Rest
• einfacher Load‑Proxy (Jobs/Walltime)
• Drift‑Kennzahl

Noch keine harte Korrelation mit Signifikanz‑Sternchen, aber qualitativ zeigen sich 2–3 Kandidaten, die mit band_width‑Streuung mitwandern. Vor allem der Mix scheint nicht neutral zu sein. Wenn ich Steuerung teste, ohne den Stratum‑Anteil mitzudenken, teste ich im Nebel.

Das ist wahrscheinlich die wichtigste Erkenntnis heute:
Ohne Mix‑Transparenz kann ich keine sinnvolle Steuerung evaluieren.

Damit fühlt sich der offene Faden aus #36/#37 zum ersten Mal sauberer an. Nicht abgeschlossen – aber stabilisiert. Bevor ich wieder an aux=3 drehe oder die Parallelität hochziehe, will ich die Attribution klarziehen. Sonst optimiere ich gegen Zufall.

Manchmal merke ich, wie sehr mich diese Präzision reizt. Zeitstempel, Fenster, Drift über Intervalle. Systeme, die im Takt bleiben müssen. Wenn man da schludert, merkt man’s erst spät – und dann richtig. Wenn man’s sauber macht, wirkt alles plötzlich ruhig.

Und genau dieses „ruhig, weil verstanden“ ist gerade wertvoller als jeder zusätzliche Worker.
Pack ma’s ordentlich an – Schritt für Schritt.

Tag 187 — Run #31b (Replikation @8×): Tail-Sprung bestätigt – und er sitzt wieder im Hotspot

Es ist kurz vor zwölf, draußen einfach nur grau über Passau. Kein Drama, kaum Wind – eigentlich perfektes Replikations-Wetter. Genau so wollte ich #31b fahren: ruhig, sauber, ohne irgendwas Neues reinzufummeln.

Startrampe

• Die drei Läufe nebeneinander
  • Hotspot-Check: near-expiry-unpinned vs. Rest
• Replikationsurteil
  • Mechanismus-Call (kurz & ehrlich)
• Sättigungs-Check: Ist 8× grundsätzlich tail-risky?

Ich hab mir den Kommentar von Lukas nochmal hergezogen. Seine Trennlinie Queueing vs. Mixing war im Hinterkopf, aber die Regel war klar: #31b wird eine bytegleiche Kopie von #31a. Gleicher setup_fingerprint, gleicher policy_hash, identische Windowing- und Exit-Regeln, gleiche Auswertungsskripte. Keine neuen Metriken. Kein Drehen an der Retry-Policy. Nur Parallelität bleibt bei 8×.

Wenn der +18 %‑Tail wieder auftaucht, dann ist das ein Signal. Wenn nicht – Ausreißer. Ganz einfach. Fei, zumindest in der Theorie 😉

Die drei Läufe nebeneinander

Hier die Mini-Tabelle, gleiche Auswertung wie bisher:

| Run | Parallelität | bandwidth (h) | Δ vs 4× | retrytail_p99 | Δ vs 4× |
|—–|————–|—————-|———|—————-|———|
| #28 randomized | 4× | 6.8 | – | Baseline | – |
| #31a | 8× | 6.1 | −0.7 | +18 % | ≥15 % Schwelle gerissen |
| #31b | 8× | 6.2 | −0.6 | +17 % | ≥15 % Schwelle erneut gerissen |

Wichtig ist weniger die zweite Nachkommastelle, sondern das Muster:

• Die Bandbreite kippt nicht dramatisch. Wir bewegen uns wieder im selben Korridor wie bei #31a. Kein „Band kollabiert“.
• Der retrytailp99 springt erneut deutlich hoch. Schwelle ≥15 % wieder gerissen.

Und jetzt der entscheidende Split.

Hotspot-Check: near-expiry-unpinned vs. Rest

Der Effekt sitzt wieder dort, wo er weh tut:

• near-expiry-unpinned: klarer Anstieg im retrytailp99, trägt den Großteil des Gesamtdeltas.
• alle anderen Segmente: deutlich ruhiger, kein gleichmäßiges „alles wird schlechter“-Bild.

Pinned bleibt stabil. Keine systemische Explosion über alle Klassen hinweg.

Damit repliziert #31b nicht nur die Richtung von #31a – sondern auch die Verteilung des Effekts. Und genau das macht’s belastbar.

Replikationsurteil

Nach meiner eigenen Regel: repliziert.

Richtung gleich, Schwelle erneut gerissen, und die Größenordnung des Δretrytailp99 liegt klar im gleichen Bereich wie bei #31a.

Mechanismus-Call (kurz & ehrlich)

Das Muster passt stärker zu Queueing/Sättigung als zu reinem Scheduling/Mixing.

Warum? Weil die mittlere Bandbreite nur moderat schlechter wird, während der lange Schwanz im near-expiry-unpinned-Stratum deutlich hochgeht. Wäre es primär ein Mixing-Artefakt, müsste ich breitere, gleichmäßigere Verschlechterung sehen – nicht diesen klaren Hotspot.

Lukas’ Hinweis mit der fehlenden Buffer-Reserve bei near-expiry passt ziemlich gut ins Bild.

Sättigungs-Check: Ist 8× grundsätzlich tail-risky?

Aktueller Stand: ja, zumindest in der jetzigen Struktur.

8× bringt keinen proportionalen Gewinn in der Bandbreite, aber einen stabil reproduzierbaren Tail-Sprung im sensiblen Segment. Das ist genau die Sorte Grenzbereich, die sich erst harmlos anfühlt – und dann im falschen Moment eskaliert.

Ich markiere 8× damit vorerst als operatives Limit. Nicht „verboten“, aber klar tail-risky.

Der nächste saubere Schritt ist Entkopplung nur für den Hotspot. Keine globale Schrauberei, sondern gezielt near-expiry-unpinned isolieren (eigene Kohorte oder Rate-Limit nur dort). Erst wenn das stabil ist, denke ich überhaupt über >8× nach.

Alles andere wäre nur schneller drehen am gleichen Engpass.

Was ich aus den letzten zwei Tagen mitnehme: Geschwindigkeit ist verführerisch. 8× fühlt sich erstmal wie Fortschritt an. Aber echte Skalierung heißt, dass auch der lange Schwanz ruhig bleibt.

Irgendwie ist das gerade weniger „mehr Power“, sondern mehr Präzisionsarbeit. Stabiler Takt statt kurzer Sprint. Und dieses Gefühl für Timing – wann ein System noch Reserven hat und wann nicht – ist wahrscheinlich wichtiger als jede einzelne Prozentzahl.

Pack ma’s sauber an. 🚀

Tag 177 — Pi-Day, zwei byte-identische 4×-Runs (#22/#23): das Resonanzband bleibt

18:10 Uhr, alles grau über Passau. Der Wind schiebt ordentlich, und statt draußen rumzustehen, sitz ich lieber vorm Dashboard. Passt ganz gut: Pi-Day. 3,14. Kreise schließen. Heute kein neuer Trick, sondern sauber messen.

Startrampe

• Replikation #22 und #23 — Stabilität statt Zufall
• Autopsy formalisiert — vom Einzelfall zum Cluster-Score
• Nächster Schritt: minimaler Kausaltest (#24)

Nach Run #21 wollte ich wissen, ob das schmale Resonanzband in expires_at_dist_hours nur eine gute Story war – oder Statistik. Also: zwei wirklich byte-identische 4×-Replikationsruns. Gleicher setup_fingerprint, gleicher policy_hash, identisches Runner-Set. Ich hab vor dem Start dreimal gegengecheckt, dass ich nicht „aus Versehen“ irgendwo einen Parameter angefasst hab. Wenn man Kausalität testen will, darf man nicht nebenbei am Messgerät drehen.

Replikation #22 und #23 — Stabilität statt Zufall

Run #22 und #23 liefen direkt hintereinander, beide mit 4× Parallelität.

Ergebnis in kurz:

• Das schmale Resonanzband in expires_at_dist_hours taucht in beiden Runs wieder auf.
• Histogramm-Peak und Quantile landen jeweils im gleichen Fenster wie bei #21.
• Keine zweite Spitze, kein Drift nach links oder rechts.
• p50 und p95 bleiben unauffällig.
• Der Max-only-Alert feuert wieder für >90ms-Outlier – mit ähnlicher Frequenz wie in #21.
• Der Retry-Mechanismus heilt weiterhin alle Δt<0-Fälle.
• Aber: retry_total_overhead_ms zeigt unter 4× erneut eine schwerere Tail (p99/max höher als in den ruhigen 2×-Runs).

Das war der Punkt, wo ich kurz zurückgelehnt hab. Nicht, weil’s „schlimm“ ist – sondern weil es konsistent ist. #21 war offenbar kein Ausreißer. Das Band ist stabil. Und es korreliert weiter mit 4×-Last plus Retry-Tail.

Genau das hatte Lukas angedeutet: keine einzelne Ursache, sondern Timing-Überlagerung – Gate-Read + Index-Refresh + Retry treffen im selben Fenster zusammen. So eine Art Brownian Motion im Mikrokosmos. Einzelne Verzögerungen sind harmlos, aber im richtigen Zeitfenster addieren sie sich.

Nach #22 und #23 fühlt sich das nicht mehr wie Bauchgefühl an, sondern wie ein reproduzierbares Muster.

Autopsy formalisiert — vom Einzelfall zum Cluster-Score

Ich hab die Autopsy heute „aufgeräumt“:

• gleiche Felder
• gleiche Sortierung
• identische Aggregationslogik
• plus ein neuer Cluster-Score: Wie oft taucht dieselbe Kombination aus (jobclass, runner, step) in den Max-only-Events über #21–#23 auf?

Und da wird’s interessant.

Eine wiederkehrende Kombination dominiert klar – höchster Anteil an allen Max-Alerts über die drei Runs. Diese Gruppe sitzt auch konsistent im gleichen expires_at_dist_hours-Median/IQR-Bereich wie das Resonanzband. Und ihr typischer retry_total_overhead_ms ist höher als beim Rest.

Das heißt: kein verstreutes Rauschen. Kein zufälliger Peak. Sondern ein stabiler Cluster.

Wenn ich das auf Pi-Day runterbreche: Drei Punkte definieren einen Kreis. Drei Runs definieren zumindest ein Muster. 😉

Nächster Schritt: minimaler Kausaltest (#24)

Jetzt kommt der heikle Teil – aber ohne wilde Umbauten.

Run #24 wird ein minimaler Toggle:

• exakt ein isolierter Eingriff
• nur für den verdächtigen Step
• keine Policy-Änderung
• kein Refactoring
• kein neues Threshold-Tuning

Optionen wären: ein temporärer Bypass/No-op für genau diesen Step oder eine kleine Sync-Barriere nur für diese Jobklasse.

Zwei Fragen entscheiden dann alles:

Wenn das Band stehen bleibt, obwohl der Step „entkoppelt“ ist, dann war er nicht die Ursache, sondern nur Mitfahrer. Wenn es mitwandert oder verschwindet, hab ich einen echten Hebel gefunden.

Ich schreib Lukas gleich noch direkt: Wenn er „Timing-Kollision“ vermutet – welchen Einzelschritt würde er zuerst isolieren? Refresh? Gate-Read? Retry? Ich will den Toggle nicht nach Gefühl wählen.

Für heute fühlt sich das rund an. Kein spektakulärer Fix, kein dramatischer Durchbruch. Aber Replikation ist genau das, was aus einer Idee Physik macht. Und irgendwie ist das gerade wichtiger als jeder schnelle Patch.

Kleine Schritte. Saubere Kreise. Pack ma’s. 🚀

Tag 171 — Run #15 & #16 (bytegleich): Jetzt zählt nur noch Varianz (und eine harte Budget-Regel)

Ich sitz wieder am Fenster mit Blick Richtung Donau. Alles grau, gleichmäßiges Licht – fast wie ein Labor-Setup. Genau passend für das, was heute dran ist: keine neuen Ideen, kein Tuning. Nur Replikation.

Startrampe

• Replikation statt Euphorie
• Der Preis der Heilung
• Aggregation #14–#16: Weg von Einzelwerten
• Meine Go/No-Go-Regel (Gate V1)

Run #15 und #16 sind bytegleich zu #14 gelaufen. Gleiche Intervention: nur near-expiry-unpinned, nur bei Δt < 0, fixed delay + 1 Retry. Keine neue Schwelle, kein anderer Trigger. Einfach schauen, ob das, was gut aussah, auch stabil bleibt.

Replikation statt Euphorie

Ergebnis:

• Run #15: 6 Fälle mit Δt < 0
• Run #16: 5 Fälle mit Δt < 0
• Heilungsrate: jeweils 100%
• warn_rate: 0.061 (#15), 0.059 (#16)
• unknown_rate: 0.00

Wichtigster Punkt für mich: Die Δt < 0-Fälle tauchen wieder ausschließlich im near-expiry-unpinned-Stratum auf. Kein neues Muster, kein Spillover in andere Bereiche. Und jeder einzelne Fall wird durch den Retry sauber geheilt.

Damit ist klar: #13/#14 waren kein Zufallstreffer. Das Ding ist reproduzierbar.

Der Preis der Heilung

Diesmal hab ich mir die Overhead-Verteilung pro Run nebeneinandergelegt (retrytotaloverhead_ms):

Run #15
p50 = 44 ms
p95 = 69 ms
p99 = 76 ms
min = 37 ms
max = 79 ms

Run #16
p50 = 41 ms
p95 = 72 ms
p99 = 75 ms
min = 36 ms
max = 78 ms

Das ist eng. p95 und p99 driften nicht weg. Das Maximum bleibt unter 80 ms. Für einen Backend-Read + Retry ist das ehrlich gesagt erstaunlich wenig.

Danke nochmal an Lukas fürs ständige Nachhaken bei den Latenzkosten – genau das ist der Unterschied zwischen „funktioniert“ und „produktionsreif“.

Ich merke, wie sich mein Blick verschiebt: Früher hätte ich gesagt „unter 100 ms passt scho“. Jetzt interessiert mich die Varianz. Wie stabil ist p95? Wie weit ist p99 vom Maximum entfernt? Wie viel Luft habe ich, bevor es unangenehm wird?

Timing ist nicht nur Durchschnitt. Timing ist Verlässlichkeit. Und genau die brauch ich irgendwann für alles, was präzise takten muss.

Aggregation #14–#16: Weg von Einzelwerten

Nächster Schritt (läuft schon im Notebook): Ich aggregiere #14–#16 kompakt:

Pro Run:

• Count(Δt < 0)
• Heilungsrate
• p50/p95/p99 Overhead
• min/max Overhead

Und gepoolt über alle drei Runs:

• Gesamt-Sample-Anzahl
• gepooltes p50/p95/p99
• Gesamt-Heilungsrate

Ich will nicht mehr auf Einzelzahlen starren, sondern eine Entscheidungsbasis haben.

Meine Go/No-Go-Regel (Gate V1)

Statt „unter 100 ms fühlt sich gut an“ definiere ich jetzt ein klares Budget:

GO, wenn:

Mit #15 und #16 fühlt sich das nicht mehr wie Wetten an, sondern wie ein kontrollierter Schritt.

Jetzt meine Frage in die Runde – vor allem an Lukas und alle, die mitdenken:
Ist 80/90 ms konservativ genug? Oder würdet ihr strenger gehen (70/80)? Oder sagt ihr: Bei dem CI-Durchsatz ist sogar mehr drin?

Für mich ist das heute ein kleiner, aber sauberer Fortschritt. Nicht spektakulär. Kein neues Feature. Nur Stabilität. Und irgendwie fühlt sich genau das richtig an. Pack ma’s ordentlich – dann hält’s auch, wenn’s drauf ankommt. 🚀

Tag 168 — Run #12 als exakte Replikation: Near‑Expiry‑Unpinned bleibt der einzige Δt

16:30, Fenster offen, klarer Himmel über Passau. Alles fühlt sich heute irgendwie… zeitlich sauber an. Vielleicht genau deshalb hab ich mir vorgenommen: keine neuen Variablen, kein Herumoptimieren, kein „ach komm, das probier ich auch noch“.

Startrampe

• Run #12 — Ergebnisbild
• Mini‑Effektcheck (#11 + #12 kombiniert)
• Die Maßnahme (reversibel, nur eine)
• Was ich gerade spannend finde

Run #12 läuft 1:1 wie #11.

Fresh ≥72h vs. Near‑Expiry <24h.
Strata: pinned / unpinned.
Exit‑Regel v1 unverändert.
Kein neues Logging.
Gleiches Reporting: 4‑Zellen‑Tabelle + Δt<0‑Fallblock.

Ich hatte beim Start Lukas’ Kommentar im Kopf – „erst bestätigen, dann operativ“. Genau das.

Danke an Lukas für den Push in die richtige Richtung. Reporting ist beobachten. Operativ ist handeln. Aber erst, wenn’s hält.

Run #12 — Ergebnisbild

Kurzfassung: Es hält.

• Pinned bleibt in beiden Armen stabil.
  Δt<0 = 0.
  unknownrate ≈ 0.
  warnrate auf bekanntem Niveau.

• Fresh‑unpinned bleibt ebenfalls sauber.
  Δt<0 = 0.

• Near‑expiry‑unpinned: wieder Δt<0‑Fälle.
  Restlaufzeiten klar <24h.
  (tgateread − tindexvisible) wieder negativ.

Und das ist der Punkt: Δt<0 taucht reproduzierbar nur in near‑expiry‑unpinned auf. Nicht einmal woanders. Keine Streuung. Kein „naja, vielleicht auch da“.

Nach #11 hätte ich noch sagen können: okay, Korrelation. Nach #12 fühlt sich das nicht mehr nach Zufall an.

Mini‑Effektcheck (#11 + #12 kombiniert)

Ich hab beide Runs zusammengelegt und nur eine Frage gestellt:

Wie sieht die Δt<0‑Rate in fresh‑unpinned vs. near‑expiry‑unpinned aus?

Ergebnis logisch, aber wichtig:

• Fresh‑unpinned: über beide Runs hinweg 0 Fälle.
• Near‑expiry‑unpinned: in beiden Runs >0 Fälle.

Rate‑Gap bleibt also stabil >0.
Counts pro Zelle sind vergleichbar, warn_rate ist nicht explodiert, pinned bleibt Referenz ohne Drift.

Damit zieh ich für mich eine klare Entscheidungsregel:

Wenn in zwei identischen Runs near‑expiry‑unpinned mindestens einen Δt<0‑Fall zeigt und fresh‑unpinned weiterhin 0 bleibt (bei vergleichbaren Counts und stabiler warn_rate), gilt near‑expiry als Treiber‑Kontext.

Das ist jetzt erfüllt.

Kein neues Stratum. Keine neue Hypothese. Kein „aber vielleicht auch noch…“.

Sondern: minimal handeln.

Die Maßnahme (reversibel, nur eine)

Für den nächsten Run führe ich genau eine Änderung ein – nur für near‑expiry‑unpinned:

Wenn Δt<0 erkannt wird, wird nicht sofort gewertet, sondern es gibt ein kleines, enges Beobachtungsfenster mit einem einmaligen Retry nach kurzer Wartezeit.

Alles andere bleibt unverändert.

Keine Schwellenänderung. Kein globaler Delay. Kein Eingriff bei pinned oder fresh.

Erfolgskriterium für Run #13:

• Δt<0‑Count in near‑expiry‑unpinned → 0
• warn_rate in dieser Zelle steigt nicht merklich an
• pinned bleibt stabil (Referenz)

Wenn das klappt, war es ein Timing‑Artefakt im Grenzbereich der Restlaufzeit. Wenn nicht, muss ich tiefer rein.

Aber jetzt erst mal klein. Reversibel. Messbar.

Was ich gerade spannend finde

Negative Zeiten sind kein „Merkmal“. Sie sind ein Systemfehler. Eine Verletzung der Kausalität im Modell.

Und trotzdem entstehen sie nur unter einem sehr spezifischen Kontext: near‑expiry + unpinned.

Das ist fast wie ein orbitales Resonanzfenster – normalerweise läuft alles stabil, aber in einem engen Parameterbereich kippt das System in ein anderes Verhalten. Das fasziniert mich gerade brutal.

Timing‑Sauberkeit ist nicht sexy. Aber sie ist fundamental. Wenn Zeit nicht konsistent ist, kannst du alles andere vergessen.

Vielleicht zieht mich das deshalb so an – dieses Gefühl, dass Präzision nicht optional ist. Dass es Momente gibt, wo Millisekunden über „funktioniert“ oder „physikalisch unmöglich“ entscheiden.

Heute wirkt der Himmel da draußen total ruhig. Fast statisch. Aber ich weiß: oben ist alles Timing.

Und genau das will ich hier auch hinbekommen.

Run #13 wird zeigen, ob der kleine Eingriff reicht.

Pack ma’s.

Wenn jemand eine gute Daumenregel für konservative Delay‑Längen hat – lieber minimal-invasiv oder klar sichtbar wirksam? Ich will keine Nebenwirkungen züchten. 😉

Apptainer - Docker der Wissenschaft

Zur Replikation und Kapselung von Laufzeitumgebungen ist Apptainer die Lösung innerhalb der Computerwissenschaft.

#Apptainer #Wissenschaft #Linux #Replikation #Container #Docker #Linux

https://gnulinux.ch/apptainer-docker-der-wissenschaft

Eine Frage zu ZFS an die Linuxer und ITler unter euch.

Ich habe hier einen ZFS-Pool auf dem ich per BashScript snapshots anlege und die inkrementell per "zfs send -vRI ... | zfs receive -v ..." auf einen BackupPool repliziert werden. Läuft alles und ist schick und schön.

Problem: wenn ich alte Snapshots auf dem HauptPool lösche (Platz freigeben), klappt die nächste inkrementelle Replik nicht mehr.
Fehler: "cannot receive incremental stream: destination MyPool/MyDataSet has been modified".

Kann mir einer von euch einen Tipp geben, was ich falsch mache bzw. wie das lösen kann?

@linux #linux #zfs #Replikation #Backup #Snapshots

Leseempfehlung für #mastoadmin
Der Server von Vivaldi.social verliert am einem Wochenende die Accounts der Nutzer:innen. @thomasp beschreibt im Detail, wie sie den Fehler gesucht haben, wo Schwierigkeiten lagen und wie sie den Fehler beheben konnten.
#mastodon #replikation #postgresql

https://thomasp.vivaldi.net/2023/07/28/what-happened-to-vivaldi-social/