Ubuntu auf 1,8" Toshiba SSD (THNS128GG4BAAA-NonFDE) kleines HowTo

[JetroNick]

Dies soll eine kleine Anleitung werden wie Ubuntu 10.04 64-Bit auf einem T410s mit Toshiba SSD (THNS128GG4BAAA-NonFDE) zu konfigurieren ist.
Ich bitte euch einfach einmal alles durch zuschauen ob alles passt. Falls ich Fehler bzw. unnütze Einstellungen getätigt habe, werde ich diese natürlich in der Anleitung korrigieren.

SSD-Partitionierung:
Partitionierung der SSD habe ich unter Win 7 (Computerverwaltung) gemacht. Wie man die SSD unter Linux partitioniert kann man in einigen Beiträgen hier im Forum nachlesen.

Das Alignment kann man mit dem Befehl "sudo fdisk -lu" prüfen:

(sda1 = / und sda2 = /home)

Ausgabe:

Platte /dev/sda: 128.0 GByte, 128035676160 Byte
255 Köpfe, 63 Sektoren/Spur, 15566 Zylinder, zusammen 250069680 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xba7b70a3

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *        2048    45058047    22528000   83  Linux
/dev/sda2        45058048   250064895   102503424   83  Linux

SWAP-Partition habe ich keine angelegt, falls ich noch eine brauchen werde z.B. für Hibernate (RAM2Disk) werde ich die SWAP via Datei realisieren.
Dann braucht man nichts mehr umpartitionieren, Beschreibung siehe: http://wiki.ubuntuusers.de/swap

Ubuntu installieren:
Hier ist alles beschrieben http://thinkpad-wiki.org/Ubuntu_Schnelleinstieg

Anpassungen fstab:
Option 'noatime' beiden Partitionen zuweisen. Dies reduziert die Schreibvorgänge.
(Option 'discard' wird nicht benötigt, da die Toshiba SSD kein TRIM unterstützt)

Desweiteren wird das Verzeichnisse /tmp in ein tmpfs ausgelagert.

fstab editieren mit Befehl:
gksudo gedit /etc/fstab

(sollte dann so aussehen)

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=80d0f970-346f-4d39-acf9-a2957a1b3498 /               ext4    noatime,errors=remount-ro 0       1
# /home was on /dev/sda2 during installation
UUID=5b2a5883-4718-4cda-89ff-338ebefd0b59 /home           ext4    noatime,defaults        0       2

# mount temp as tmpfs
tmpfs /tmp tmpfs defaults,noatime,nodiratime,mode=1777   0  0

IO-Scheduler Optimierung (cfq) deaktivieren:
Folgende Scheduler Option "deadline" wird mittels echo in der rc.local realisiert:
1. gksudo gedit /etc/rc.local
2. folgendes vor exit 0 eintragen:

echo deadline > /sys/block/sda/queue/scheduler

Die Variante über die rc.local ist der Commandline-Medthode vorzuziehen! Siehe Beitrag von linrunner.
Der Vollständigkeit halber hier die Scheduler-Konfiguration über die Commandline:
gksudo gedit /etc/default/grub
1. GRUB_CMDLINE_LINUX="elevator=noop" editieren -> speichern
2. In der Konsole ein 'sudo update-grub' ausführen

Nach einem Neustart kann mittels folgenden Befehl die Übernahme der noop Option geprüft werden:

cat /sys/block/sda/queue/scheduler
Ausgabe:
noop anticipatory [deadline] cfq    <-- deadline ist selektiert

ACHTUNG: Das deaktivieren des Journaling birgt einige Risiken bei Systemabsturz. Daher habe ich das Journaling wieder aktiviert!
EXT4-Journaling deaktivieren:

1. Booten mit Ubuntu-Live CD/Stick
2. In der Konsole folgende Befehle ausführen
sudo tune2fs -O ^has_journal /dev/sda1
sudo tune2fs -O ^has_journal /dev/sda2
3. Ein Filesystem check beider Partitionen durchführen:
sudo e2fsck -f /dev/sda1
sudo e2fsck -f /dev/sda2
4. Reboot (Ubuntu von SSD starten) Kein Live-System
5. Mittels Befehl 'dmesg | grep EXT4' überprüfen ob das Journal jetzt deaktiviert ist. Das sollte dann folgende Ausgabe bringen:

Ausgabe:
EXT4-fs (sda1): mounted filesystem without journal
EXT4-fs (sda2): mounted filesystem without journal

Falls das Journaling wieder aktiviert werden soll, einfach Schritte 1-3 wiederholen aber bei Schritt 2 ohne ^.
Quelle: http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/


Habt ihr noch irgendwelche Ergänzungen oder Anregungen?

Edit: Alle neuen Erkenntnisse von den Beiträgen der anderen Forenmitgliedern eingearbeitet!

 

