Re: Linux-Speicherverwaltung

[Stefan Hagen <sh@xxxxxxxxx>]

Werner Holtfreter wrote:
> --------------------------------------------------------------
> md5sum /dev/sda #buff/cache bleibt belegt bei Systemplatte
>
> md5sum /dev/sdb #buff/cache wieder frei nach Abbruch, wenn die 
> Platte *nicht* gemountet ist
>
> md5sum /dev/sdb #buff/cache bleibt belegt, wenn die Platte
> gemountet ist, wird aber wieder frei nach umount
> --------------------------------------------------------------
>
> Das scheint der Logik zu folgen, was nicht gemountet ist, kann nicht 
> zugeordnet werden und wird im RAM wieder geloescht.

Ich denke das hast du genau richtig erkannt. Wenn du Dateien hin und her 
schiebst, dann passiert vereinfacht gesagt folgendes:

1. Datei vom Quelldatentraeger lesen und im Hauptspeicher ablegen
2. Datei vom Hauptspeicher lesen und auf den Zieldatentraeger schreiben

Statt proaktiv, die Datei aus dem Hauptspeicher zu loeschen, laesst Linux 
sie dort. Wenn die Datei kurz danach noch einmal vom Quelldatentraeger 
angefordert wird, dann spart sich Linux das Lesen und holt die Datei 
direkt aus dem Hauptspeicher.

Dabei ist zu beachten, dass Anwendungen Prioritaet haben. Wenn du z.B. ein
grosses Bild in Gimp oeffnest und Gimp dafuer sehr viel Hauptspeicher 
anfordert, dann werden im Speicher gehaltene Dateien verdraengt um diesen 
Speicher bereitstellen zu koennen. (Anwendungsspeicher ist wichtiger als 
Dateicache)

Wenn du unterhalb des Dateisystems arbeitest, also auf Blockgeraete
direkt zugreifst und diese dumpst, dann ist das ein anderes Szenario.
Hier "streamst" du Bits und Bytes die fuer den Kernel keine Dateien sind.
Es sind Bits und Bytes ohne Semantik. Diese muessen auch kurzfristig
ueber den Hauptspeicher wandern, koennen aber nicht wiedererkannt werden
und haben daher keinen Caching-Effekt. Darum wird der Speicher direkt
freigegeben, damit er wieder zum Datei-Caching verwendet werden kann.

Viele Gruesse,
Stefan

-- 
STEFAN HAGEN // GPG 0x52BE43BA
CONTACT: finger(1) finger@xxxxxxxxxxx