[linux-l] Alle 5 Sikunden...

[Jan-Benedict Glaw]

On Wed, 2003-05-28 12:58:58 +1000, Peter Ross <Peter.Ross at alumni.tu-berlin.de>
wrote in message <Pine.LNX.4.44.0305281244460.1024-100000 at purzelina.optusnet.com.au>:
> On Tue, 27 May 2003, Jan-Benedict Glaw wrote:
> 
> > Wenn Du definierte Punkte haben willst, wo Du (berechtigt) glauben
> > darfst, daß etwas _wirklich_ auf der Platte gelandet ist, dann _mußt_ Du
> > der Platte entsprechend Befehle schicken, daß sie jetzt bitte mal alle
> > eventuellen Caches leert.
> 
> Ja. Das machen Datenbanken am Ende von Transaktionenb z.B. Kann die Kiste 
> ganz schoen bremsen.. Dann hilft entweder eine ordentliche Hardware oder 
> aber eine schlampige Datenbank (tjaja, und dann gibt's die kaputten 
> mysql-Indexes..)

Nicht wirklich - solange Du Festplatten benutzt und von Zeit zu Zeit
darauf wartest, daß eine Platte wirklich einen Block physikalisch
geschrieben hast, verlierst Du jedes Mal wieder einige Millisekunden.

Wenn Du dann noch IDE nimmst, kann zudem kein anderer zwischenzeitlich
auf die Platte zugreifen (wenn Du nicht TCQ am Laufen hast, was aber
anscheinend noch recht gackelig ist und nur von wenigen IDE-Platten von
der Firmware her unterstützt wird).

> > Datei-Inhalte werden im Cache (RAM) gehalten. Um auf den Spezial-Fall
> > ext3 einzugenen, da hast Du drei Optionen:
> > 
> > man 8 mount:
> > --------------------------------------------------------------------
> >               ordered
> >                    This is the default mode.  All data is forced directly out
> >                    to the main file system prior to its metadata  being  com­
> >                    mitted to the journal.
> > 
> > --------------------------------------------------------------------
> > 
> > "ordered" ist Default. Das heißt hier, daß zuerst alle Daten zur Platte
> > geschickt werden. Danach wird über das Journal das Update der Meta-Daten
> > gemacht. Das Journal wird synchron geschriben. Wenn also das
> > Journal-Schreiben beendet ist, haben die Daten ebenso auf der Platte zu
> > sein.
> 
> Wuerde das nicht bedeuten, dass der bdflush-Parameter praktisch oft
> bedeutungslos wird? Ich meine, das Schreibvorgaenge in der Regel kuerzer 
> als 30 Sekunden sind, so dass eh, da Jourmalschreiben synchron 
> stattfindet, wesentlich haeufiger gesynct wird?

bdflush soll Daten zur Platte tragen. Das hindert aber einen
Dateisystem-Treiber (oder den raw-Treiber;) nicht, auf den Block-Treiber
zu warten, bis dieser fertig hat.

Wenn der Dateisystem-Treiber jeglichen I/O submitted und wartet, dann
werden die Daten effektiv früher geschrieben, als sie vom bdflush
sonstig zur Platte getragen worden wären...

> Entschuldige die Nachfrage, irgendetwas habe ich hier, glaube ich, nicht 
> recht verstanden..

Fragen ist gut! Da kann man (und alle anderen auch ) 'was bei lernen.
...führt dazu, Dinge zu verstehen und nicht mit gefährlichem Halbwissen
durch die Gegend zu rennen...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20030528/5253aa18/attachment.sig>