[gelöst] SSD, ext3 und discard = Problem?

[TuxPeter]

Hallo Debianfreunde,

leider schon wieder eine SSD-Frage:

Meine neue SSD habe ich einfach mit einem von der HDD per rsync geklonten Jessie befüllt (60 GB in 2 Partitionen, / und /home), Anpassung der Devicenamen in fstab und grub(alt), fertig. Vom Ergebnis bin ich sehr beeindruckt. Allerdings habe ich im Nachhinein mich belesen und festgestellt: noatime und discard sollten wohl zusätzlich in die fstab. Und vor allem sollte der Partitionstyp ext4 sein - ich habe ext3.

Was meint Ihr, sollte ich das ganze nochmal umschaufeln, auf ext4 formatieren und zurückschaufeln? Oder ist es doch eher egal? Habe zwar Hinweise gefunden, dass ext3 auch "discard" kann, aber alle Beispiele bezogen sich auf ext4. (Ist ja kein allzu großer Aufwand, legt die Kiste aber ausführlich lahm)

Übrigens: fstrim -v / bzw fstrim -v /home machen irgendwas, vielleicht reicht es ja, das gelegentlich zu geben? Trim wird auch von der SSD-Firmware untestützt, wie hdparm -I anzeigt -

mfG, TuxPeter

[smutbert]

discard (noatime sowieso) funktioniert mit ext3 bestimmt genauso gut und wenn du mit ext3 zufrieden bist, würde ich nicht grundlos neu formatieren.

trim macht dasselbe wie discard, nur dass die discard Option eben das Dateisystem veranlaßt die frei gewordenen Speicherbereiche im laufenden Betrieb ständig als frei zu markieren, während trim jedes Mal den kompletten freien Speicher als frei markiert. Also ja natürlich genügt es gelegentlich fstrim für die einzelnen Dateisysteme aufzurufen.

[wanne]

Zuerstmal: ext3 ist auch nur ein ext4. => Du kannst in die fstab einfach ext4 schreiben und du hast ein ext4-Dateisystem.
Du kannst (Optional!) noch das ausführen, um die zusätzlichen Performance Features von ext4 zu bekommen das ausführen:

Code: Alles auswählen

tune2fs -O extents,uninit_bg,dir_index /dev/sdxX
e2fsck -fDC0 /dev/sdxX

Habe zwar Hinweise gefunden, dass ext3 auch "discard"

Di Ubuntuusers meinen dass nicht: http://wiki.ubuntuusers.de/SSD/TRIM

fstrim -v / bzw fstrim -v /home machen irgendwas, vielleicht reicht es ja, das gelegentlich zu geben?

Ja. Die kernelentwickler empfehlen zwar discard. Es gibt aber Leute, die behaupten, dass das fstrim sogar besser ist.

[TuxPeter]

Vielen Dank für Eure Antworten!

Neben Ubuntuusers hatte ich auch "Archwiki" und "Linuxbibel" sowie ein Debian-Wiki in englisch aufgerufen, weiß nicht mehr, wo ich diese Tabelle gesehen habe, woraus hervorgeht, dass ext3 auch "discard" kann. egal, vielleicht auch ein Verständnisfehler meinerseits.

Ich wüsste auch nicht, wozu ein ext4 in meiner schlichten DesktopAnwendung Vorteile bringen könnte - wenn man von besagtem discard-Mechanismus absieht. Im man steht es übrigens auch, dass es mit ext4 geht:

Code: Alles auswählen

 discard/nodiscard
              Controls  whether ext4 should issue discard/TRIM commands to the
              underlying block device when blocks are freed.  This  is  useful
              for  SSD  devices  and sparse/thinly-provisioned LUNs, but it is
              off by default until sufficient testing has been done.

Dann werde ich es jetzt also schön bei ext3 lassen und eben ab und zu fstrim geben.
Ich verstehe sowieso nicht wirklich, was das eigentlich bewirken soll. Schließlich werden gelöschte Speicherbereiche doch sowieso frei gegeben? Außerdem ist die root-Part. derzeit sowieso zu ca. 60% frei, /home sogar zu 85%. Da kann es doch nur günstig sein, wenn die freien Bereiche so nach und nach auch einmal verwendet werden - wo doch, wenn ich das richtig verstanden habe, ein neuerer SSD-Kontroller die Zugriffe sowieso breit über den ganzen Adressbereich streut.