[yatpu]

alignment passt.

noop ist ein reichlich sinnfreier scheduler meiner meinung nach. nimm lieber deadline. der bevorzugt nämlich lese- vor schreiboperationen. schreibzugriffe können nämlich ohne weiteres gepuffert werden, lesezugriffe nicht. unter hoher i/o-last werden bei noop anwendungen, die daten von der ssd brauchen unnötig ausgebremst, was für den nutzer durchaus spürbar sein kann.

das abschalten des journaling bei ext4 spart minimal schreibzugriffe und man erkauft dies mit dem risiko eines zerstörten fs beim absturz des systems. zumindest dauert ein fsck nach einem absturz unnötig lange, da das gesamte fs auf konsistenz geprüft werden muss. die zeiten von fs ohne journaling sind zum glück vorbei. ich würde daher jounaling definitiv anlassen.

genauso würde ich mir den aufwand mit den tmpfs sparen. bei alten ssd mit mlc-chips war sowas z.t. nötig, da die ssd das system sekundenlang zum stillstand brachte. einer modernen ssd "bürde" ich das ganze gerne auf. sämtliche logdateien beim reboot ins nirvana zu jagen finde ich unpraktisch. friert einem die kiste ein und man kann sie nicht mehr kontrolliert runterfahren und zuvor die logs sichern, weiß man am ende nicht, was gerade passiert ist, da sämtliche logs futsch sind.

lange rede kurzer sinn:
achte auf passendes alignment der dateisysteme, mounte diese mit discard (also in /etc/fstab setzen), wenn die ssd es unterstützt und gut is. scheduler auf deadline setzen ist nicht unbedingt nötig, aber durchaus sinnvoll. mehr würde ich nicht machen. beim alignment muss man bedenken, dass bei einsatz von dm_crypt und / oder lvm2 auch dort aufs alignment geachtet werden muss.

 

[JetroNick]

Hallo yatpu, danke für deine ausführliche Antwort.

Dann fasse ich mal zusammen:
1. Scheduler auf "deadline" umstellen
2. EXT4-journaling wieder aktivieren
3. tmpfs von /var/log und /var/tmp unnötig. /tmp werde ich mal als tmpfs lassen.
4. in fstab "discard" doch setzen, obwohl die SSD kein TRIM kann. Aber "noatime" ist schon sinnvoll? Die Reihenfolge der Optionen ist egal oder?

Die fstab würde dann so aussehen:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=80d0f970-346f-4d39-acf9-a2957a1b3498 /               ext4    discard,noatime,errors=remount-ro 0       1
# /home was on /dev/sda2 during installation
UUID=5b2a5883-4718-4cda-89ff-338ebefd0b59 /home           ext4    discard,noatime,defaults        0       2

# mount temp as tmpfs
tmpfs /tmp tmpfs defaults,noatime,nodiratime,mode=1777   0  0

Als Anfänger ist das doch alles recht viel und man weiß nie so richtig was sinnvoll ist und was nicht. Danke für die Hilfe.

Fällt sonst jemanden noch was dazu ein?

 

[yatpu]

discard würde ich nicht setzen bei ssd ohne trim.
unter ubuntu 10.04 ist discard ohnehin nutzlos, da dafür mindestens kernel 2.6.33 benötigt wird, lucid aber noch mit dem 2.6.32 daherkommt. bei maverick kann mans aber nutzen.

edit: noatime nutze ich seit langem schon auch bei festplatten.

 

[JetroNick]

Danke für die Info!!

 

[linrunner]

Ich kann mich yatpus Änderungsvorschlägen uneingeschränkt anschließen .

Ich würde den Elevator nicht per Bootoption sondern in rc.local setzen, damit kannst Du z.B. für eine Ultrabay-HDD einen anderen Elevator einstellen (kommt auch im nächsten TLP-Release).

 

[Ezekeel]

Man legt das /tmp auf eine Ramdisk nicht wegen der Geschwindigkeit, sondern um unnötige Schreibzugriffe zu vermeiden und so die Lebensdauer der SSD zu verlängern. Man kann natürlich diskutieren, ob das wirklich einen signifikanten Unterschied macht. Andererseits, man wundert sich was alleine Firefox an Schreibzugriffen für den Cache verursacht. Ich bin außerdem auch dazu übergegangen beim Programmieren /tmp zu benutzen um die obj-files zu speichern, da diese sich in der Entwicklungsphase eh alle Nase lang ändern und neu geschrieben werden müssen und da kann schon ordentlich was an Datenvolumen zusammenkommen. Eigentlich sehr sinnvoll für alle Anwendungen, bei denen größere Mengen intermediärer Dateien geschreiben werden. Und die logs kann man doch sicherlich auch irgendwie umlegen oder nicht?