Partitionierung mit SSD

[chris71]

Wünsche allseits ein gutes neues Jahr

Ich "darf" für meine Dad mal wieder einen neuen Rechner stricken und bin bei der Partitionierung unschlüssig. Es ist mehr oder weniger ein Office Rechner ohne besondere Anforderungen, außer einem Mindestmaß an Datensicherheit, da der gute zu faul zum Sichern ist. Rechner: I5-4570, 8GB RAM, H87-Board, Samsung SSD mit 120GB, 2xHDD ... soll ja auch wieder eine längere Zeit laufen .... testing ist wohl nötig, wegen der recht neuen Hardware.

Bisher hatte ich auf den 2 HDDs ein SW-Raid1, alles auf einer großen Partition, ohne weiter nachzudenken, da keine Datenmengen anfallen. Prinzipiell könnte ich so auf die SSD installieren, würde genügen. Da aber diese latente Sichungsfaulheit besteht werde ich die wichtigen Daten auf einem Raid 1 mit den 2 HDDs speichern.

Wie mache ich das jetzt?

/ auf SSD
/swap wohin?
/home/benutzer/raid auf Raid 1

oder soll ich mehr auf das Raid legen?
/home komplett?
/temp
/var (nur die Teile, die oft neu beschrieben werden)

Offensichtlich müssen die SSDs ja nicht mehr geschont werden - oder?

Bremst es, wenn man /temp und /var auf HDDs legt?

... ich bin noch unschlüssig ....

Danke für die Hilfe und Gruß

Chris

PS: gibt es beim formatieren der SSD etwas zu beachten? Oder einfach ext4 in standard-Konfiguration?

[owl102]

/temp

/tmp würde ich bei 8GB RAM einfach in eine Ramdisk legen.

Offensichtlich müssen die SSDs ja nicht mehr geschont werden - oder?

Jein, hier kann man seiner eigenen Paranoia freien Lauf lassen. Ich habe mein Gewissen mit "noatime" beruhigt und /tmp in einer RAM-Disk, das reicht mir.

Bremst es, wenn man /temp und /var auf HDDs legt?

Natürlich bremst es die Zugriffe auf /var, wenn es auf HDD statt SSD liegt. Ich würde /var einfach auf die SSD packen.

PS: gibt es beim formatieren der SSD etwas zu beachten? Oder einfach ext4 in standard-Konfiguration?

Die Partitionen sollten aligned sein. Aktuelle Partitionierungstools legen die Partitionen sowieso auf 1MB-Grenzen, das passt immer.

[smutbert]

Wheezys gnome-disk-utility benimmt sich nicht so gut und wollte bei mir mit Sektor 63 anfangen. Bei testing mag das schon wieder anders aussehen, aber es kann nicht schaden hinterher nachzuprüfen, was das Partitionierungsprogramm tatsächlich gemacht hat.

swap lege ich normalerweise entweder auf die SSD oder lasse es, weil es dank großzügigem Hauptspeicherausbau sowieso nicht genutzt würde, ganz weg.

/tmp auf ein tmpfs zu legen widerspricht dem eigentlichen Zweck von /tmp, zumindest legt der Anfang dieser Diskussion [1] diese Vermutung nahe und ich bin geneigt dem zuzustimmen, denn die einzige Situation, in der ich eine erwähnenswerte Menge an Daten in /tmp hatte, war beim Brennen eines otischen Mediums und gerade da würde es spätestens mit BluRay-Images auch bei gut ausgestatteten Rechnern im Hauptspeicher knapp. Dann müsste das System aufgrund der Daten in /tmp auslagern und da erscheint es mir sinnvoller die Daten von vornherein auf das normale Dateisystem zu schreiben.

Alles in allem, ist es also das einfachste und meiner Meinung nach vollkommen ausreichend / auf die SSD und /home auf das RAID zu legen.
(was aber natürlich das Backup keineswegs ersetzt. Etwas mehr Sicherheit hätte man vielleicht zB mit btrfs auf einem RAID1 und regelmäßig angelegten read-only-Snapshots, aber als Ersatz für ein Backup würde ich es trotzdem nicht betrachten. Also entweder sind die Daten so unwichtig, dass es sich kaum lohnt sie zu speichern , dann stelle ich auch die Sinnhaftigkeit eines RAID in Frage oder du überlegst dir etwas anderes.
backintime-gnome und backintime-kde bieten beispielsweise eine recht schöne grafische Oberfläche und können auch in regelmäßigen Abständen automatisch sichern und auch alte Sicherungen automatisch löschen.)

[1] https://lists.debian.org/debian-devel/2 ... 01092.html

[owl102]

Wheezys gnome-disk-utility benimmt sich nicht so gut und wollte bei mir mit Sektor 63 anfangen.

