ataidle Ersatz

Crest schrieb:
Kamikaze: willst du wirklich das dir Logs das RAM komplett füllen können? Du hast ja nicht einmal die Größe beschränkt.

Auf einem syslogd mit XORP hatte ich alleine mal >10MB/s an Datenmüll in -/var/log/messages, weil sich XORPs Prozesse alle gleichzeit in ner Endlosschleife drüber beschwerten, weil sie ihren Elternprozess verloren hatten. Das war nicht lustig und hat /var voll laufen lassen.
Zum Vergrößern anklicken....

Für mich gibt es kaum einen Grund, die Syslogs in einem fertigen und funktionierenden System, besonders auf einem Laptop, weiter laufen zu lassen. Ich wiederhole das nochmal: für mich. Das ist nicht allgemein üblich, aber damit habe ich keinerlei negativen Erfahrungen gemacht und habe aus ähnlichen Gründen, wie sie Kamikaze beschreibt, auch Etliches auf tmpfs gelegt.
Selbst auf meinem relativ schmalen EEE mit 2GB RAM funktioniert das bislang tadellos. Ich sehe in der Praxis nur Vorteile.
 
@Fusselbär
Danke für deine Antwort und Recherchen. Die Diskussion kenne ich bereits aus eigenen Recherchen. Man bekommt den aktuellen Status im Übrigen auch wesentlich benutzerfreundlicher via smartctl hin:

Z.B. um die Platte bei der Anfrage nicht aufzuwecken:
Code: 
[~]# smartctl --nocheck standby -i --format=brief -A /dev/ada0
[...]
Power mode is:    ACTIVE or IDLE
[...]


... Aber leider gibt mir weder smartctl noch ataidle Auskunft über den aktuell gesetzten Standby-Timout Wert ... ich durchgrabe gerade schon den FreeNAS PHP-Quellcode um herauszufinden, wie die das gelöst haben ... denn deren Webinterface (vor der kürzlich erschienenen Version 8) zeigen das aktuell gesetzte Timeout im Webinterface an ... ich hoffe nur, dass die das nicht aus ihrer XML DB abrufen ... ;)


Grüße
 
Crest schrieb:
Kamikaze: willst du wirklich das dir Logs das RAM komplett füllen können? Du hast ja nicht einmal die Größe beschränkt.

Auf einem syslogd mit XORP hatte ich alleine mal >10MB/s an Datenmüll in -/var/log/messages, weil sich XORPs Prozesse alle gleichzeit in ner Endlosschleife drüber beschwerten, weil sie ihren Elternprozess verloren hatten. Das war nicht lustig und hat /var voll laufen lassen.
Zum Vergrößern anklicken....
Das ist ja kein Server der unbeaufsichtigt zuverlässig arbeiten muss. Wenn der Speicher voll ist, wird eben geswappt. Dann landet eben der alte Teil des tmpfs im Swap. Passt schon.
 
@Kamikaze:

Ich habe das auf meiner Kiste so gelöst:

echo '#==== Enable tmpFS ====#
tmpfs_load="YES"
' > /boot/loader.conf

echo '#==== Enable tmpFS ====#
tmpmfs="YES"
tmpsize="512M"
tmpmfs_flags="-S"
#tmpmfs_flags="-m 1 -o async,noatime -S -p 1777"
' > /etc/rc.conf

... und für die, die es, wie ich, bis vor kurzem noch nicht wussten:
For other tmpmfs_flags:
man mdmfs
Zum Vergrößern anklicken....
... aber vielleicht willst du das ja aus irgendeinem Grund nicht so ...



P.S. hat noch jemand ne Idee zu dem CAMControl Problem zwecks dem Auslesen des Spindown-Timeouts? Oder gibts zu den CAMControll cmd Befehlen irgendeine Referenz / Dokumentation? Vielleicht gibt es da ja doch noch ne Möglichkeit das auszulesen .. ?! Die Hoffnung stirbt zuletzt ...


Grüße
 
Um die tmpfs Sache abzuschließen:

1. Tmpfs verkleinert sich automatisch wenn der Speicher knapper wird

Ich habe zum Beispiel gerade ein:
# mdconfig -at malloc -s 4g -o reserve

ausgeführt. Damit habe ich auf einen Schlag 4GB Arbeitsspeicher geschluckt (nicht nur angefragt sondern tatsächlich in Beschlag genommen). Das tmpfs hat sich automatisch von 14GB auf 5GB verkleinert.

2. Alle gemounteten tmpfs bedienen sich aus einem Speicherpool

Es gibt also für mich wirklich keinen Grund mich manuell darum zu kümmern.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben