Re: Defer for background checking

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Fri, 21 Oct 2011 19:49:43 +0200 (CEST)

Markus <universe(at)truemetal.org> wrote:
> Am 21.10.2011 15:38, schrieb Oliver Fromme:
> > In der Regel weigert sich mount, ein Dateisystem read-write
> > zu mounten, das nicht clean ist.
>
> Danke an Dich und Lars fuer die Infos. Was ich gesucht habe war die Info
> bzgl. des clean-flags, die mir file -s liefert.

Da würde ich eher "dumpfs /dev/xxx | grep -m1 clean" nehmen.
Bei read-write-gemounteten Dateisystemen sollte da immer
"clean 0" stehen.

> fsck koennte nach einem erfolgreichen oder nicht erfolgreichen
> background-fsck eigentlich doch einfach einen Logeintrag in
> /var/log/messages schreiben: "fsck done, file system is now clean".
> Macht es aber leider nicht.

Die Ausgabe vom Background-fsck landet natürlich im syslog.
Als Facility wird daemon.notice genommen. Das sollte
eigentlich in /var/log/messages landen, wenn Du an der
sysctl.conf nichts geändert hast.

> Ich frage mich, was ist, wenn der background-fsck nicht erfolgreich
> durchlaeuft.

Theoretisch (!) kann das nicht passieren, da Soft-Updates
nur solche Inkonsistenzen hinterlassen kann, die vom Back-
ground-fsck repariert werden können. Wie gesagt, theore-
tisch. Siehe meine vorhergehende E-Mail.

> Der User wird ja darueber nicht informiert.

Doch sicher. Wenn mit dem fsck irgendwas schiefgeht, kann
man das in /var/log/messages nachlesen.

> Das Filesystem ist dann einfach nicht clean, wird aber
> dennoch einfach weiterhin read-write eingehaengt?

Es ist in jedem Fall nicht clean, da es ja gemountet ist.
Du meinst vermutlich, dass fsck noch Inkonsistenzen fest-
stellt, die es im Background-Modus nicht repariert kann.
Theoretisch sollte sowas nicht passieren, siehe oben.
Aber wenn doch, sollte man besser schleunigst das Datei-
System unmounten und ein "richtiges" fsck machen. Und
wenn man ganz paranoid ist, zieht man vorher ein Duplikat.
Und wenn man ein aktuelles Backup hat, sollte man es
evtl. zum Vergleich (und nötigenfalls zum Restaurieren)
heranziehen.

> Oder wird es dann automatisch als read-only remounted?

Nein. Leider nicht. Besser wäre das in der Situation
vermutlich. Aber wie gesagt: Theoretisch kann das ja
sowieso nicht passieren ...

> Oder ist es gar nicht moeglich dass der background-fsck nicht
> erfolgreich durchlaeuft? :)

Es sind Szenarien denkbar, wo das möglich ist. Das kann
z.B. Folge äußerer Einwirkungen sein, z.B. ein Hardware-
Schaden oder eine Firmware-Bug der Festplatte.

> Das mount sich bei einem non-clean filesystem weigert zu mouten kann ich
> nicht nachvollziehen. Man bekommt zwar die Meldung "WARNING: /mntpoint
> was not properly dismounted", aber das wars und das Filesystem wird
> dennoch read-write gemounted.

Ja, natürlich, sonst würde Background-fsck ja nicht funk-
tionieren. Das geht aber *nur*, wenn auf dem Dateisystem
Soft-Updates eingeschaltet sind. Anderenfalls weigert
sich mount tatsächlich, und man muss auf jeden Fall ein
reguläres fsck durchführen, bevor sich das Dateisystem
read-write mounten lässt.

Der Hintergrund ist folgender: Soft-Updates puffert alle
Schreibzugriffe und sortiert sie so um, dass die Metadaten
in einer bestimmten Reihenfolge geschrieben werden. Diese
Reihenfolge stellt sicher, dass zu jedem beliebigen Zeit-
punkt das Dateisystem in einem konsistenten Zustand ist,
bis auf evtl. noch nicht freigegebene Daten.

Einfaches Beispiel: Wenn eine Datei gelöscht wird, wird
zuerst der Verzeichniseintrag gelöscht, danach wird der
inode freigegeben (sofern der Link-Zähler dann null ist).
Crasht der Rechner zwischen diesen beiden Vorgängen, ist
das Dateisystem konsistent (keine Daten zeigen irgendwo
ins Nirwana) und man kann normal damit arbeiten, aber es
hängt halt noch ein inode herum, der nirgendwo mehr
referenziert wird. Das Dateisystem kann problemlos
read-write gemountet werden. Das Background-fsck erzeugt
vorübergehend einen read-only Snapshot, damit es von
regulären Schreibzugriffen nicht gestört wird, und
untersucht diesen. Es findet dann die inode-Karteileiche
und gibt den betreffenden inode im Dateisystem frei.

Wenn das Background-fsck aus irgendeinem Grund stirbt,
kann es also sein, dass noch weitere Karteileichen im
Dateisystem liegen bleiben, was aber kein Problem sein
sollte, außer dass sie unnötig Platz belegen.

Andererseits *sollte* das Background-fsck nicht einfach
so sterben oder aufgeben. Wenn es das tut, gibt es
einen Grund dafür. Im allgemeinen deutet es darauf
hin, dass das Dateisystem Inkonsistenzen aufweist, die
es aufgrund Soft-Updates eigentlich gar nicht haben
dürfte. Wenn es sie aber doch hat, dann hat man ein
ernsthafteres Problem. In dieser Situation kann es
sogar sein, dass durch den read-write-Mount bereits
weitere Daten zerstört wurden.

Daher plädiere ich immer wieder für background_fsck="NO".
Im privaten Bereich kommt es ohnehin auf ein paar
Minuten, die das dauert, nicht an. Und im Profi-Bereich
muss man sich überlegen und abwägen, wie man diese
Problematik handhaben will. Es gibt ja durchaus mehrere
Lösungsmöglichkeiten; es kommt immer auf die jeweilige
Situation an.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 21 Oct 2011 - 19:50:06 CEST

search this site