Ich habe festgestellt, dass XFS beim Systemstart kein fsck implementiert, und einer der Gründe, die in diesem Journal angepriesen werden, trägt dazu bei, dass das Dateisystem nach einem unsauberen Herunterfahren in einem konsistenten Zustand ist. Beim nächsten Mount (z. B. nach dem Neustart) wird das Journal wiedergegeben.
Wird nach einem unsauberen Herunterfahren noch ein fsck benötigt und warum?
Antworten:
Ich beantworte dies im allgemeinen Kontext von "Journalled Filesystems".
Ich denke, wenn Sie früher oder später eine Reihe von "unreinen Abschaltungen" (durch Ziehen des Netzkabels oder etwas anderem ) durchführen würden, würden Sie zu einem Dateisystemzustand gelangen, der dies erfordert fsckoder das moralische Äquivalent von fsck , xfs_repair. Der ext4Dateisystem auf meinem Laptop spielt das Journal größtenteils nur bei jedem Neustart ab, einschließlich sauberer Abschaltungen, aber hin und wieder wird ein vollständiger Vorgang ausgeführt fsck.
Aber fragen Sie sich, was "Wiedergabe des Tagebuchs" bewirkt. Durch die Wiedergabe eines Journals wird lediglich sichergestellt, dass die Festplattenblöcke des restlichen Dateisystems der Reihenfolge entsprechen, die für die Journaleinträge erforderlich ist. Das Wiedergeben eines Tagebuchs ist ein kleines fsckoder ein Teil eines vollen Tagebuchs fsck.
Ich denke, es gibt einige verbale Tricks: Das Wiedergeben eines Tagebuchs ist Teil dessen, was traditionell fsckfunktioniert, und xfs_repairgenau das ist die gleiche Art von Programm, die e2fs.fsck(oder jedes andere Dateisystem fsck) ist. Die XFS-Leute haben nur geglaubt oder ihre Erfahrung hat dazu geführt, dass sie nicht xfs_repairbei jedem Start ausgeführt wurden, sondern nur das Tagebuch erneut abgespielt haben.
fscknicht "pedantisch". Ich habe eine ext3 LVMPartition in ext4"ext4_mb_generate_buddy" konvertiert und Fehler erhalten, die meines Wissens auf einen Fehler im ext4Code zurückzuführen sind, der zu einer Nichtübereinstimmung der Kopien auf der Festplatte und im Speicher der Bitmap auf konvertierten "LVM" -Partitionen führte. Soweit ich das beurteilen kann, fsckist keine Korruption aufgetreten. Die Lösung bestand entweder darin, die UNINIT_BGOption zu deaktivieren oder die Daten zu verschieben und die Partition als neu zu initialisieren ext4. Ich habe den letzteren Kurs belegt. Aber ich denke immer noch, ein paar Minuten Warten auf einen fsckist es wert, keine Daten zu verlieren!
Stellen Sie sicher, dass sich das Dateisystem nach einem unsauberen Herunterfahren in einem konsistenten Zustand befindet
Als erstes ist zu beachten, dass XFS, reiser und die meisten Konfigurationen von ext nur Metadaten-Journale implementieren, bei denen es darum geht, fsck zu vermeiden. Das Journal wird beim Start nicht immer wiedergegeben - es kann verworfen werden, wenn es unvollständig ist.
Es gibt Systeme, die eine vollständige Datenerfassung unterstützen. In der Praxis ist die Sicherheit, die diese nur für die Erfassung von Metadaten bieten, in realen Szenarien jedoch sehr gering.
Ein 'inkonsistenter Zustand' und die von fsck behobenen Probleme sind also Fehlanpassungen zwischen den Metadaten und den Dateien selbst. Um dies zu vermeiden, schreibt das Betriebssystem die vorgeschlagenen Metadatenänderungen in das Journal, schreibt dann die tatsächlichen Daten auf die Festplatte und wendet dann die im Journal replizierten Metadatenänderungen auf die Festplatte an. Der einzige Haken dabei ist, dass der Festplattencontroller die Anforderungen puffert und möglicherweise neu anordnet. Um dies zu vermeiden, implementieren die meisten Journalling-Dateisysteme Barrieren: Sie trennen jeden Vorgang und warten, bis die Festplatte bestätigt, dass der Vorgang abgeschlossen wurde. Viele moderne Festplatten bestätigen jedoch tatsächlich den Abschluss von Schreibvorgängen, bevor die Daten festgeschrieben werden. Daher können die Dinge chaotisch werden.
Wird nach einem unsauberen Herunterfahren noch ein fsck benötigt und warum?
Die meisten Dateisysteme behalten eine Bereitstellungsanzahl bei. Sobald diese Anzahl erreicht ist, wird beim nächsten Versuch, die Festplatte bereitzustellen, ein vollständiger fsck ausgelöst. Der Grund dafür ist, dass Datenträgerdaten möglicherweise beschädigt werden, auch wenn sie nicht explizit beschrieben werden, auch ohne Fehler in der Software. Der obige Kommentar von psusi ist falsch.
hdparm -W) nicht aktivieren, führt die Festplatte Schreibanforderungen erst aus, wenn sie sich auf dem Medium befindet. Warum gibt es diese Option Ihrer Meinung nach? Barrieren verhindern eine Neuordnung, wenn mehrere Anforderungen ausgegeben werden. Ohne Barrieren gibt das fs einfach keine weiteren Anforderungen aus, bis die vorherigen abgeschlossen sind, wodurch die Reihenfolge ohne Barrieren beibehalten wird ... vorausgesetzt, der Festplattenschreibcache ist nicht aktiviert. Der Zweck von Barrieren besteht darin, Ihnen zu ermöglichen, den Schreibcache zu aktivieren, ohne die fs bei einem Absturz zu beschädigen.
sync. Lass mich es nochmal versuchen. Das Verfahren zum Schreiben auf die Festplatte ohne Barrieren besteht darin, in das Journal zu schreiben, alle Schreibcaches zu syncleeren und dann die realen Daten zu schreiben. Dies stellt sicher, dass das Journal immer verwendet werden kann, um die fs nach einem Absturz wiederherzustellen, aber die Synchronisierung verlangsamt die Arbeit und macht den Zweck des Schreibcaches zur Hälfte zunichte. Daher wurden Barrieren als besserer Ersatz hinzugefügt sync, und mit der richtigen Festplattenunterstützung können sie sicher einen Großteil der Leistung zurückgewinnen, die durch die Synchronisierung beeinträchtigt wird.
Es ist nicht erforderlich, ein Journal-Dateisystem nur aufgrund eines unsauberen Herunterfahrens zu überprüfen.
Der gesamte Grund für die Beeinträchtigung der Laufzeitleistung beim Metadatenjournal besteht darin, sicherzustellen, dass das Dateisystem wieder 100% konsistent gemacht werden kann, indem das Metadatenprotokoll beim nächsten Mounten automatisch wiedergegeben wird, wenn das Dateisystem nicht sauber abgemeldet wurde.
Die einzige Aufgabe von fsck besteht darin, die Konsistenz der Metadaten sicherzustellen. Daher ist es redundant, fsck auszuführen, nur weil das Dateisystem nicht ordnungsgemäß abgemeldet wurde.
Ein Journaling-Dateisystem kann jedoch aus anderen Gründen beschädigt werden - Hardwarefehler, Treiberfehler, Administratorfehler usw. -, sodass fsck-Tools auf jeden Fall erforderlich sind. Es gibt einfach keinen Grund, sie nur aufgrund eines unsauberen Herunterfahrens aufzurufen.