Gentoo auf SSD & HDD aufteilen, Partitionen? & Anderes

[Krik]

Moin

Wegen dieser News bin ich am überlegen, ob ich mir zwei SSDs im RAID 0 als Systemplatten einsetze.

Ich würde dann dieses Mal Gentoo als OS verwenden wollen. Nun hat mein PC aber nur 1 GB RAM und das ganze Kompilieren braucht ja doch mal mehr Platz und lagert deshalb aus. Swap soll auf eine mechanische HDD ausgelagert werden. Und jetzt kommt der Punkt: Wenn ich mich richtig erinnere, sollte man für Gentoo /tmp auch extra haben (/var auch?).

Wie groß sollte /tmp in etwa sein. Ich will nicht solche Monster wie OpenOffice und KDE kompilieren. Aber Gnome (wobei sich hier die Frage stellt, ob Gnome ähnlich viel Platz wie KDE benötigt) sollte schon passen.

Ich habe mir die Partitionsaufteilung etwa so gedacht:
2x SSD 32 GB - sda & sdb (Software RAID 0)
2x HDD 200 GB - sdc & sdd
2x HDD 500 GB - sde & sdf

sda/sdb - 64 GB - /
sdc - 128 MB - /boot
sdc - 2 GB - Swap (4 GB?)
sdc - 2 GB - /tmp (4 GB?)
sdc - 2 GB - /var (sollte man das tun?)
sdc - Rest - /home
sdd - 200 GB - /home/laurin/Windows (Windows HDD)
sde - 500 GB - /home/laurin/Backup1
sdf - 500 GB - /home/laurin/Backup2

Hat schon jemand eines der Flash-Speicher-optimierten Dateisystem verwendet und kann was dazu sagen? Es gibt ja JFFS2, YAFFS und ein paar andere.

Gruß, Laurin

 

[aki]

Hi

Prinzipiell ungeeignet für SSD halte ich /usr/portage/, weil dort durch den Portage-Tree recht viel Bewegung von kleinen Dateien stattfindet. Das könnte sich recht negativ auf die Lebensdauer der Speicherchips auswirken. In /tmp passiert nicht viel, dafür aber in /var/tmp. Dort landet der entpackte Sourcecode und der ganze Datensalat wärend des Kompilierens (/var/tmp/portage). Benutzt man den Compiler-Cache (ccache), um das Kompilieren ansich zu beschleunigen, dann hat man wiederum einen ganzen Haufen Daten in /var/tmp/ccache.

Ich würde also, und so habe ich es auch getan, /usr/portage/ und /var/tmp/ (oder generell /var/) jeweils auf eine eigene Partition legen und das, wenn möglich, nicht auf eine SSD. Für den Datensalat ist der knappe Speicherplatz eh zu schade. Man muss aber sagen, dass Portage wohl verdammt schnell wäre durch die Zugriffszeiten

2GB ist für /var zu wenig würde ich sagen. Das kann sich, je nachdem was man kompiliert, sehr aufblasen. Ich habe 10GB, wovon 2GB durch ccache schon belegt sind. Dafür die /tmp Partition weglassen.


Ich hatte übrigens den gleichen Gedanken nach der SSD-News Gentoo auf Soft-Raid0


KDE ist übrigens kein Monster. Du musst ja nicht gleich "kde" emergen, sondern kdebase reicht völlig. Die restlichen Programme gibts in der Regel auch einzeln, so das man nur das nötigste installieren muss.


mfg
aki

 

[Krik]

Vielen Dank für die Infos

Welche Größe muss man für /usr/portage ungefähr einplanen?

 

[sturme]

Der Einfachheit halber poste ich einen relevanten Ausschnitt (/home, /mnt usw. sind ja nicht von Belang) meines Systems von df -h:

Filesystem            Size  Used Avail Use% Mounted on
/dev/root             7,4G  419M  7,0G   6% /
/dev/sda6              15G  8,9G  5,9G  61% /usr
/dev/sda7             8,7G  6,4G  1,9G  78% /usr/portage/distfiles
/dev/sda9              52G   24G   25G  49% /opt
/dev/sdb2              14G  3,6G  9,5G  28% /var
tmp_portage           2,0G   73M  1,9G   4% /var/tmp/portage

Dazu muss ich sagen, dass ich sehr viele Packages installiert habe (über 1200 insgesamt), daher auch ein stattliches /usr/portage/distfiles.

