Axel Dörfler hat einen verschollen geglaubten Artikel zu BFS und chkbfs gefunden und auf sein Blog gestellt. Hier eine Zusammenfassung:
"chkbfs", das Tool um Fehler im Dateisystem zu finden und zu beseitigen, wurde erst später dem BeOS mitgegeben. Und man ist gut beraten es nach einem Systemcrash laufen zu lassen.
Seine Daseinsberechtigung erlangte chkbfs zum einen durch ein VFS Feature, zum anderen durch ein Design Problem des BFS: wird eine Datei gelöscht, die noch von einer anderen Anwendung benutzt wird, wird der Platz auf der Festplatte nicht freigegeben, bis der letzte Benutzer seine Referenz auf diese Datei geschlossen hat. Bis dahin wird nur deren Inode als gelöscht markiert und aus dem Verzeichnis entfernt damit sie nicht weiterhin gefunden oder geöffnet werden kann.
Da das BFS nur sequentielle Transaktionen 1) beherrscht, benötigt es zwei Transaktionen um die Datei zu löschen: eine um sie aus dem Verzeichnis zu entfernen, eine weitere um den belegten Platz auf der Platte freizugeben.
Die Hauptaufgabe von chkbfs ist also auf diese Art nicht freigegebenen Speicherplatz zu erkennen und wirklich wieder zur Verfügung zu stellen. Wer chkbfs nicht ab und zu ausführt, dem fehlen von wenigen kB zu GB an Plattenspeicher; je nach dem…
Es gibt zwei Lösungsansätze: BFS könnte ein spezielles Action Log unterhalten in dem es alle Dateien notiert die gelöscht werden sollen. Diese Dateien können dann beim nächsten Boot komplett gelöscht werden. Die andere Möglichkeit ist mehrere Transaktionen gleichzeitig zu erlauben.
Beides sind sehr wünschenswerte Lösungen, die zusammen genommen in vielen Fällen die Geschwindigkeit des BFS steigern würde: Erstere beschleunigt Index bzw. Verzeichnis Updates, weil immer gleich mehrere auf einen Schlag abgearbeitet werden können und außerdem unabhängig von der Aktion, die die Updates auslöste. Die zweite Lösung könnte den Datendurchsatz sehr erhöhen wenn man mehrere Platten in einem RAID betreibt. Da diese Lösungen jedoch nicht abwärts-kompatibel zum BFS wären, sind sie erst nach Haiku R1 geplant und chkbfs bleibt für’s erste unentbehrlich.
In Zukunft wären auch ein Tool nützlich um Fehler auf einer BFS Disk zu reparieren für die der Journal Mechanismus mit seinen Transaktionen nichts kann: fehlerhafter Speicher, kaputte Blocks usw. Zur Zeit gibt es für so was Axel's etwas umständliche Tool „recover“.
Übrigens, der Befehl “forcerm”, mit dem widerspenstige Dateien unter BeOS gekillt werden konnten, ist unter Haiku nicht mehr nötig, da er nur Auswirkungen von Bugs im alten BeOS-BFS behebt, die sich in der Haiku Implementation nicht befinden.
"chkbfs", das Tool um Fehler im Dateisystem zu finden und zu beseitigen, wurde erst später dem BeOS mitgegeben. Und man ist gut beraten es nach einem Systemcrash laufen zu lassen.
Seine Daseinsberechtigung erlangte chkbfs zum einen durch ein VFS Feature, zum anderen durch ein Design Problem des BFS: wird eine Datei gelöscht, die noch von einer anderen Anwendung benutzt wird, wird der Platz auf der Festplatte nicht freigegeben, bis der letzte Benutzer seine Referenz auf diese Datei geschlossen hat. Bis dahin wird nur deren Inode als gelöscht markiert und aus dem Verzeichnis entfernt damit sie nicht weiterhin gefunden oder geöffnet werden kann.
Da das BFS nur sequentielle Transaktionen 1) beherrscht, benötigt es zwei Transaktionen um die Datei zu löschen: eine um sie aus dem Verzeichnis zu entfernen, eine weitere um den belegten Platz auf der Platte freizugeben.
1) Transaktionen sind “atomare”, also nicht-teilbare, Operation auf der Festplatte: sie werden entweder komplett abgeschlossen oder gar nicht durchgeführt. So garantiert ein Journal Datei System seine Integrität.Wenn das System abstürzt nachdem die erste Transaktion abgeschlossen ist und bevor die zweite begonnen wurde, kann das BFS nicht wissen, dass noch Speicherplatz freizugeben ist. Und auch beim nächsten Hochfahren wird es das nicht erfahren, weil das System ja schon korrekterweise gemeldet hat, dass die Datei zu löschen ist.
Die Hauptaufgabe von chkbfs ist also auf diese Art nicht freigegebenen Speicherplatz zu erkennen und wirklich wieder zur Verfügung zu stellen. Wer chkbfs nicht ab und zu ausführt, dem fehlen von wenigen kB zu GB an Plattenspeicher; je nach dem…
Es gibt zwei Lösungsansätze: BFS könnte ein spezielles Action Log unterhalten in dem es alle Dateien notiert die gelöscht werden sollen. Diese Dateien können dann beim nächsten Boot komplett gelöscht werden. Die andere Möglichkeit ist mehrere Transaktionen gleichzeitig zu erlauben.
Beides sind sehr wünschenswerte Lösungen, die zusammen genommen in vielen Fällen die Geschwindigkeit des BFS steigern würde: Erstere beschleunigt Index bzw. Verzeichnis Updates, weil immer gleich mehrere auf einen Schlag abgearbeitet werden können und außerdem unabhängig von der Aktion, die die Updates auslöste. Die zweite Lösung könnte den Datendurchsatz sehr erhöhen wenn man mehrere Platten in einem RAID betreibt. Da diese Lösungen jedoch nicht abwärts-kompatibel zum BFS wären, sind sie erst nach Haiku R1 geplant und chkbfs bleibt für’s erste unentbehrlich.
In Zukunft wären auch ein Tool nützlich um Fehler auf einer BFS Disk zu reparieren für die der Journal Mechanismus mit seinen Transaktionen nichts kann: fehlerhafter Speicher, kaputte Blocks usw. Zur Zeit gibt es für so was Axel's etwas umständliche Tool „recover“.
Übrigens, der Befehl “forcerm”, mit dem widerspenstige Dateien unter BeOS gekillt werden konnten, ist unter Haiku nicht mehr nötig, da er nur Auswirkungen von Bugs im alten BeOS-BFS behebt, die sich in der Haiku Implementation nicht befinden.
Keine Kommentare:
Kommentar veröffentlichen