ssd unf fstrim [gelöst]

[hermelin]

Hallo

Ich habe zwei ssd platten bekommen. Die muß man ja mit fstrim bearbeiten. Nun lese ich
immer, das man das ext4 Filesystem benutzen sollte. Ich habe aber ext3. Muß ich nun
unbedingt auf ext4 wechseln oder kann ich bei ext3 bleiben.?
Muß ich bei den fstab einträgen etwas besonderes beachten (ext3)?

Code: Alles auswählen

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=87159bd2-0d74-472b-9292-ebc4f50fde33 /                 ext3    errors=remount-ro 0       1
# /home was on /dev/sdb1 during installation
UUID=c09f47a5-ab93-4807-8a84-b0fd5eb883a1 /home             ext3    defaults        0       2
# UUID=da16a04d-c159-4c45-aad3-b2fd59367500 /Dokus1         ext3    defaults        0       2
# swap was on /dev/sda5 during installation
UUID=b1dba111-0aa1-429f-96c1-60d57365c66b   none            swap    sw              0       0
# swap was on /dev/sdb2 during installation
UUID=b1b759f6-09f9-48eb-8599-82f2f6e49d40  none            swap    sw              0       0
/dev/sr1        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sr0        /media/cdrom1   udf,iso9660 user,noauto     0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto      0       0

OS: Debian stable amd64

Tschau
Hermann

[dirk11]

Ich habe zwei ssd platten bekommen. Die muß man ja mit fstrim bearbeiten.

Was muss man? Ich denke, das Thema ist schon lange erledigt, weil die SSDs das trim quasi selbst machen!?

Siehe auch hier, hier und hier.

[smutbert]

Was soll denn gegen ext3 sprechen?

trim/discard beherrschen jedenfalls beide ext3 und ext4. Du könntest discard und noatime zu den Mountoptionen hinzufügen, für das / Dateisystem könnte die Zeile in der fstab dann so aussehen:

Code: Alles auswählen

UUID=87159bd2-0d74-472b-9292-ebc4f50fde33   /   ext3   errors=remount-ro,discard,noatime   0   1

noatime wurde gerade erst hier [1] diskutiert. discard macht manuelle fstrim Aufrufe überflüssig indem es frei gewordene Sektoren laufend auch an die SSD meldet. Mir ist es vorläufig aber auch noch lieber fstrim manuell auszuführen.

trim/discard kann die SSD übrigens nicht im Alleingang machen. Da geht es darum, dass man leere/mit nicht mehr benötigten Daten beschriebene Blöcke dem SSD-Controller gegenüber als frei markiert damit immer genügend freie Blöcke verfügbar sind. Sonst kann die Performance bei Schreibzugriffen in den Keller gehen. Die SSD-Controller kommen zwar immer besser mit der ungünstigen Situation weniger freier Blöcke zurecht, aber ich stelle mir vor, dass es auch dem Wear-Leveling zugute kommt, wenn man für möglichst viele freie Blöcke sorgt.

[1] http://debianforum.de/forum/viewtopic.php?f=12&t=146341

[dirk11]

Wie ist das eigentlich mit dem allow_discard bei Verschlüsselung, sprich einer verschlüsselten Partition dmcrypt/luks? Kann man das im Installer schon angeben? Ist es möglich, das auch nachträglich anzugeben? Wo, also in welche conf-Datei, kommt das überhaupt hin?

[rendegast]

trim/discard beherrschen jedenfalls beide ext3 und ext4.

?
Nach manpage ist es eine ext4-Option.
wikipedia:

Als weitere Verbesserungen gegenüber ext3/ext2 sind unter anderem noch in Planung oder bereits implementiert:
....
TRIM-Unterstützung

Wie ist das eigentlich mit dem allow_discard ...
Kann man das im Installer schon angeben?
Ist es möglich, das auch nachträglich anzugeben?

tune2fs

[dirk11]

Wie ist das eigentlich mit dem allow_discard ...
Kann man das im Installer schon angeben?
Ist es möglich, das auch nachträglich anzugeben?

tune2fs

Moment. tune2fs ist doch für Dateisysteme ext2-4? Ich habe vor, XFS zu nutzen, da funktioniert das doch gar nicht? Ich denke, das ist eine dmcrypt-Option? Weil das Dateisystem liegt ja im dmcrypt und nicht ausserhalb.

[smutbert]

Zumindest unterstützt ext3 laut ubuntuwiki discard seit Linux 3.0 und ich kenne die mountoption auch von xfs, btrfs...
Es kann allerdings gut sein, dass die mountoption z.t. überflüssig ist, weil manche Dateisysteme berücksichtigen, dass sie auf einer SSD liegen (SWAP zb aktiviert discard automatisch).

http://wiki.ubuntuusers.de/SSD/TRIM

[hermelin]

Was soll denn gegen ext3 sprechen?

trim/discard beherrschen jedenfalls beide ext3 und ext4. Du könntest discard und noatime zu den Mountoptionen hinzufügen, für das / Dateisystem könnte die Zeile in der fstab dann so aussehen:

Code: Alles auswählen

UUID=87159bd2-0d74-472b-9292-ebc4f50fde33   /   ext3   errors=remount-ro,discard,noatime   0   1

noatime wurde gerade erst hier [1] diskutiert. discard macht manuelle fstrim Aufrufe überflüssig indem es frei gewordene Sektoren laufend auch an die SSD meldet. Mir ist es vorläufig aber auch noch lieber fstrim manuell auszuführen.

trim/discard kann die SSD übrigens nicht im Alleingang machen. Da geht es darum, dass man leere/mit nicht mehr benötigten Daten beschriebene Blöcke dem SSD-Controller gegenüber als frei markiert damit immer genügend freie Blöcke verfügbar sind. Sonst kann die Performance bei Schreibzugriffen in den Keller gehen. Die SSD-Controller kommen zwar immer besser mit der ungünstigen Situation weniger freier Blöcke zurecht, aber ich stelle mir vor, dass es auch dem Wear-Leveling zugute kommt, wenn man für möglichst viele freie Blöcke sorgt.

[1] http://debianforum.de/forum/viewtopic.php?f=12&t=146341

Hallo
Hab dank für Deine Antwort.

Wenn ich das jetzt richtig verstanden habe, kann ich mit dem Aufruf von (fstrim -v / und fstrim -v /home) in der Kosole die Festplatten trimmen.
Den Eintrag in /etc/fstab discard noatime brauche ich dann nicht.? Ich möchte, wenn es geht an der fstab so wenig wie möglich ändern.
Da habe ich sonst Angst, das das System vieleicht nicht mehr bootet. Ich bin kein Linux-Spezialist und weiß mir da nicht zu helfen.

Tschau
Hermann

[smutbert]

Genau, wobei noatime nichts mit discard/trim zu tun hat sondern lediglich generell ein paar Schreibvorgänge verhindert.

[rendegast]

Moment. tune2fs ist doch für Dateisysteme ext2-4?
Ich habe vor, XFS zu nutzen, da funktioniert das doch gar nicht?

Steht oben nichts von xfs.

Ich denke, das ist eine dmcrypt-Option? Weil das Dateisystem liegt ja im dmcrypt und nicht ausserhalb.

Das ist eigentlich ein interessanter Punkt.
trim regelt ja das Verhalten für die Löschung/Freigabe veralteter Sektoren.
Der Dateisystemtreiber wird in dem Fall wohl die Platte direkt triggern?
(Und dann die ganze SSD oder nur für den Partitionsbereich, ala 'fstrim --offset'? )
In 'man mount' steht

Mount options for ext4
...
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.