/usr und /var sind kürzlich auf reiserfs-Partitionen übersiedelt weil dieses Dateisystem bei vielen kleinen Dateien erhebliche Vorteile gegenüber ext3 bietet. Besonders bei meinem Notebook mit 5400rpm Platte hat sich das bemerkbar gemacht - ein 'emerge --sync' ist damit kein Vergleich zu vorher.

/usr/portage/distfiles habe ich dafür auf eine ext2 Partition ausgelagert um sowenig Overhead wie möglich haben, das ist ja lediglich ein Lagerplatz.

tmp_portage ist hier eine mit 2GB in der /etc/fstab definierte Ramdisk was den emerge-Prozess ganz erheblich beschleunigt, zusätzlich kann man auch /tmp in eine Ramdisk auslagern, so habe ich das bei meinem Notebook bereits gemacht - es genügen dabei aber locker 32MB oder weniger, darin passiert wie schon erwähnt nicht viel. Natürlich kann man sich bei 4 GB Arbeitsspeicher besonders ungeniert mit Ramdisks spielen, diese festgelegten 2GB sind aber ein Maximalwert - die Ramdisk belegt nur soviel Speicher wie tatsächlich benötigt wird. Angeblich würde OpenOffice mit 2 GB scheitern...

Die entsprechende Zeile für die Ramdisk in /etc/fstab:

tmp_portage             /var/tmp/portage        tmpfs   size=2000M,nr_inodes=2M 0 0

Mein /var ist natürlicherweise relativ klein, die 3.6 GB beinhalten bereits einen 1.8 GB großen ccache, und durch das ausgelagerte tmp_portage wächst /var auch während einem emerge nicht an. Standardmäßig allerdings kann /var ganz gewaltig anschwellen, da erstens der Datensalat abgebrochener emerges nicht aus /var/tmp/portage gelöscht wird, und zweitens natürlich während einer großen Installation wie eben z.b. OpenOffice temporär sehr viel Platz benötigt wird. Deshalb ist es gut, einem /var viel Luft zu geben.

Grundsätzlich würde ich dieselben Argumente, die für reiserfs sprechen, auch auf SSDs anwenden, mit der Ausnahme dass sich /usr/portage wirklich nicht unbedingt darauf auszulagern empfiehlt (aus dem bereits von aki genannten Grund, auch wenn das Lebenserwartungsproblem ja "gelöst" sein soll). Es stellt sich ja auch die Frage wie relevant ein schnelleres 'emerge --sync' und 'emerge -uvaD' für den täglichen Gebrauch überhaupt ist.

Schon bemerkbarer macht sich, z.B. die verbleibenden Reste von / auf die SSD auszulagern, die für den Systemstart wichtig sind (und deshalb auch nicht in andere Partitionen aufgetrennt werden sollten/können wie z.B. /lib, /bin, /etc...), sowie die Beschleunigung der Ladevorgänge aller Userspace-Programme. Dazu genügt die Auslagerung von /usr auf die SSD, da sich dort natürlicherweise am meisten bei Gentoo abspielt, weil nun einmal praktisch alles selbst compiliert ist und deshalb dort landet.

Mit alternativen Filesystemen habe ich noch keine Erfahrung gemacht, ich habe allerdings selbst schon mit dem Gedanken gespielt mir demnächst eine SSD anzuschaffen - oder doch vorerst nur eine kleine Velociraptor... Ich denke jedenfalls reiserfs ist für eine SSD bestens geeignet, und da die SSDs sich ja bereits selbst um eine möglichst schonende Nutzung der Speicherzellen kümmern, bedarf es nicht auch noch eines Filesystems das sich darauf konzentriert.

 

[Stefreak]

zum kompilieren braucht gentoo bei den Standardeinstellungen kaum ram (außer du lagerst das auf tmpfs aus).
Ich persönlich würde 2gb swap auf die ssd machen, wegen der Geschwindigkeit.
Weil du bei der ssd keine probleme mit fragmentierten Festplatten hast, brauchst du die Festplatte auch nicht sehr zerteilen - nur eben der lebensdauer wegen wie oben schon erwähnt wurde. Sonst wird das auch ganz gut im Handbook beschrieben: http://www.gentoo.org/doc/de/handbook/handbook-amd64.xml?part=1&chap=4
Viel Spaß mit gentoo, hoffe es gefällt dir genauso wie mir

 

