Auswirkungen des Beendens eines lange laufenden RM-Befehls

Auswirkungen des Beendens eines lange laufenden RM-Befehls

Heute habe ich mit diesem Befehl eine 50 GB große Datei gelöscht, die auf einem Ext3-Dateisystem gespeichert war rm. Es dauerte rmfast 40 Minuten intensiver I/O-Operationen, um alle Blöcke freizugeben. Soweit ich aus anderen Quellen weiß, dauert es so lange, alle von der Datei verwendeten Blöcke freizugeben. Was wäre passiert, wenn jemand den rmProzess mittendrin beendet hätte? Könnte dies zu einer Beschädigung des Dateisystems geführt haben, bei der einige Blöcke nicht mehr als freier Speicherplatz zurückgewonnen werden konnten?

Antwort1

(d. h. erforderlich fsck). Es ist keine Dateisysteminkonsistenz erforderlich.

Ja, die Blockfreigabe erfolgt nach dem Aufheben der Verknüpfung. Dieser Vorgang kann jedoch nicht unterbrochen werden.

ext2_evict_inode->

__ext2_truncate_blocks ->
ext2_free_branches -> (for loop)
sb_bread ->
wait_on_buffer ->

wait_on_bit_io(&bh->b_state, BH_Lock, TASK_UNINTERRUPTIBLE);

Das obige Beispiel gilt für ext2, ich dachte, es wäre einfacher anzusehen. ext3Wird nicht anders sein …

ext4sollte jedoch schneller sein. Die Verwendung von Extents sollte die Notwendigkeit vermeiden,dreifach indirekte Blöcke. (Der Artikel beschreibt das Hinzufügen von Extents zu ext3, aber Linus schreckte zurück und sagte, man solle zuerst die Versionsnummer auf ext4 erhöhen.) Ich gehe davon aus, dass die Aktualisierungszeit für Bitmaps dieselbe wäre, aber diese sind viel kompakter als die Blockzeiger.

verwandte Informationen