Das BlockDevice ist dann ja das crypt-Device, das die trim-Anweisung durchreichen müßte.
Falls da die Entwickler nicht Vorkehrung getroffen hätten,
wäre ein denkbarer walkararound eine kleine discard-gemountete ext4-Partition direkt auf der SSD.
Und das würde folgerichtig auch für 'fstrim ... mountpoint' nötig sein.
Aber
"weist das Dateisystem an, ungenutzte Bereiche zu suchen und diese dem Controller der SSD zu melden. "
würde dann ja nur diese dummy-Partition betreffen, in der jedoch gar nichts passiert.

Kollidiert das mit dem Crypt, das ja (für die Platte) gar keinen ungenutzten Speicherplatz besitzt?
???

könnte die Zeile in der fstab dann so aussehen:
UUID=xxxxxxxxxxxxxxxxxxxxxxxxx / ext3 errors=remount-ro,discard,noatime 0 1

Zumindest unterstützt ext3 laut ubuntuwiki discard seit Linux 3.0 ...

Hier lese ich sowas heraus:
http://wiki.ubuntuusers.de/SSD/TRIM

Batched Discard – Der Befehl fstrim /mnt/point/ weist das Dateisystem an, ungenutzte Bereiche zu suchen und diese dem Controller der SSD zu melden. Dieser Befehl muss sporadisch und manuell vom Anwender ausgeführt werden.

Online Discard – Der Kernel informiert das Laufwerk sofort, wenn Speicherbereiche durch Löschen von Dateien frei werden. Diese Funktion ist von Haus aus deaktiviert und muss vom Anwender in /etc/fstab mit der Option discard eingeschaltet werden.

Batched Discard
Dateisysteme ext2, ext3, XFS ab Kernel 2.6.38
Online Discard
Dateisystem ext4 ab Kernel 2.6.33

demnach "nur" 'fstrim' für ext3.

[wanne]

Zu dm-crypt: Standardmäßig reicht der die trim - Befehle aus Sicherheitsgründen nicht durch. Man kann das aber abschalten.

[dirk11]

Ich denke, das ist eine dmcrypt-Option? Weil das Dateisystem liegt ja im dmcrypt und nicht ausserhalb.

Das ist eigentlich ein interessanter Punkt.
trim regelt ja das Verhalten für die Löschung/Freigabe veralteter Sektoren.
Der Dateisystemtreiber wird in dem Fall wohl die Platte direkt triggern?
[...]
Das BlockDevice ist dann ja das crypt-Device, das die trim-Anweisung durchreichen müßte.

Genau um den Punkt geht es mir.
Siehe auch hier.

Zu dm-crypt: Standardmäßig reicht der die trim - Befehle aus Sicherheitsgründen nicht durch. Man kann das aber abschalten.

Ja, das ist ja genau meine Frage: muss ich das bei der Installation angeben, wenn ja wie? Kann ich das auch hinterher machen, wenn ja wie und wo?

[wanne]

Code: Alles auswählen

discard
           Allow using of discards (TRIM) requests for device.

           WARNING: Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the
           leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later.

           Kernel version 3.1 or more recent is required. For older versions is the option ignored.

Also z.B. so in der crypttab abändern:

Code: Alles auswählen

root UUID=87159bd2-0d74-472b-9292-ebc4f50fde3                  none       luks,discard

Du kannst dir aber auch überlegen, ob du aus sicherheitsgründen nicht einfach einen großen leeren ext4-Formatierten berecih hinlegst und das lieber sein lässt.

[dirk11]

in der crypttab abändern:

Also geht es nachträglich. Gut.

Du kannst dir aber auch überlegen, ob du aus sicherheitsgründen nicht einfach einen großen leeren ext4-Formatierten berecih hinlegst und das lieber sein lässt.

