Re: AW: write cache und softupdate

From: Bernd Walter <ticso(at)cicely5.cicely.de>
Date: Wed, 29 May 2002 00:46:47 +0200

On Wed, May 29, 2002 at 12:07:43AM +0200, thomas vogt wrote:
> Hallo
>
> > > thomas vogt <turbo23(at)gmx.net> wrote:
> > > Ist es besser, wenn man den "write cache" von IDE Festplatten
> abstellt,
> > > sofern man Softupdates eingestellt hat?
> >
> > Oliver Fromme wrote:
> > Darüber streiten sich die Geister ... Meine persönliche
> > Meinung: Wenn man sicherstellen kann, das es keinen Strom-
> > ausfall gibt (indem man z.B. eine USV und ggf. redundante
> > Netzteile verwendet), dann geht man durch das Einschalten
> > des Write-cache kein Risiko ein. Zumindest kein größeres,
> > als die Verwendung von IDE ohnehin schon ist.
> >
> > Man muß sich im Klaren darüber sein, daß bei eingeschalte-
> > tem Write-cache im Falle eines Spannungsverlustes die Kon-
> > sistenz des Dateisystems den Bach runtergeht; da hilft dann
> > auch Soft-updates nicht mehr. Ob man das Risiko eingehen
> > möchte, muß jeder für sich selbst entscheiden.
>
> Danke. Das ist so in etwa dasselbe, was ich in der englischen
> Mailingliste gefunden habe.
> Dann sollte mein Frage wohl lauten:
> Ist es ein so grosser Geschwindigkeitsverlust, wenn man den Write Cache
> auf der Platte abschaltet?

Softupdates bringt mehr Performance durch sortiertes Verzögertes
Schreiben ohne ein Risiko bezüglich der Filesystem Integrität zu
haben.
Ohne Softupdates ereicht man das durch syncrones Schreiben.
In beiden Fällen jedoch bringt ein aktive Schreibcache die Schreib-
reihenfolge unkontrolliert durcheinander.
Schreibcache ist also immer ein Risiko fürs Filesystem.
Das ganze kann man sogar bis zu einem Sicherheitsrisiko hochspielen.
User A löscht eine Datei mit vertraulichen Daten.
User B legt eine neue Datei an und bekommt die gleichen Datenblöcke,
welche User As Datei hatte.
Der Plattencache schreibt nun User Bs Dateiallokierung und der Strom
geht weg, bevor der Plattencache die Dateiblöcke geschrieben hat.
Nach dem Booten hat User B nun den Inhalt von User As ehemaliger Datei.
Der Fall ist nicht theoretisch, sondern tatsächlich Umsetzbar.

> Wenn nicht, dann steht dem Abschalten ja nichts im Wege oder gibt’s
> sonst noch Probleme?

Die Lineare Schreibperformance geht den Bach runter.
Nichtlineare ist eh schon langsammer, sodas hier der Effekt nicht
so stark bis gar nicht spürbar ist.

Das liegt daran wie IDE funktioniert - oder halt nicht funktioniert.
Moderne Platten schreiben ohne Interleave um mehr Durchsatz zu bekommen.
D.h. Sektor 1 liegt direkt hinter Sektor 0 auf dem Medium.
Wenn man Sektor 0 schreibt wartet der Rechner ohne Schreibcache auf
die Schreibbestätigung der Platte - danach schreibt er Sektor 1.
Dummerweise ist der aber in der Zwischenzeit am Schreibkopf vorbei-
gerauscht und die Platte muss eine Umdrehung warten.
Bei SCSI gibt es Tagged Command Queueing, was bedeutet, das man
den Schreibbefehl für Sektor 1 absetzen kann während man noch auf
die Bestätigung von Sektor 0 wartet.
Wenn die Platte Sektor 0 geschrieben hat kann die Platte sofort
mit Sektor 1 weitermachen, ohne eine Umdrehung zu warten.
In der Realität schreibt man zwar keine hinternanderfolgenden
Einzelsektoren, sondern 8k-64k an einem Stück, aber dazwischen
liegen halt immer die Warteumdrehungen.

Es gibt auch den Fall, daß Sektor 1 vor Sektor 0 kommt um den
Prereadcache schneller zu füllen.
Aber auch dann kann man einfach nachvollziehen, daß die Schreib-
performance darunter leided, wenn man maximal eine ausstehende
Schreibtransaktion haben kann.

Oh ja - IDE hat seit ATA TCQ in der Norm - nur wirklich funktionierende
Implementierungen sind für Billigzeug kein Verkaufsargument, sodas
es bis heute lediglich ein paar IBM Experimente gibt.
IDE in einer funktionierenden Betriebart ist nun mal Lahm.

-- 
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
Received on Wed 29 May 2002 - 00:47:01 CEST

search this site