Re: tmpfs mit wenig RAM

Polytropon <freebsd(at)edvax.de> wrote:
> Um da mal kurz einzuhaken: Mich hat es immer gestört, daß bei
> Backups von ~/.*/-Verzeichnissen, in denen durchaus sicherns-
> werte Inhalte lagen, auch immer Schmodder wie Browser-Caches
> mitgezogen wurden. Gibt es da einen bequemen Weg, diese auf
> /tmp umzulenken, gleich ob /tmp nun im RAM, auf einer eigenen
> Partition oder als Teil eines allumfassenden / existiert?

Symlinks?

Ich persönlich lasse Operas Disk-Cache aber dort, wo er
ist (siehe unten). Ich mache Backups mit cpdup, und das
verwendet eine Exclude-Datei (".cpignore" per Default).
Dort habe ich einfach die Unterverzeichnisse "cache" und
"icons" von Opera aufgenommen.

> > Die
> > Gefahr, daß entweder RAM und/oder /tmp-Platz "umbemerkt" kritisch
> > ausgehen ist dort IMHO eher gering.
>
> Kommt drauf an. So ein Opera-Cache kann z. B. über längeren
> Gebrauch durchaus auf knapp 1 GB anwachsen.

Opera cacht Daten sowohl im RAM als auch auf Platte (man
kann dies auch getrennt voneinander konfigurieren), daher
ist davon auszugehen, dass sich die Programmierer dabei
etwas gedacht haben. Unter anderem wird die Lebensdauer
(Expiry) der Daten in die Entscheidung einfliessen, wo es
gecacht wird. Aus diesem Grund würde ich den Disk-Cache
von Opera eben _nicht_ ebenfalls auf den RAM umbiegen
(z.B. TMPFS), wo er mit dem "normalen" RAM-Cache quasi
konkurriert.

Das ist sicherlich auch nicht Opera-spezifisch, sondern
bei anderen Browsern ähnlich.

Übrigens wird die Rolle von RAM-Disks häufig überbewertet.
Bei vielen Dingen bringen sie nicht nennenswert mehr
Performance als eine "normale" Festplatte. Beispielsweise
sorgt Soft-Updates dafür, dass transiente Dateien, die nach
ein paar Sekunden wieder gelöscht werden, niemals auf der
Festplatte physikalisch existieren (weder Daten noch Meta-
daten).

> > Bei wenig RAM - und wenn absehbar ist, daß jedes KB dem laufenden
> > System besser zu Gesicht steht als Temporärspeicher, KDE und
> > Gome-Desktops z.B.) würde ich wohl eher auf die Geschwindigkeit beim
> > Schreiben und Lesen auf /tmp, /var/tmp verzichten und den Speicher
> > dem System(Caching) bzw. den Anwendungen zur Vefügung stellen.
>
> Richtig. Die Problemprogramme werden eher nicht mit /tmp arbeiten,
> sondern ihre eigenen malloc()s machen, die dann in den RAM und
> bei dessen Erschöpfung in den swap gehen - bildlich gesprochen
> natürlich, stimmt ja technisch so nicht ganz, aber in etwa. :-)

Andererseits kann man sich auf den Standpunkt stellen, dass
das OS selbst am besten wissen sollte, welche Daten in den
Swap gehören und welche eher im RAM gehalten werden sollten.
Und TMPFS ist ja im Grunde genommen auch nichts weiter als
ein Prozess-Image (ok, stimmt auch nicht ganz), das geswappt
werden kann, oder eben auch nicht.

Wenn RAM knapp wird, wird das OS die Daten rausswappen, die
am wenigsten benötigt werden. Wenn /tmp eine physikalische
Disk ist, ist die RAM-Benutzung nicht viel geringer, denn
die Daten in /tmp werden dann natürlich auch im RAM gecacht.

Der entscheidende Unterschied ist, dass bei TMPFS die Daten
zunächst _nur_ im RAM landen (es sei denn, der RAM ist von
Anfang an zu knapp, aber dann hat man eh ein Problem).
Bei einer Disk-Partition dagegen landen die Daten auf der
Platte _und_ im RAM (Cache).

Insofern kann man bei ber Benutzung von TMPFS ruhig etwas
mutiger sein.

> Eau cónträir! Früher waren virtuelle Maschinen, die für jedermann
> verfügbar waren, sogar der Normalfall! :-)

Naja, nicht für jedermann. Für Wissenschaftler, Studenten
und andere Angehörige von Unis und Forschungseinrichtungen,
bzw. für Mitarbeiter der ganz großen Firmen, die sich das
"Large Iron" leisten konnten. Aber es kommt wohl darauf,
welche Zeit Du genau mit "früher" meinst ...

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"When your hammer is C++, everything begins to look like a thumb."
        -- Steve Haflich, in comp.lang.c++
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message