Nun ja, damit hadere ich. Eine SSD strotzt sowieso nicht vor freiem Speicher (im Vergleich zu klassischen HDD), da stellt sich mir die Frage, was wird als "leer" betrachtet und vor allem: wieviel "leeren" Platz braucht eine aktuelle SSD? Es gibt ja sowieso reservierten Platz für "Over-provisioning", da ergibt es eigentlich keinen Sinn, dass ich als Anwender selbst noch für freien Speicher sorgen muss.
Wenn ich mit ein paar GB auskomme, sollte doch z.B. bei einem DualBoot-System mit unverschlüsseltem Win7 der freie Platz auf der NTFS-Partition ausreichend sein, oder?

[smutbert]

@rendegast
Du hast vollkommen recht — mir ist entgangen, dass in der "online discard"-Spalte der Tabelle ext3 gar nicht aufgeführt ist.

[owl102]

Es gibt ja sowieso reservierten Platz für "Over-provisioning", da ergibt es eigentlich keinen Sinn, dass ich als Anwender selbst noch für freien Speicher sorgen muss.

Nein, man muß als Anwender nicht zwingend selbst noch für freien Speicher sorgen, aber je knapper der Speicher auf der SSD ist, desto eher kommt die SSD auf die Idee Sektoren von sich aus umzukopieren, um die Anzahl der Schreibzyklen zu verteilen (und desto wichtiger wird trim), und desto langsamer werden u.U. Schreibzugriffe.

Es kommt also darauf an, was genau man von der SSD erwartet, mir persönlich ist z.B. die Geschwindigkeit der Schreibzugriffe ziemlich banane; ich achte eher auf kleinen Stromverbrauch (und damit längere Akkulaufzeit im Laptop) und schnelle Lesezugriffe.

Wenn ich mit ein paar GB auskomme, sollte doch z.B. bei einem DualBoot-System mit unverschlüsseltem Win7 der freie Platz auf der NTFS-Partition ausreichend sein, oder?

Ja, insbesondere da Windows 7 Trim beherrscht.

BTW: Wem die Mount-Option discard nicht behagt, kann ja stattdessen beim Booten (oder in der crontab) ein paar fstrim absetzen.

[dirk11]

Wenn ich mit ein paar GB auskomme, sollte doch z.B. bei einem DualBoot-System mit unverschlüsseltem Win7 der freie Platz auf der NTFS-Partition ausreichend sein, oder?

Ja, insbesondere da Windows 7 Trim beherrscht.

Äh, ich meine natürlich, wenn Debian läuft. Win7 wird zu 99,9% der Zeit nur auf der SSD "rumschimmeln".

BTW: Wem die Mount-Option discard nicht behagt, kann ja stattdessen beim Booten (oder in der crontab) ein paar fstrim absetzen.

Eigentlich will ich mich um so ein Zeug gar nicht kümmern müssen. Muss ich trim machen oder nicht? Ich mein, ist ne SSD, wenn ich "trimmen" will, gehe ich zum Hundefriseur. Hätt das Ding eben kein Speicher werden sollen...

[smutbert]

[…]da stellt sich mir die Frage, was wird als "leer" betrachtet und vor allem: wieviel "leeren" Platz braucht eine aktuelle SSD? Es gibt ja sowieso reservierten Platz für "Over-provisioning", da ergibt es eigentlich keinen Sinn, dass ich als Anwender selbst noch für freien Speicher sorgen muss.[…]

Als frei werden Bereiche betrachtet, die noch nie beschrieben wurden oder Bereiche die zwar schon beschrieben, aber später wieder als frei markiert wurden. Ein paar Unsicherheiten und Ungereimheiten gibt es dabei.

• Ich weiß zB nicht, ob bzw. welche Dateisysteme beim Formatieren, die (noch) nicht verwendeten Bereiche als frei markieren. Deshalb führe ich nach dem Formatieren meistens ein fstrim aus, nur um sicherzugehen. Bei einer nagelneuen SSD kann man sich das natürlich sparen, weil sowieso noch alles frei ist.
• Dasselbe gilt für das Partitionieren. Es wäre meiner Meinung nach wünschenswert, wenn beim Partitionieren alle Bereiche außerhalb der Partitionstabelle(n) als frei markiert würden und vielleicht gibt es Partitionierungsprogramme die das machen.
  Andererseits wäre es ungünstig, wenn man auf diese Art nur eine beschädigte Partitionstabelle wieder reparieren möchte und hinterher zwar wieder die Partitionstabelle, aber keine Daten mehr hat…