[Krik]

Vielen Dank für eure Tipps. Ich habe das mal aufgearbeitet und das ist herausgekommen:

2x SSD 32 GB - sda & sdb (Software RAID 0)
1x HDD 200 GB - sdc & sdd

sda/sdb
+- sda1/sdb1 - 64 GB - ReiserFS3 - /

sdc
+- sdc1 - 128 MB - Ext3 - /boot
+- sdc2 - 2 GB - swap - Swap
+- sdc3 - 12 GB - ReiserFS3 - /var
+- sdc4 - Rest - Extended Partition
+--- sdc5 - 12 GB - Ext2 - /usr/portage
+--- sdc6 - Rest - ReiserFS - /home

RAM-Disk - 640 MB - tmpfs - /var/tmp/portage


/var ist 12 GB groß, das könnte für meine Zwecke ein wenig übertrieben sein. 8 GB tun es vermutlich auch. Dasselbe bei /usr/portage.
Der Tipp mit der RAM-Disk ist sehr gut Ich habe mich für max. 640 MB entschieden. So bleiben trotz voller Ausnutzung noch 320 MB für die Anwendungen übrig. Das sollte reichen. Falls die RAM-Disk mal zu voll wird, lagert er dann auf Swap aus? Oder bricht er mit einer Fehlermeldung ab?

Mir kam da gerade noch eine Idee. 64 GB für / ist sehr viel. Die werde ich nie komplett nutzen. Vermutlich sogar weniger als 2 GB (Minimalist ). Ich dachte mir, dass ich / nur 8 GB gebe und den Rest /home zuweise, zusätzlich zu dem /home auf der mechanischen Festplatte. Beide Partitionen würde ich dann mit UnionFS verbinden und die Priorität auf die SSD legen. Also er benutzt zuerst den Speicherplatz der SSD und dann den der HDD. Was haltet ihr von dem Gedanken?
Ich bin bei Wikipedia nicht richtig schlau daraus geworden, wie UnionFS funktioniert. Würde es das /home auf der HDD als nur-lesbar betrachten?

Edit:
Wenn ich mir das so überlege... 56 GB für /home reicht eigentlich vollkommen. Und so stark nutze ich es nun auch nicht, dass die SSD darunter leiden könnte (alle paar Tage mal einen Download, der dann wieder gelöscht oder sonstwohin verschoben wird).

 

[Sensei21]

e-Laurin, probier es mal mit reiser4 + zen-sources bzw. zenmm-sources:

das ist zurzeit das schnellste was es gibt (+ das stabilste -> zenmm):

http://zen-sources.org/cgi-bin/gitweb.cgi?p=kernel-mm.git;a=summary

http://zen-sources.org/cgi-bin/gitweb.cgi?p=kernel.git;a=summary

ein anderer vorteil ist, dass reiser4 so gestrickt ist (durch seinen "atomaren" aufbau) so wenig schreibzyklen benötigt wie nötig, außerdem ist der speicherverbrauch um einiges geringer als bei den anderen dateisystemen: bei mir ist es momentan die Hälfte, ein Drittel vom Ursprünglichen ist ebenfalls möglich (mit gzip-Kompression)

das schont die SSDs, verlängert die Lebenszeit & steigert die Produktivität
2.6.26-rc8-zenmm3 ist momentan sehr zu empfehlen: mega stabil, sauschnell, reagiert immer (auch bei 2600% Belastung) und ist auch sehr sparsam (powertop)

aktiviere noch compcache + tlsf, dann wird die swap auch (komprimiert) im speicher abgelegt -> schont nochmals die SSD

spiel noch ein bißchen mit swappiness und anderen einstellungen rum, dann wirst du lange deine freude mit dem system haben

empfohlene partitionen:
/boot, /, swap, /home, /usr/portage mehr braucht keiner

hier die erklärung / grundlagen von reiser4:

http://www.linux-magazin.de/layout/set/print/content/view/full/4459

 

[Stefreak]

Ich schließe mich freak01 an, mehr partitionen brauchst du nicht. Das mit der Ram-Disk ist auch nicht sehr gut, weil einige Pakete schon viele Gigabyte zum kompilieren brauchen (X oder openoffice). Und einen wirklichen Geschwindigkeitsvorteil hast du kaum!

