[gelöst] fstab,TRIM,SSD

[Par@noid]

Hallo debiangmeinde,

ich habe mir eine Samsung SSD 850 Evo zugelegt, sie (als nicht einzige Festplatte) in meinen pc eingebaut und jetzt nach der Installation von Debian auf dieser SSD habe ich eine Frage zu Trim in der /etc/fstab.

Debian hat mir die fstab folgendermaßen angelegt :

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/sda5 during installation
UUID=16bdc430-5bba-4cd3-98b4-3c479602caa3 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sdb5 during installation
UUID=689a10a1-86e0-4544-b1d9-18c632174cd8 /home           ext4    defaults           0       2
# swap was on /dev/sdb6 during installation
UUID=0a616fa9-3e4e-4a64-884e-81f00ec31001 none            swap    sw                 0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto                              0       0

Code: Alles auswählen

# hdparm -I /dev/sda | grep -i TRIM
	   *	Data Set Management TRIM supported (limit 8 blocks)

sdb5 = SSD Samsung SSD 850 Evo 250 GB
sdb5 = HDD TOSHIBA DT01ACA100 1.00 TB

Nun zu meiner Frage. Reicht es, die anderen Parameter in meiner fstab so lassen und um discard zu erweitern oder ist das kontraproduktiv?
Welches währen die optimalen Einstellungen?

Distributor ID: Debian 64-Bit
Description: Debian GNU/Linux 8.2 (jessie)
Release: 8.2
Codename: jessie


Bin für jede hilfe dankbar.

MfG Par@noid

[smutbert]

das ] vor der ersten UUID für das /-Dateisystem ist dir nur beim Kopieren ins Forum hineingerutscht, oder? (Sonst müsstest du des korrigieren, damit sich Debian beim booten nicht daran stößt)

Ansonsten, ja, für ext4 kannst du einfach discard zu den Mountoptionen hinzufügen oder du führst selbst gelegentlich fstrim aus (zB »fstrim -v /« und »fstrim -v /home«) oder du siehst dir das an was util-linux in der Dokumentation für Beispiele mitbringt (die systemd-Units »/usr/share/doc/util-linux/examples/fstrim.service« und »/usr/share/doc/util-linux/examples/fstrim.timer«).

Bei swap brauchst du afaik nichts zu unternehmen, das macht das discard/trim automatisch.

[hikaru]

Kann mir das hier jemand erklären?:

Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems the sufficient trimming frequency is once a week. Note that not all devices support a queued trim, so each trim command incurs a performance penalty on whatever else might be trying to use the disk at the time.

SSDs "altern" doch dadurch, dass bei jeder Schreiboperation irgendwelche Flashzellen-Ummantelungen oxidieren, die dazu dienen, aus dem eigentlich flüchtigen Speicher einen Nichtflüchtigen zu machen.
Beim Ausführen eines Trim-Befehls wird doch aber gar nicht auf die eigentlichen Speicherzellen geschrieben.
Oder ist hier der Speicher im Controller selbst gemeint, der ja vermutlich ebenfalls aus Flash-Zellen besteht, auf den dann jeder Trim-Befehl eine Schreiboperation ausführen würde? Falls dem so ist, sollte dem doch in Zeiten von MLC-SSDs auf Herstellerseite recht einfach zu begegnen sein, indem man hier eine Hand voll SLCs verwendet, die vermutlich immer noch um Größenordnungen robuster sind.

[Par@noid]

das ] vor der ersten UUID für das /-Dateisystem ist dir nur beim Kopieren ins Forum hineingerutscht, oder? (Sonst müsstest du des korrigieren, damit sich Debian beim booten nicht daran stößt)

Ansonsten, ja, für ext4 kannst du einfach discard zu den Mountoptionen hinzufügen oder du führst selbst gelegentlich fstrim aus (zB »fstrim -v /« und »fstrim -v /home«) oder du siehst dir das an was util-linux in der Dokumentation für Beispiele mitbringt (die systemd-Units »/usr/share/doc/util-linux/examples/fstrim.service« und »/usr/share/doc/util-linux/examples/fstrim.timer«).