• btrfs verwendet nur soviel Platz auf dem Blockgerät wie es tatsächlich braucht. Selbst wenn man fstrim direkt nach der Formatierung ausführt wird nur dieser kleine Teil "getrimmt", der Rest bleibt unberührt und so wie er vorher war, wird also nicht als frei markiert.

Das Overprovisioning kann man zu einem Teil selbst festlegen. Dieser unzugängliche Bereich am Ende des Datenträgers nennt sich auch HostProtectedArea und läßt sich mit hdparm -Npxxx einstellen, wobei xxx die Zahl der noch zugänglichen Sektoren ist. Der läßt sich lediglich 1 Mal pro Kaltstart verändern (beim ersten Mal habe ich 3 Kaltstarts benötigt, weil ich mich zuerst verrechnet und dann irrtümlich Größe der HPA angegeben habe, statt der Größe des zugänglichen Bereiches )
Manche SSDs haben über diese manuell einzustellende HPA hinaus noch weitere Reserven, andere nicht und auch die Größe der HPA variiert im Auslieferungszustand, bei der Samsung 840 Pro gibt es zB im Auslieferungszustand keine HPA.

Denselben Effekt wie mit der HPA erreicht man mit einem unpartitionierten Bereich oder einer leeren Partition zB am Ende der SSD. Man muss nur gegebenenfalls (also wenn dieser Bereich bereits genutzt wurde) dafür sorgen, dass er wieder als frei markiert wird.

Generell herrscht die Meinung vor, dass bei funktionierendem trim/discard das Overprovisioning nicht wichtig ist. Bei besonders schreibintensiven Anwendungen würde ich mich aber nicht darauf verlassen.

[dirk11]

Schön. Jetzt bin ich genauso weit wie vorher. Ich will Win7 auf die SSD packen, ein vollverschlüsseltes Debian (im dmcrypt mit XFS). Muss da jetzt also irgendwelche Vorkehrungen treffen, ja oder nicht?

[owl102]

Äh, ich meine natürlich, wenn Debian läuft. Win7 wird zu 99,9% der Zeit nur auf der SSD "rumschimmeln".

Das ist doch völlig egal, für die SSD sind unbelegte (physikalische) Sektoren unbelegte (physikalische) Sektoren. Und solange sie unbelegt sind, gehören sie keiner Partition und somit auch zu keinem Betriebssystem. Erst wenn ein Schreibzugriff auf einen bisher unbelegten (logischen) Sektor erfolgt (oder die SSD bei einem Schreibzugriff auf einen schon belegten aber auch schon vielbeschriebenen Sektor die Verteilung der Zugriffszahlen optimieren möchte), dann und erst dann schaut die SSD in ihrer Schublade nach um einen passenden (physikalischen) Sektor herauszukramen und verknüpft dann diesen (physikalischen) Sektor mit dem (logischen) Sektor der Partition.

Man muß sich bei einer SSD einfach von der Vorstellung lösen, man würde im Partitionseditor tatsächlich das (physikalische) Abbild der Platte sehen oder bearbeiten. Das ist nur ein logisches Abbild; wo sich die einzelnen Sektoren innerhalb der SSD tatsächlich befinden (d.h. die Verknüpfung zwischen logischem Abbild und physikalischem Abbild), das regelt alleine die SSD, und aufgrund dieser Struktur kann die SSD auch von sich aus die Verknüpfungen zwischen logischen und physikalischen Sektoren jederzeit ändern (und physikalische Sektoren fleißig woanders hin kopieren, je nach Lust und Laune), ohne daß das OS etwas davon mitbekommt, man merkt es nur indirekt durch längere Zugriffszeiten.

