Re: T-DSL und -CURRENT

On Wed, Apr 10, 2002 at 06:42:28PM +0200, Oliver Fromme wrote:
> Kleiner Crash-Kurs über Write-Caching bei Festplatten ...
>
> Kirill Ponomarew <kirill.ponomarew(at)t-online.de> wrote:
> > danke :-) Hab's jetzt auch beim cvsup in /usr/src/UPDATING gelesen.
> > Da steht's auch, dass write caching ausgeschaltet ist wegen "on-going
> > concerns about disk write order and file system integrity".
> > Weisst jemand welche Aenderungen in file system reingehen ? Und warum ?
>
> Das Problem ist, daß sich der UFS-Code (insbesondere Soft-
> updates) darauf verläßt, daß die Platte die Schreibzugriffe
> in der Reihenfolge ausführt, in der sie ihr übergeben wer-
> den, damit die Konsistenz des Dateisystems zu jedem Zeit-
> punkt gewährleistet ist.

Ein hartnäckiges Gerücht.
Softupdates verläßt sich nicht auf die Reihenfolge.
Allerdings kann er Schreibzugriffe erst dann starten, wenn die
Abhängigkeiten auf dem Medium sind.
Genau diese Information gibt es allerdings mit IDE Schreibcaches nicht.

> Wenn man nun aber den Write-Cache der Festplatte einschal-
> tet, dann ist der Erhalt der Reihenfolge von Schreibzugrif-
> fen nicht mehr garantiert. Im Falle eines Stromausfalles
> kann es also zu Schäden an Dateisystemen kommen. (Bei
> Crashes ist es egal, denn ein Crash betrifft ja nicht die
> Firmware auf der Platte, die den Write-Cache verwaltet.
> Und bei kaputter Platte und/oder Firmware ist es auch egal,
> denn dann können die Dateisysteme auch bei ausgeschaltetem
> Write-Caching Schaden nehmen.)
>
> Im Grunde genommen sollte jeder für sich selbst entschei-
> den, ob dieses Risiko eingegangen werden kann oder nicht,
> und dann den write-cache bei sich entsprechend aus- oder
> einschalten (geht bei SCSI durch Editieren der entsprechen-
> den Modepage per camcontrol, bei IDE per »set« in der Boot-
> loader-Config).

Das Risiko ist bei stable identisch, allerdings verläßt sich
der Backgroundfsck bei current darauf, das bestimmte Fehler
nicht vorkommen können.

> Wenn man eine USV hat, oder einen Festplattencontroller mit
> NV-RAM (das hat z.B. jeder bessere RAID-Controller), dann
> kann man Write-Caching getrost einschalten. Gleiches gilt
> für Notebooks, die ja ohnehin nicht die schnellsten Platten
> haben.
>
> In allen anderen Fällen muß man es halt abwägen. So ein
> Stromausfall muß ja nicht zwangsläufig zu einem kaputten
> Dateisystem führen. Meistens sind wohl nur Dateien ver-
> loren, in die kürzlich geschrieben wurde. Die Linux-Leute
> leben seit Jahren mit async-by-default Dateisystemen, und
> die riskieren ihre Dateisysteme ja schon bei einem normalen
> Crash; da braucht's keinen Stromausfall.

Genau das ist das Problem mit Backgroundfsck.
Das filessystem wird direkt readwrite gemountet und *darf*
einfach bestimmte Schäden nicht haben.

> In -stable wurde der Default für Write-Caching bei IDE
> mehrfach geändert (bei SCSI bestimmt ohnehin der Hersteller
> den Default). Ich weiß gar nicht, was aktuell der Default
> ist, da ich es eh immer explizit einschalte. Da kämpfen
> halt die beiden Fraktionen »secure by default« und »fast by
> default« gegeneinander.

Wenn die Platte Tagged Comand Queuing kann ist ausschalten
bei Softupdates sogar minimal schneller.
Die Medienbestätigung kommt unverzögert und Softupdates kann
früher die nächsten Abhängigkeiten schreiben.
Mit einem NVRAM Controller ist das egal, da die Medienbestätigung
eigendlich immer aus dem RAM kommt.

> Ich persönlich bin der Meinung, daß das Write-Caching per
> default eingeschaltet sein sollte, und daß der Benutzer in
> ausreichender Deutlichkeit darüber aufgeklärt werden soll-
> te, daß er, wenn er eine unzuverlässige Stromversorgung
> hat, es entweder ausschalten oder (besser) sich eine USV
> zulegen sollte.

Ich persönlich finde es sollte ausgeschaltet sein und die Hersteller
sollten Performance durch funktionierende Techniken ereichen.
Auf IDE kann mans aber ruhig einschalten - wichtige Daten sollte man
auf IDE ja eh nicht speichern.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message