Bei swap brauchst du afaik nichts zu unternehmen, das macht das discard/trim automatisch.

ist beim Kopieren ins Forum hineingerutscht
SWAP UND HOME habe ich auf HDD (sdb5) installiert .

Wenn ich das also richtig Verstanden habe musste es fstab so aussehen :

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/sda5 during installation
UUID=16bdc430-5bba-4cd3-98b4-3c479602caa3 /               ext4    discard,errors=remount-ro 0       1
# /home was on /dev/sdb5 during installation
UUID=689a10a1-86e0-4544-b1d9-18c632174cd8 /home           ext4    defaults           0       2
# swap was on /dev/sdb6 during installation
UUID=0a616fa9-3e4e-4a64-884e-81f00ec31001 none            swap    sw                 0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto                              0       0

Danke schonmal für die Hilfe

MfG Par@noid

[smutbert]

@Par@noid
Ja

@Hikaru
Lese ich zum ersten Mal, aber da steht ja auch „poor-quality SSD devices“. Ich würde mir das am ehesten so erklären, dass es SSDs gab (gibt?), die beim trim tatsächlich (unnotwendige) Schreiboperationen ausführen, etwa weil sie sogar bereits gelöschte Blöcke tatsächlich noch einmal löschen, genauso wie es auch SSDs gab, die sich im Leerlauf selbst "kaputtgeschrieben" haben. (Die Art und Weise wie Flashspeicher gelöscht wird hört sich ja eher ungesund an...)
trim und discard an sich sind doch imho insofern harmlos, als der SSD nur mitgeteilt wird, dass bestimmte Speicherbereiche ungenutzt sind, was die Firmware und Controller dann mit dieser Information anfangen ist ja deren Sache.

[hikaru]

trim und discard an sich sind doch imho insofern harmlos, als der SSD nur mitgeteilt wird, dass bestimmte Speicherbereiche ungenutzt sind,

Genau das entspricht auch meinem Verständnis.

was die Firmware und Controller dann mit dieser Information anfangen ist ja deren Sache.

Zumindest müssen sie diese Info irgendwie speichern, wobei vermutlich prinzipiell die selben Probleme entstehen wie beim normalen Datenspeichern.

[Par@noid]

Kleine zwischenfrage,

wie ist es eigentlich mit den Optionen noatime,nodiratime

Danke nochmals und Gruß!

Par@noid

[smutbert]

noatime schließt nodiratime mit ein. Wenn schon genügt also ersteres.
Das sorgt für etwas weniger Schreibzugriffe (die Zugriffszeit wird nicht bei jedem lesenden Zugriff aktualisiert), aber unabhängig davon ob du das nun einträgst oder nicht, wird die SSD aller Vorraussicht nach länger leben, als du sie verwenden willst und wenn sie doch früher stirbt, dann aller Wahrscheinlichkeit nach, nicht, weil zu viel geschrieben worden ist sondern wegen eines defekten Controllers, eines Firmwarefehlers ein paar durchgebrannten Bauteilen aufgrund eines defekten Netzteils oä.
(ich hab noatime trotzdem in der fstab stehen )

@Hikaru
Ok, vielleicht ist dann die Frage dann auch, ob die Informationen noch einmal geschrieben werden, wenn sie bereits genauso gespeichert werden. Die Mountoption discard gibt der SSD ja nur bekannt, wenn neue Speicherbereiche frei geworden sind, fstrim informiert die SSD aber immer über den gesamten ungenutzten Speicher, soweit ich das verstanden habe.
(ganz nachvollziehen kann ich das nicht, weil btrfs, das ich verwende, sich bei der Verwaltung des Speicherplatzes etwas eigenwillig verhält...)