Die fstab (Ausschnitt) soll demnach jetzt so aus aussehen:

Code: Alles auswählen

/dev/sdb1       /               ext3    errors=remount-ro,noatime           0    1
/dev/sdb2       /home           ext3    defaults,noatime                    0    2

Auf /dev/sda bleibt weiter das alte HDD mit stable und weiteren Daten-Parts.
Ein witziger Effekt am Rande: Auf der SSD habe ich auch einen Grub-legacy, und der funktioniert auch, wenn er über das Bios aufgerufen wird. Allerdings möchte er dann, genauso wie der Grub auf /dev/sda die Anweisung root (hd0,0), obwohl dem Kernel korrekterweise sdb1 als root mitgegeben werden muss.

MfG
TuxPeter

[smutbert]

Ich verstehe sowieso nicht wirklich, was das eigentlich bewirken soll. Schließlich werden gelöschte Speicherbereiche doch sowieso frei gegeben? Außerdem ist die root-Part. derzeit sowieso zu ca. 60% frei, /home sogar zu 85%. Da kann es doch nur günstig sein, wenn die freien Bereiche so nach und nach auch einmal verwendet werden - wo doch, wenn ich das richtig verstanden habe, ein neuerer SSD-Kontroller die Zugriffe sowieso breit über den ganzen Adressbereich streut.

Für das Dateisystem gelten freie Bereiche als frei, aber nicht automatisch auch für die SSD. Viele Dateisysteme versuchen außerdem frei gewordene Bereiche nicht gleich bei den nächsten Schreibvorgängen wieder zu überschreiben. Auf die Spitze treiben das die COW Dateisysteme (copy on write) wie btrfs und zfs.

Für die SSD gilt aber jeder logische Sektor/Block als belegt, auf den einmal ein Schreibzugriff stattgefunden hat und der nicht mit trim/discard wieder als frei markiert wurde. Ohne trim/discard gibt es also aus Sicht der SSD früher oder später keine freien Bereiche mehr.

Vor jedem Schreibzugriff muss die SSD aber den Speicher, auf den sie zu schreiben gedenkt, löschen, was erstens Zeit in Anspruch nimmt und zweitens kann die SSD den Speicher nicht blockweise löschen sondern es werden immer mehrere Blöcke zu einer löschbaren Einheit (Erasable Block) zusammengefaßt. Dh wenn nichts mehr frei ist, muss der SSD-interne Controller einen solchen Erasable Block komplett einlesen, selbst im eigenen RAM zwischenspeichern den Block löschen und dann wieder komplett beschreiben.
Etwas entschärft wird das durch die Reserveblöcke, die die SSD vorhält — verschlimmert andererseits vielleicht durch das Wear Leveling (die SSD weist den logischen Blöcken ständig neue physische Speicherzellenzu, damit alle Speicherzellen einigermaßen gleichmäßig abgenutzt werden).

Die Tatsache, dass die SSD aufgrund dieser größeren Einheiten der Erasable Blocks, des Wear Leveling und wahrscheinlich auch noch anderer Dinge (nicht zuletzt in der Vergangenheit aufgrund von Fehlern in der SSD Firmware), wesentlich mehr Daten schreiben muss, als es Rohdaten wären, nennt man übrigens Write Amplification.

Jedenfalls leiden sowohl Lebensdauer und Performance, wenn zu wenig, auch der SSD als frei bekannter, Speicher zur Verfügung steht. Aber ich glaube auch, dass das im typischen Alltagsgebrauch bei guten SSDs keine große Rolle spielt, weil die SSD trotzdem noch sehr schnell ist und die Lebensdauer ist normalerweise auch nicht das Problem.

Ein witziger Effekt am Rande: Auf der SSD habe ich auch einen Grub-legacy, und der funktioniert auch, wenn er über das Bios aufgerufen wird. Allerdings möchte er dann, genauso wie der Grub auf /dev/sda die Anweisung root (hd0,0), obwohl dem Kernel korrekterweise sdb1 als root mitgegeben werden muss.

Wenn du mit dem BIOS oder der BIOS-Emulation vom zweiten Datenträger bootest, macht das BIOS (oder der Bootmanager) diesen zweiten Datenträger sozusagen zum ersten. Das ändert sich erst wieder, wenn das Betriebssystem, also Linux seine eigenen (ATA-)Treiber lädt und dann ist der zweite Datenträger eben wieder /dev/sdb. Wobei man sich darauf nicht verlassen sollte, es kann durchaus passieren, dass Linux die Festplatten einmal in einer anderen Reihenfolge erkennt und die Buchstaben (sda, sdb, sdc,…) durcheinanderwürfelt oder man vergißt einen USB-Stick, der sich sda schnappt, bevor die internen Datenträger eine Chance dazu haben oder, oder,…
Deshalb hat sich durchgesetzt die Dateisysteme, unabhängig davon auf welchem Datenträger sie sich befinden, anhand ihrer ID (UUID) oder auch ihres Labels (LABEL) zu idenifiziern. An so gut wie allen Stellen, kann man statt /dev/sdxy auch LABEL=Name oder UUID=xyz schreiben, in der fstab genauso, wie im Parameter root=UUID=xyz des Kernels.
Alle UUIDs und Labels lassen sich mit

Code: Alles auswählen

# blkid

anzeigen.

[wanne]

Ich wüsste auch nicht, wozu ein ext4 in meiner schlichten DesktopAnwendung Vorteile bringen könnte - wenn man von besagtem discard-Mechanismus absieht.

ext4 braucht typischerweise weniger Schreibzugriffe, was gerade bei SSDs zu längeren Haltbarkeiten und weniger CPU-Auslastung führt.
Dazu kommen halt das ext4 fragmentierung besser vermeiden un so in erster Linie auf herkömmlichen HDDs schneller läuft. Außerdem sind die Zugirffseiten auf kleine Dateien deutlich besser. Diese Argumente Gelten aber in erster Linie erst, wenn die Daten wirklich als ext4 geschrieben wurden und extents,uninit_bg und dir_index mittels tune2fs aktiviert wurde. Nicht wenn man einfach ext4 in die fstab schreibt.

Siehe auch da (ext4 arbeitet einfach wesentlcih schneller, bei wesentlich kleinerer CPU-Auslastung):
http://www.bullopensource.org/ext4/2007 ... write.html


Aber ich weß, warum die Handbremse Lößen, wo man doch auch locker mit anfahren kann.

[TuxPeter]

... typischerweise weniger Schreibzugriffe .. und weniger CPU-Auslastung ...Zugriffszeiten auf kleine Dateien deutlich besser. Diese Argumente Gelten aber in erster Linie erst, wenn die Daten wirklich als ext4 geschrieben wurden und extents,uninit_bg und dir_index mittels tune2fs aktiviert wurde. ...

Danke für die weiteren Infos - das sieht dann doch so aus, dass sich eine Neueinrichtung des FS und zurückkopieren lohnen würde! - Mache ich denn mal!

@smubert
danke auch für die ausführlichen Erläuterungen - sehe jetzt klarer, wozu das gut sein kann.

Grüße, TuxPeter

[smutbert]

Brauchst du doch gar nicht zu machen:

Zuerstmal: ext3 ist auch nur ein ext4. => Du kannst in die fstab einfach ext4 schreiben und du hast ein ext4-Dateisystem.
Du kannst (Optional!) noch das ausführen, um die zusätzlichen Performance Features von ext4 zu bekommen das ausführen:

Code: Alles auswählen

tune2fs -O extents,uninit_bg,dir_index /dev/sdxX
e2fsck -fDC0 /dev/sdxX

[…]

[wanne]

Danke für die weiteren Infos - das sieht dann doch so aus, dass sich eine Neueinrichtung des FS und zurückkopieren lohnen würde! - Mache ich denn mal!

Wie gesagt Zurückkopieren ist weitenstgehend Unnötig. Da das in erster Linie schreibvorgänge betrifft: Reicht ein aktivieren der features und abändern der fstab:

Code: Alles auswählen

tune2fs -O extents,uninit_bg,dir_index /dev/sdxX
e2fsck -fDC0 /dev/sdxX

dann hast du die weitestgehend Schreibperformance von ext4. Aber mach's von einer LiveCD aus!

Edit: Smutbert war schneller.

[TuxPeter]

Hi,

Diese Grafiken hier für ext4 sind ja wirklich beeindruckend: http://www.bullopensource.org/ext4/2007 ... write.html - für ext4.

Wenn die nachträgliche Umwandlung mittels tune2fs und e2fsck den gleichen Effekt bringen, werde ich das wohl tun.

Nochmal zur Device-Adressierung mittels Label: Feine Sache, aber in der root-Anweisung im alten Grub wir das wohl eher nicht aufgelöst. Egal, das Aufkommen von zwei Laufwerken in meinem Hauptrechner kann ich gerade noch so handeln, und dass USB-Devices dazwischenfunken, habe ich noch nie erlebt.

Jetzt muss ich erst mal zu einer anderen Baustelle.

Vielen Dank für Eure Tipps!
TuxPeter

Edit: Ihr wart beide schneller. Klar doch, Umwandlung von einem anderen System aus!

[wanne]

Achos: und mache inem Grub install. Sonst kann der bim nächsten Update nciht mehr lesen.

[TuxPeter]

So, habe die Änderungen jetzt durchgeführt.

Hatte zwar einen kleinen Performance-Vergleich geplant, umkopieren vieler kleiner sowie einer großen Datei von einer auf die andere SSD-Partition, der hat aber nicht funktioniert. (ging zu schnell) Ansonsten spürt man bei der Arbeit keinen Unterschied, aber vermutlich ist es unter der Haube jetzt besser.

Es muss übrigens "tune2fs -O extent,..." heißen, also ohne Plural-s, meint das manual.

@wanne: Was meinst Du mit dem erneuerten Grub-Install? Das funktioniert nach wie vor, egal ob ich über die 1. Platte (HDD, ext3) oder die 2. Platte (SSD, ext4) boote.

Grüße und Dank
TuxPeter

[rendegast]

Habe mal gerade ein 4T qemu-img angelegt.
Auch bei dieser Größe legt mkfs.ext4 ein 128MB journal an.
Ich empfehle das zu vergrößern

Code: Alles auswählen

mkfs.ext4 -J size=256 XXXX

resp. bei einem schon vorhandenen:
tune2fs -O ^has_journal XXXX
tune2fs -J size=256 XXXX

Nachprüfen mit sowas
bonnie++ -s0 -n 100:$((6*1024)):512 ...

[wanne]

Was meinst Du mit dem erneuerten Grub-Install? Das funktioniert nach wie vor, egal ob ich über die 1. Platte (HDD, ext3) oder die 2. Platte (SSD, ext4) boote.

Nja. Grub wird wenn du grub-install /sev/sdx ausführst auf das Dateisystem von /boot angepasst. ext3 und ext4 sind so ähnlich dass das gut gehen kann wenn du mit nem ext3-Grub von ext4 bootest. Aber wenn du beim nächsten Kernelupdate nicht das Risiko haben willst, dass es eben nicht mehr geht solltest du den einfach noch einmal grub-install /dev/sda ausführen

[TuxPeter]

Hi Wanne, recht hattest Du.
Neuer Kernel kam, alter Grub bootete ihn nicht mehr. Habe bei der Gelegenheit auf Grub-Pc umgestellt.

Grüße, TuxPeter

Edit: inzwischen weiß ich, dass grub-legacy ext4 sowieso nicht lesen kann. Es gibt wohl inoffizielle Patches, aber nicht bei Debian. Abhilfe wäre hier also nur ein anderer Boot-Loader oder eine Extra-Boot-Partition.