Die Debian-Installation legt die Partitionen spätestens seit Squeeze auf 1MB-Grenzen (startet also mit Sektor 2048), GParted macht dies auch schon seit einer gefühlten Ewigkeit. Merkwürdig, daß es immer noch Tools gibt, die die Partitionen auf Zylindergrenzen legen wollen, denn schließlich bringt dies schon sehr lange keinen Geschwindigkeitsgewinn bei Festplatten mehr. (Und 4k-Platten gibt es auch nicht erst seit gestern.) Aber gut zu wissen, daß man immer noch aufpassen muß.

denn die einzige Situation, in der ich eine erwähnenswerte Menge an Daten in /tmp hatte, war beim Brennen eines otischen Mediums

Dies sollte eigentlich in /var/tmp und nicht in /tmp landen. Welches Brennprogramm hattest du verwendet?

[smutbert]

Tut mir leid, keine Ahnung mehr welches Brennprogramm das war — ich habe einmal so ziemlich alle durchprobiert und aufgefallen ist es mir auch nur deswegen, weil der Speicherplatz in /tmp nicht ausgereicht hat (war ein tmpfs )
Sollten nicht nur Dateien nach /var/tmp, die auch nach einem Neustart noch vorhanden sein sollen (was beim Brennen nicht unbedingt der Fall ist)?

Aber ist ja eigentlich egal, ich wollte nur darauf hinaus, dass es bei nur wenigen Daten in /tmp egal ist, wo es liegt und bei großen Datenmengen ist der Hauptspeicher nicht unbedingt der beste Platz.

[owl102]

Tut mir leid, keine Ahnung mehr welches Brennprogramm das war — ich habe einmal so ziemlich alle durchprobiert und aufgefallen ist es mir auch nur deswegen, weil der Speicherplatz in /tmp nicht ausgereicht hat (war ein tmpfs )

Dann müsste aber IMHO das Brennprogramm korrigiert werden, denn so wird es auch unter Solaris, Arch, Fedora, und vielen mehr Probleme machen.

Sollten nicht nur Dateien nach /var/tmp, die auch nach einem Neustart noch vorhanden sein sollen (was beim Brennen nicht unbedingt der Fall ist)?

Dies ist nur eines der Kritieren für /var/tmp.

Siehe zum Beispiel auch: http://0pointer.de/blog/projects/tmp.html

[smutbert]

Das ist aber doch der Blog des Gründers und Verfechters von pulseaudio und systemd. Es fällt mir schwer seine Argumente ernst zu nehmen, da schaue ich doch lieber in der FHS Dokumentation nach und dort steht nicht viel mehr zu den Unterschieden von /tmp und /var/tmp [1].

Aber um zum eigentlichen Thema zurückzukommen:
Etwas was abgesehen von noatime als Mountoption noch sinnvoll ist, ist die Mountoption discard, damit freigewordene Speicherbereiche auf der SSD auch für den SSD-Controller als frei markiert werden oder alternativ regelmäßige Aufrufe von zB fstrim /home (siehe auch http://debianforum.de/forum/viewtopic.php?f=27&t=146503)

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html

[owl102]

Das ist aber doch der Blog des Gründers und Verfechters von pulseaudio und systemd.

Ja, und? Es war ja auch nur ein auf die schnelle herausgesuchter Beispiellink; es war schon seit Jahren (und lange bevor es systemd gab) schon eine schlechte Idee (wenn nicht gar schon immer), größere Dateien nach /tmp (und nicht /var/tmp) zu packen.

[wanne]

Also ich kann nirgends finden, dass man große Dateien nicht in tmp speichern soll.
Sonst: Ich würde stark empfehlen, dass man zumindest einen Teil des SWAP in die SSD legt. Dann muss man auch nicht so sparsam mit den tmpfs-größen sein und kann da auch mal ne iso reinlegen.
Ansosnten ist bcache eine tolle sache, die meiner meinung nach viel zu wenig beachtung findet. Gerade /home ist oft zu groß für die SSD aber viele programme lesen da oft von (configurationsdateien falsch abgelegte tempoäre dateien...) Da lohnt sich dann die SSD als cache für die HD

[chris71]

...Gerade /home ist oft zu groß für die SSD aber viele programme lesen da oft von ...

Organisationssache .... kannst ja auch nur Unterverzeichnisse von home auf eine HDD auslagern ....

[wanne]

Organisationssache .... kannst ja auch nur Unterverzeichnisse von home auf eine HDD auslagern ....

Ja, aber keiner wil 100 Partitionen für die 100 versteckten Programmeinstellungsordner (Bei mir sind es sogar mehr) anlegen. Für alle während insbesondere die schnelleren Zugriffszeiten der SSD aber schön. (OK, mit btrfs geht das mittlerweile etwas schöner aber trotzdem umständlich.)

[DeletedUserReAsG]

Ja, aber keiner wil 100 Partitionen für die 100 versteckten Programmeinstellungsordner (Bei mir sind es sogar mehr) anlegen.

Und weil’s keiner will, wurden Symlinks erfunden. Oder so.