[owl102]

Schön. Jetzt bin ich genauso weit wie vorher. Ich will Win7 auf die SSD packen, ein vollverschlüsseltes Debian (im dmcrypt mit XFS). Muss da jetzt also irgendwelche Vorkehrungen treffen, ja oder nicht?

Ich denke die Vor- und Nachteile der Mount-Option "discard" wurden ausreichend besprochen. Als Alternative gibt es fstrim. Weiterhin schließe zumindest ich mich der Meinung von smutbert an: "Generell herrscht die Meinung vor, dass bei funktionierendem trim/discard das Overprovisioning nicht wichtig ist. Bei besonders schreibintensiven Anwendungen würde ich mich aber nicht darauf verlassen." Wenn auf der Win7-Partition immer genügend Platz sein wird, hast du IMHO das Overprovisioning hinreichend bedacht, aber auch das ist nur meine Meinung.

Entscheiden mußt du nun selber, je nach Einsatzzweck deiner SSD.

[dirk11]

Wenn auf der Win7-Partition immer genügend Platz sein wird, hast du IMHO das Overprovisioning hinreichend bedacht, aber auch das ist nur meine Meinung.

Ja, sowas in der Art habe ich mir nach deiner Erklärung auch gedacht. Kann jemand sagen, was eine Win7 Prof. oder Ultimate (32Bit, es gibt keine 64Bit-Treiber für das Notebook) so an Platzbedarf hat? XP kriegte man auf 2GB unter, das wird für Win7 wohl nicht ganz reichen...

[wanne]

• Ich weiß zB nicht, ob bzw. welche Dateisysteme beim Formatieren, die (noch) nicht verwendeten Bereiche als frei markieren. Deshalb führe ich nach dem Formatieren meistens ein fstrim aus, nur um sicherzugehen. Bei einer nagelneuen SSD kann man sich das natürlich sparen, weil sowieso noch alles frei ist.
• Dasselbe gilt für das Partitionieren. Es wäre meiner Meinung nach wünschenswert, wenn beim Partitionieren alle Bereiche außerhalb der Partitionstabelle(n) als frei markiert würden und vielleicht gibt es Partitionierungsprogramme die das machen.
  Andererseits wäre es ungünstig, wenn man auf diese Art nur eine beschädigte Partitionstabelle wieder reparieren möchte und hinterher zwar wieder die Partitionstabelle, aber keine Daten mehr hat…

Ich kann nur sagen, dass überall empfohlen wird, eine ungenutzte Partition erstmal ext4 zu formatieren. Also nehme ich an, dass die meisten Partitionseditoren zu dumm sind das zu machen, wehrend mkfs.ext4 wohl den trim befehel abschickt.

[smutbert]

Habe jetzt in der Manpage sowohl von mkfs.xfs wie auch mkfs.btrfs den Schalter -K gefunden, der verhindert, dass vor der Formatierung das gesamte Blockdevice getrimmt wird.

Offensichtlich machen das also auch xfs und btrfs (wohingegen ich bei ext4 gar nichts dazu in der Manpage gefunden habe)

[Ulidor]

Wie lange dauert denn so ein fstrim in der Regel? Oder hängt das davon ab, in welchen Abständen man den Befehl ausführt (wenn man nicht discard in der fstab stehen hat)?

Ich habe seit fast zwei Jahren / (ohne /home) von Wheezy auf einer 16GiB großen SSD-Partition, und fstrim zum ersten Mal ausgeführt. Der Befehl brauchte 4 Minuten und 20 Sekunden! Dauert das immer so lange? Ich könnte zum Vergleich den Befehl gleich noch mal absetzen, aber ich habe Angst, dass das die gute SSD zu sehr stessen könnte.