MfG
Stefreak

 

[Krik]

Interessant wie unterschiedlich die Meinungen doch sind.

Die einen gehen lieber auf Nummer sicher und legen die am intensivsten genutzten Bereiche auf eine HDD (dazu würde ich mich zählen), den anderen ist das egal, sie setzen eher auf Verringerung der SSD-Zugriffe.

Wenn man jetzt noch beide kombinieren könnte, also nur die Vorteile von jeder Idee... hmmmm


Na jedenfalls bin ich jetzt durcheinander und nicht mehr sicher, was ich am besten mache. SSDs sind leider noch zu neu bzw zuwenig verbreitet, als dass schon ausreichend Erfahrungen angehäuft wurden.

 

[Stefreak]

Das mit den Erfahrungen kommt noch. Und wenn es so weit ist sind die SSDs auch schön billig und alle sind glücklich.

 

[sturme]

Ja, reiser4 ist ein sehr geniales Filesystem, ich hoffe es schafft es irgendwann einmal in den vanilla-Kernel... so problemlos ist dessen Betrieb aber leider noch nicht.

Ich frage mich was es bringt, swap auf die SSD zu legen... das wird ohnehin so gut wie nie angerührt. Bei 1 GB RAM vielleicht noch eher, aber ich würde da ohnehin ein Upgrade empfehlen bevor eine SSD ins System kommt. Eben weil durch die Ramdisk während des emerge extrem viele temporäre Schreib-, Lesezugriffe und Löschungen eingespart werden können, selbst normalen Festplatten kommt das gelegen (und der Lautstärke des Systems beim Installationsvorgang). Außerdem finde ich gehören temporäre Daten einfach aus Prinzip in den Arbeitsspeicher, dazu ist er da.

Verzichtet man aus Kosten- oder anderen Gründen auf eine solche Ramdisk, empfiehlt es sich zumindest /usr und /var auf verschiedenen Platten zu betreiben, wenn möglich - weil aus /usr/portage/distfiles auf /var/tmp/portage entpackt wird, und die fertigen Builds von /var/tmp/portage zum Großteil schließlich auf /usr zurückkopiert und anschließend gelöscht werden. Das spart viel Festplattenrattern (durch die ansonsten gleichzeitigen Schreib-/Lesezugriffe) und Zeit, selbst ohne Ramdisk (die diese Vorgänge natürlich noch einmal massiv beschleunigt).

@Stefreak: X ist schon lange kein Riesenpaket mehr, seit es modular aufgebaut ist (afaik seit 7.0) sind es unzählige Minipakete.

@e-Laurin: 640 MB tmpfs sind 640 MB, darüber hinaus wird dann auch nicht geswapped - ein emerge, das mehr Platz benötigt wird also scheitern. In solch selten auftretenden Fällen kann man die Ramdisk ja einfach unmounten.

PS: Wer Partitionen sparen will um etwa auf einer kleineren Notebook-Festplatte (oder eben auch einer SSD) nicht zuviel Platz zu verschwenden, und dennoch die Stärken eines jeweiligen Dateisystems ausnutzen will wo es Sinn macht, dem ist mit 'mount -o bind' geholfen.
- man erstellt lediglich eine Partition mit z.B. reiser4 //Bsp. /dev/sda4
- verschiebt die entsprechenden directories auf diese Partition //Bsp. /var - /usr/src - /usr/portage - ...
- hängt die reiser4-Partition an unauffälliger Stelle ein //Bsp. mount /dev/sda4 /mnt/reiser4storage
- und mountet dann diese directories zusätzlich dort wo sie hingehören:

mount -o bind /mnt/reiser4storage/var /var
mount -o bind /mnt/reiser4storage/usr/src /usr/src
mount -o bind /mnt/reiser4storage/usr/portage /usr/portage

Schon hat man alle Vorteile von reiser4 mit einem Minimum an Partitions- und Platzaufwand. Das lässt sich natürlich mittels der /etc/fstab automatisieren.

Nur eines: Für den Fall einer künftig vielleicht notwendigen Rettungsaktion mittels LiveCD sollte man diese Mountereien am besten gleich auch in ein script verewigen, sonst artet ein sonst noch relativ simples chroot in ziemliche Arbeit aus, je nachdem wie viele directories man derart ausgelagert hat.