staging.inyokaproject.org

Huhu!

kaputtnik schrieb:

Den Link zu Dateisystem verstehe ich nicht. Ist dort vllt viel mehr die Linux-Verzeichnisstruktur gemeint?

Nee, ist so korrekt. Man könnte auch schreiben:

In einem Dateisystem werden temporäre Dateien gemäß der Linux-Verzeichnisstruktur in /tmp und in einigen Unterverzeichnissen von /var (z.B. /var/run, /var/lock) gespeichert.

Liebe Grüße,

Flo

Ich hab das mal so geändert, dass ihr beide Recht habt 😀.

Oder so ☺

Danke!

Flo

Servus ☺

linrunner schrieb:

Ich hab das mal so geändert, dass ihr beide Recht habt 😀.

Prima, danke. Den Link zu Dateisystem würde ich trotzdem komplett raus lassen weil er an dieser Stelle keinen Mehrwert ergibt (keine Infos dazu im Artikel)

Gruß
kaputtnik

kaputtnik schrieb:

Den Link zu Dateisystem würde ich trotzdem komplett raus lassen weil er an dieser Stelle keinen Mehrwert ergibt

Done.

Der Artikel ist im Wiki. Mein Dank an alle Beteiligten für die konstruktive Zusammenarbeit. ☺

Liebe Grüße

martin

Hallo,

ich bin neu hier und habe schon sehr von den guten Artikeln profitiert.

Zu dem sehr hilfreichen SSD-Auslagern-Artikel hätte ich ein paar Anmerkungen, der vielleicht hilft um die Probleme die ich hatte zu vermeiden:

- Das Auslagern von var/log hat zu folge, dass zuvor vorhandene Unterverzeichnisse nicht mehr vorhanden ist. Damit gibt es für Samba keinen LOG-mehr. Apache2 will erst gar nicht mehr starten, bevor man nicht das Verzeichnis von Hand (jedes mal neu) erstellt. Fragen dazu: Sollte man die ursprüngliche /var/log umbenennen und beim Start/Mount umkopieren (zumindest die Verzeichnisse)? Evtl. beim Herunterfahren zurückkopiert?

- Verlinkung mit ACPI: Im ACPI-Artikel steht bereits, dass STD bei SSD evtl. wenig Sinn macht. Es wäre also wichtig zu erklären, wie man das "deaktiviert" umsetzt. Ich habe beispielsweise einen Homeserver mit 8GB RAM und "shutdown" nach 30 Minuten "idle", da wird ordentlich was auf die SSD geschrieben ...

- Ab Maverick werden die Verzeichnisse /var/lock ... ausgelagert. Bitte hier wie im Kommentar in dieser Diskussion "ins RAM" zufügen. Damit ist klar dass nicht der SWAP-gemeint ist. Vielleicht noch dazuschreiben, dass hier diese Verzeichnisse nicht nochmal verlagert werden müssen.

Grüße -Mario-

Hi -Mario-,

willkommen auf Ubuntuusers.de ☺

Es ist ein Wiki. Du kannst Deine Anmerkungen gerne dort eintragen. Einfach in der Artikelansicht auf "Bearbeiten" klicken.

Bitte auf Wiki/Syntax achten, heißt Verzeichnisse zB fett formatieren.

Gruß
kaputtnik

Hallo kaputtnik,

danke für die nette Begrüßung. Ich habe im Wiki die Teile abgeändert zu Punkt 1) und 3) meiner e-Mail. Wobei Punkt 1) sicher noch Diskussionsbedarf hat, denn es wirft das Problem auf, wie mit Unterverzeichnissen in /var/log umzugehen ist. Eine Variante ist: - Das bestehende /var/log nach /var/logssd umzuhängen - Einrichten der ram-Disk von /var/log - Ein Mount der Ram-Disk von /var/log kopiert alles (zumindest die Verzeichnisse) von /var/logssd um. - Beim Unmount wird /var/log nach /var/logssd zurückkopiert (zumindest die Verzeichnisse).

Warum das ganze bei "geringem" Vorteil? Also, meine "Milchmädchenrechnung" sieht wie folgt aus:

- Nach jeder Zeile die in das log-geschrieben wird, erfolgt ein flush, d.h. tatsächliches Schreiben auf Platte.

- d.h. jede Zeile im Log "produziert" einen Schreibvorgang auf der SSD.

- jeder Schreibvorgang umfasst zumindest 4kB (wegen Dateisystem)

- bei meinem LOG (nur systemstart) sind das ca. 12000 Zeilen.

- d.h. ~48MB/Systemstart

- 400 Systemstarts/Jahr macht ~ 50 * 400 = 20GB

Ist jetzt zwar nicht das ganz große Problem, aber für Heimserver mit kleiner SSD macht sich das schon in der Lebensdauer bemerkbar.

Zu Punkt 2) bin ich selbst noch am Überlegen wie das funktionieren könnte, da kann ich eher wenig dazu schreiben.

Gruß -Mario-

Ich hatte damals die Warnweise zu /var/log aufgenommen. Auch aufgrund deiner Erfahrungen würde ich mittlerweile vorschlagen /var/log ganz rauszuwerfen. Das Abnutzungsargument ist übrigens nicht zutreffend, denn rsyslog schreibt nicht jede Zeile einzeln.

Ähm,

was waren nochmal konkret die Probleme, die auftreten können, wenn man /var/tmp in den RAM packt?

Es gibt zwei Probleme:

1. haben weder Du noch deine SSD einen Vorteil davon.

2. sagt der FHS dazu "The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots.". Falls sich also eine Anwendung, ein Installationsprogramm o.ä. darauf verläßt, daß der Inhalt über einen Neustart hinweg erhalten bleibt, hat es Pech gehabt.

linrunner schrieb:

Es gibt zwei Probleme:

1. haben weder Du noch deine SSD einen Vorteil davon.

2. sagt der ...

Danke, das (Punkt 2) wollte ich nochmal wissen.

Aber warum ist Auslagerung prinzipiell nicht von Vorteil (Punkt 1)?

themroc schrieb:

Aber warum ist Auslagerung prinzipiell nicht von Vorteil (Punkt 1)?

"Auslagerung" ist eigfentlich als Ausdruck eine Krücke, die wir in diesem Artikel nur gewählt haben, um einen prägnanten Begriff im Titel zu haben. Eigentlich müßte/sollte das heißen:

"Verlagerung von Teilen des Dateisystems von der HD/SSD ins RAM"

Hintergrund war die Tatsache, daß SSD's nur eine limitierte Anzahl von Schreibzyklen je Zelle (besser Block) vertragen. Also wollte man mit aller Macht die Schreibvorgänge auf die SSD minimieren, indem man so viele wie möglich einfach ins RAM verlagerte.

Bei modernen SSD's ist das völlig unnötig, denn die haben eine ausgeklügelte und wirksame Müllabfuhr (zu Deutsch: "garbage collection"), die dieses Vorgehen praktisch überflüssig macht. Manchmal ist es sogar kontraproduktiv, ein Beispiel:

Im Laptop sollte die swap Partition auf der SSD liegen, denn bei Hibernate (suspend to disk) beschleunigt das das Aufwachen ganz enorm Dank SSD.

Viele Grüße,
Ingo

Also empfiehlst Du bei einer SSD gar nichts mehr auszulagern?