PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : welche Dateien in ramdisk um HD abzuschalten?



G-SezZ
20.12.06, 22:15
Hi,
ich würde gerne sämtliche Daten, die dauerhaft benutzt werden (könnten) in eine ramdisk packen, um die Festplatten alle ausschlaten zu können, solange ich nicht selbst am PC arbeite.
Ich verwende Suse 10.2 und es handelt sich um einen desktop PC. Das abschalten sollte bei laufendem KDE mit laufendem Xine möglich sein. Zum Tv schauen eben.
Zur verfügung stehen 2gb ram, davon würde ich 1,5gb für die ramdisk opfern. Wenns nötig wäre würde ich vll. ncoh ein gb kaufen. aber nur falls es so nciht geht.
Ramdisk anlegen und damit arbeiten ist erstmal klar. mir gehts nur darum was ich alles "auslagern" müsste um die HDs abschalten zu können.
/var und /tmp komplett denke ich.
/etc wäre ja auch kein problem, nimmt ja kaum platz ein.
Aber ich denke ich werde auch einige libs und bins brauchen, um das ständige anlaufen der platte zu verhindern. da müsste ich aber genauer wissen welche, denn für alle ist natürlich nicht genug platz.

Gibt es jemanden der erfahrung damit hat? Oder köntt ihr mir helfen, wie ich das rausbekomme auf welche daten mein system laufend zugreift?
Ich bin für jeden Tipp und link dankbar, denn dazu was brauchbares zu googeln ist nicht leicht.

PS.: ich hab gelesen mit journaling FS wie ext3 und reiser soll es garnciht möglich sein die platten dauerhaft abzuschalten, weil das journal ständig geschrieben wird. Ist das wirklich so? ich kann es mit meiner ext3 partition nciht testen, da die programme noch ständig darauf zugreifen, aber meine platten mit reiser lassen sich eigentlich anstandlos abschlaten und bleiben auch stundenlang aus. (gemountet mit der standart fstab von suse.)

marce
21.12.06, 06:51
Das Journal wird immer geschrieben, wenn was auf der Platte geschrieben werden sollte (auch wenn dies zuerst mal im Cache passiert).

Von den Apps verwendete Libs findest Du (a) über die Abhänigkeiten im Paketmanagement heraus oder (b) z.B. über strace. Diese Libs einfach so zu verschieben ohne das komplette libs-Verzeichnis zu verschieben dürfte allerdings nicht so trivial sein - am ehesten noch per chroot...

Idealerweise werden diese allerdings nicht mehr geladen, wenn sie mal im Cache drin sind...

pferdefreund
21.12.06, 06:52
ist eigentlich kein Problem - einfach, so die gewünschte Anwendung
läuft, lsof, und du sieht, welche Dateien inclusive libs gebraucht werden.
Das zeug dann in der selben Ordnerstruktur in die Ramdisk und
per chroot dortin wechseln. Dann Anwendung starten und die Ruhe genießen

G-SezZ
21.12.06, 11:49
Ich hätte versucht das ganze etwas anders anzugehen, die verzeichnisse, die komplett gebraucht werden wie /var und /tmp auf eigene partitionen zu packen, diese auf eine ramdisk zu kopieren, und dann einfach die festplatte an der stelle aus und die ramdisk einhängen.
Ein problem sehe ich dabei dann durchaus z.b. im libs verzeichnis, da ich dort die benötigten dateien wohl einzeln raussuchen müsste. Ich hätte versucht die dateien auf die ramdisk zu kopieren und auf der platte durch symbolische links zu ersetzen. Ich weiß aber nicht ob das überhaupt funktionieren würde, denn um den link zu lesen müsste die platte ja auch anlaufen denke ich.

chrott ist denke ich die bessere methode, ich sehe da nur ein problem:
wenn cih dann mit dem PC arbeiten will, z.b. OOo starten, was nciht auf der ramdisk liegt, dann findet er es ja nicht, weil er garnicht auf der platte sucht. Ich müsste also erst "manuell" die chroot umgebung beenden, vorher die daten aus der ramdisk auf änderungen prüfen und evtl. die Platte synchronisieren.

...es sei denn ich lege in der ramdisk den kompletten verzeichnisbaum meines systems an, und trage dort jede datei die nciht auf der ramdisk liegt als link auf die platte ein. Somit könnte ich sogar dauerhaft von der ramdisk arbeiten. Ist nur die frage ob das praktikabel ist, wegen der benötigten zeit um die links anzulegen, bzw. evtl. deren platzbedarf.

fuffy
21.12.06, 12:20
Hi!


Das Journal wird immer geschrieben, wenn was auf der Platte geschrieben werden sollte (auch wenn dies zuerst mal im Cache passiert).
Dafür gibt es Abhilfe: http://www.samwel.tk/laptop_mode/

Gruß
fuffy

PS. "Desktop hard drives are usually rated for only 40,000-50,000 spinups, and one spinup every 10 minutes will kill your 40,000-spinup HD in 277 days."

G-SezZ
21.12.06, 13:09
PS. "Desktop hard drives are usually rated for only 40,000-50,000 spinups, and one spinup every 10 minutes will kill your 40,000-spinup HD in 277 days."

genau das will cih ja verhindern.
ich würde die platten mit ner spindowntime von 20-30minuten betreiben, und im standby sollten sie dann in der regel mehrere stunden bleiben, eben ohne wegen jedem pipifax anzulaufen.

Zudem is mir eigentlich relativ egal ob die alte 20gb platte den Geist aufgibt, dann kauf ich vll. endlich mal ne neue :D eigentlich geht mir das ding voll auf den weccker, sau laut, halb im eimer, lilo macht immer probs beim MBR schreiben, viel zu langsam. Aber ich benutz sie trotzdem, weil ich mich nciht damit abfinden kann 20gb im regal liegen zu haben ;)

