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@...