Grundsätzlich stelle ich mir vor, dass das Speichern dieser Information "in einem Aufwasch" mit der Zuordnungstabelle geht, die die Speicherblöcke logischen Adressen zuordnet und nachdem jeder Schreibzugriff eine Änderung dort zur Folge hat, sollte das bißchen Information von den ungenutzten Speicherbereichen doch nicht weiter ins Gewicht fallen, wenn die SSD sich nicht strohdumm anstellt.

[MSfree]

wie ist es eigentlich mit den Optionen noatime,nodiratime

Atime ist die Access-Time einer Datei bzw. eines Verzeichnisses. Wechselt man in ein Verzeichnis oder läßt man eine Datei mit einem Editor anzeigen, ändert sich die Zugriffszeit (atime) und das wird im Verzeichniseintrag vermekrt. Mit noatime,nodiratime wird verhindert, daß diese Zugriffszeiten geschrieben werden, so daß im vermeitlichen Nur-lese-Zugriff keine Schreibzugriffe generiert werden.

Ich verwende diese Optionen schon seit Jahren bei Rechnern, die Flashspeicher als Festplattenersatz verwenden.

[albundy]

Ich auch ohne Probleme, jedoch habe ich irgendwann mal gelesen, dass das Mailprogramm mutt diese Angaben wohl braucht.

[hikaru]

Als Kompromiss aus atime und noatime böte sich relatime an.

[smutbert]

Was afaik auch die Voreinstellung ist, also besteht eigentlich keine Notwendigkeit etwas zu ändern.

[hikaru]

Ich dachte atime wäre die Voreinstellung. Jedenfalls war es mal so. Hat sich das geändert?

[smutbert]

Aus der Manpage von mount

[…]

relatime
Update inode access times relative to modify or change time.
Access time is only updated if the previous access time was ear-
lier than the current modify or change time. (Similar to noat-
ime, but it doesn't break mutt or other applications that need
to know if a file has been read since the last time it was modi-
fied.)
Since Linux 2.6.30, the kernel defaults to the behavior provided
by this option (unless noatime was specified), and the stricta-
time option is required to obtain traditional semantics. In
addition, since Linux 2.6.30, the file's last access time is
always updated if it is more than 1 day old.

[…]

Das muss wohl natürlich noch nicht heissen, dass es auch in Debian der Default ist, aber ich meine mich erinnern zu können, dass relatime auch in Debian und Ubuntu der default geworden ist, Quelle finde ich dafür aber keine, nur für arch

• relatime enables the writing of file access times only when the file is being modified (unlike noatime where the file access time will never be changed and will be older than the modification time). The best compromise might be the use this option since programs like Mutt will continue to work, but you will still have a performance boost as the files will not get access times updated unless they are modified. This option is used when the defaults keyword option, atime option (which means to use the kernel default, which is relatime; see man 8 mount and [1]) or no options at all are specified in fstab for a given mount point.

Quelle
und demnach läuft atime und relatime momentan auf dasselbe hinaus. Ich muss allerdings zugeben, dass mir strictatime komplett neu war.

[hikaru]

Since Linux 2.6.30

Kaum schläft man mal ein paar Äonen, schon ist alles anders.

[Par@noid]

Also kann man ohne ein schlechtes gewissen zu haben noatime,nodiratime und discard einfügen in fstab :

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/sda5 during installation
UUID=16bdc430-5bba-4cd3-98b4-3c479602caa3 /               ext4    noatime,nodiratime discard,errors=remount-ro 0       1
# /home was on /dev/sdb5 during installation
UUID=689a10a1-86e0-4544-b1d9-18c632174cd8 /home           ext4    defaults           0       2
# swap was on /dev/sdb6 during installation
UUID=0a616fa9-3e4e-4a64-884e-81f00ec31001 none            swap    sw                 0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto                              0       0

LG Par@noid

[Radfahrer]

Wie smutbert schon schrieb, schliesst noatime nodiratime mit ein.
Wenn du also noatime einträgst, ist es sinnfrei, nodiratime noch einmal extra einzutragen. Ist doppelt gemoppelt.

[Par@noid]

Ich möchte mich ganz herzlich bei allen bedanken


MfG Par@noid