suck
21.12.06, 14:21
Ohne den "laptop-mode" wird es gar nicht gehen. Ohne wird auf die root-Partition nämlich alle paar Sekunden zugegriffen. Das habe ich selbst ausprobiert: http://linuxforen.de/forums/showthread.php?t=177457

Aber warte, wenn du "/" in den RAM mountest, dann geht es auch ohne diese Tools. Ansonten aber halt nicht.

Für /var/log würde ich ggf. einen USB-Stick einsetzten. Der ist auch lautlos und du verlierst deine letzten Log-Einträge nach einen Crash nicht. Ein Netzwerklaufwerk ginge auch.

Weiter solltest du dir umbedingt das Programm "strip" ansehen.

Ich würde mir im RAMDRIVE die Verzeichnisse bin und lib anlegen. Anschliessend würde ich $PATH und die /etc/ld.so.conf so anpassen, dass diese Verzeichnisse zuerst durchsucht werden. Die Orginaldateien würde ich da lassen, wo sie sind. Alles wichte kann man ja kopieren (und dann strippen).

Wenn der Bootvorgang durch das Kopieren nichjt allzusehr verlangsamt werden soll, ist es ausserdem empfehlenswert ein Image des Ramdrives auf die Festplatte zu schreiben und dann dieses statt aller Dateien einzeln zu kopieren.

G-SezZ
21.12.06, 15:11
Wenn der Bootvorgang durch das Kopieren nichjt allzusehr verlangsamt werden soll, ist es ausserdem empfehlenswert ein Image des Ramdrives auf die Festplatte zu schreiben und dann dieses statt aller Dateien einzeln zu kopieren.

Da es aber um einen Desktop PC geht an dem sich ständig etwas ändert müsste ich dann aber beim runterfahren das image jedesmal neu anlegen, was umso länger dauern wird, denke ich.
Aber so schlimm dürfte das kopieren nciht ins Gewicht fallen, von einer Festplatte auf eine andere dauert ca. 15 sekunden. Mein suse braucht sowieso über 2min zum booten, da kommts dann auch ncihtmehr drauf an ;)

So, eben habe ich mir ein weiteres gb ram gekauft. nun hab ich insgesamt 2gb, davon werde ich nun mal eine 1,5gb ramdisk anlegen, und dann los probieren.

Der Stick für /var/log ist eine gute Idee, endlich mal ne verwendung für meinen alten MP3 Player gefunden ;)


Ich würde mir im RAMDRIVE die Verzeichnisse bin und lib anlegen. Anschliessend würde ich $PATH und die /etc/ld.so.conf so anpassen, dass diese Verzeichnisse zuerst durchsucht werden. Die Orginaldateien würde ich da lassen, wo sie sind. Alles wichte kann man ja kopieren (und dann strippen).
um die platte abschlaten zu können müsste ich ja die ramdisk als / einsetzten, d.h. ich müsste die verzeichnisstruktur mit den benötigten dateien in die ramdisk kopieren, diese chroot'en und innerhalb der ramdisk, bspw. unter /mnt/real_root die festplatte mounten.
$PATH und /etc/ld.so.conf anpassen, damit falls die dateien im normalen verzeichnis nicht gefunden werden, auf der festplatte gesucht wird.

Aber kann cih denn das ganze System in einer chroot umgebung laufen lassen? Bzw. ist das ratsam? wenn cih chroot in einer konsole starte, dann gilt es doch nur für programme, die ich auf dieser konsole ausführe oder?

suck
21.12.06, 15:33
Aber kann ich denn das ganze System in einer chroot umgebung laufen lassen?Das mit dem chroot wird so nicht hinhauen, da du trotzdem normal starten müsstest und dann "/" auf einer Partition liegt. Ein chroot ist sowas wie ein zweites System. Das erste wird so nicht abgeschaltet. Das macht man anders.

Möglichkeit 1) Mit initrd booten und innerhalb der initrd das neue "/" für das spätere System präparieren und in den RAM mounten. Danach wie du sagtest die normale Platte nach /mnt/normale_platte mounten und das zuvpr präparierte neue "/" nach "/". Und zum Schluss dann alles, was auf der Platte bleiben soll irgendwie passend verlinken. Und was in der RAM soll halt kopieren statt verlinken. Anschliessend die initrd verlassen.

Möglichkeit 2) Fast das selbe, aber die initrd niemals verlassen. Alle Dateien, die in den RAM sollen werden einfach mit in die initrd gepackt. Der Rest wird an die passenden Stellen gelinkt.

Mit den laptop-mode-tools ist das Ganze aber erheblich einfacher.

G-SezZ
21.12.06, 16:14
edit.....

kann das sein, dass ramdisks von 1gb garnicht möglich sind? Ich verusche die ganze zeit eine 1,5 oder 1gb in /dev/ram0 anzulegen, laut dmesg gibt es keine probleme, das formatieren klappt auch, aber mount findet dann dort kein dateisystem. ich hab die größe in lilo wieder runter gedreht auf 512MB, das funktioniert.

suck
22.12.06, 15:29
Da bin ich überfragt. Im Kernel selbst kann man da was einstellen. Der normale Wert liegt meine ich bei 4MB. Vielleicht geht's mir 8 oder 16.

Ansonsten gibts da bei den 2.6'er Kernels noch /dev/shm. In meiner fstab z.B. lege ich fest, dass dort 768MB gespeichert werden können. Mit Sicherheit gehen auch mehrere GB. Die Zeile sieht bei mir so aus:
shm /dev/shm tmpfs defaults,size=768M 0 0