Ist essicherauf eine Datei anwenden fallocate --dig-holes, während sie geändert/geschrieben wird? Zum Beispiel auf ein QCOW2-Image, das von einem KVM-Gast geöffnet wurde?
Antwort1
Ich würde grundsätzlich nein sagen. Wenn die Datei ein auf einer VM gemountetes Image ist, können Sie stattdessen TRIM (z. B. fstrim -a) ausprobieren. Streng genommen ist dies kein Äquivalent (TRIM kann auch Speicherplatz einer gelöschten Datei freigeben, die nicht auf Null gesetzt ist), aber dies könnte das sein, was Sie wollen.
In einigen speziellen Fällen mag es sicher sein, aber ich würde mich nicht darauf verlassen. Wenn beispielsweise einige Daten sequenziell in eine Datei gestreamt werdenohne Vorbelegung, das klingt potenziell sicher. Da dies jedoch nicht in der Dokumentation steht und nur von der Implementierung abhängt, rate ich dringend davon ab.
Was kann schiefgehen? Stellen Sie sich vor, die App/VM überschreibt einen Block mit Nullen und Sie führen gleichzeitig fallocate -d aus. Das Rennen kann so aussehen:
- Fallocate sieht einen Block aus Nullen und beschließt, dort ein Loch zu graben.
- Eine andere Anwendung/VM schreibt einige Daten in den auf Null gesetzten Block.
- Fallocate gräbt ein Loch in den Block.
Es klingt vielleicht so, als ob zwischen 1 und 3 ein kleiner Zeitrahmen liegt. Vielleicht stimmt das, aber fallocate möchte möglicherweise mehrere aufeinanderfolgende Blöcke auf einmal freigeben. (Ich bin nicht sicher, ich habe die Implementierung nicht überprüft, aber selbst wenn das Gegenteil der Fall ist, können Sie sich in Zukunft nicht darauf verlassen.) Dies kann die Verzögerung zwischen 1 und 3 erhöhen und den Race Condition viel wahrscheinlicher machen.