[[Vorlage(Getestet, , precise, quantal, raring)]] {{{#!vorlage Wissen [:Terminal: Ein Terminal öffnen] [:sudo: Root-Rechte] [:Editor: Einen Editor öffnen] [:fstab: Bearbeiten von /etc/fstab] [:Packprogramme:Dateien entpacken] }}} [[Inhaltsverzeichnis(3)]] {{{#!vorlage hinweis Dieser Artikel ist Teil der Artikelserie '''[:SSD:]''', welche das Thema [wikipedia:Solid_State_Drive:Solid State Drives] behandelt.\\ Dieser Artikel geht in allen Beschreibungen davon aus, dass die SSD als '''/dev/sda''' im System eingebunden ist. Die Befehle müssen bei davon abweichenden Systemen daher gegebenenfalls angepasst werden. }}} [[Bild(Wiki/Icons/SSD.png, 80, align=left)]] [wikipedia:TRIM:] ist ein sehr wichtiger Befehl zur Markierung ungenutzter oder ungültiger Datenblöcke auf Speichermedien zum Zweck der späteren Wiederbeschreibung. Ausführliche Informationen zur Arbeitsweise von TRIM stehen im Artikel [:SSD/Begriffsdefinitionen#TRIM:]. Über die Ende 2008 mit dem [:Kernel:] 2.6.28 eingeführte Discard-Funktion (englisch: discard – (etwas) verwerfen) können [:Dateisystem:Dateisysteme] den Kernel anweisen, dem Datenträger leere Bereiche zu melden. Seit Kernel 2.6.33 kann Linux direkt über ein ATA-Kommando diese Information (via [wikipedia:Serial_ATA:SATA]) weitergeben – nahezu alle aktuellen SSD verstehen diesen TRIM-Befehl. Um nun die TRIM-Funktion nutzen zu können, müssen einige Voraussetzungen erfüllt sein: So müssen die SSD als auch der Kernel TRIM unterstützen. Dies zeigen die beiden nachfolgenden Tests [#Testen-des-TRIM-der-SSD Testen des TRIM der SSD] und [#Testen-des-TRIM-des-Kernels Testen des TRIM des Kernels]. {{{#!vorlage hinweis Es gibt verschiedene Meinungen zur Nutzung von TRIM (siehe Abschnitt [#Links Links]): Manche sprechen sich dafür aus, den TRIM-Befehl über die Mountoptionen in '''[:fstab:/etc/fstab]''' (genannt „Online Discard“) zu setzen, andere führen TRIM manuell aus (genannt „Batched Discard“), andere wiederum sind der Meinung, dass all dies, wenn der Kernel und die SSD „trimmen“ können, kontraproduktiv sei.\\ Um für sich selbst und die eingesetzte Hardware die optimalen Einstellungen zu finden, sollte man mit den einzelnen Einstellungen die [:Festplatten-Geschwindigkeitstest:Performancetests] durchführen und sich dann für die jeweilige beste/schnellste Lösung entscheiden. }}} = Welches Dateisystem (Journaling) = Laut Computermagazin ''c't kompakt 01/2012 Linux'' ist die Wahl des besten [:Dateisystem:Dateisystems] zurzeit '''[:ext#ext4:ext4]''', da dessen Arbeitsweise der SSD entgegenkommt. In Zukunft kann das sich noch in der Entwicklung befindliche Dateisystem [:Btrfs:] das Rennen um das beste Dateisystem für SSD machen, bietet es doch speziell auf die Betriebsart von SSD zugeschnittete Arbeitsweisen und die Vermeidung von [wikipedia:Overhead_(EDV):Overhead]. Die vermeintlichen Tipps, ein Abschalten des [wikipedia:Journaling-Dateisystem:Journalings] steigere die Performance der SSD und verringere die Schreibzugriffe auf selbige, halten sich hartnäckig im Netz. Die nötigen Schreibvorgänge verringern sich durch das Abschalten tatsächlich, allerdings nimmt man ein weitaus höheres Risiko eines Datenverlustes in Kauf, so dass dieses Risiko den Performance-Vorteil nicht wert ist. Der sogenannte Overhead, der durch das Journaling entsteht, liegt nur zwischen vier und zwölf Prozent. == Exkurs - Journaling auf SSD == Wie [wikipedia:Theodore_Ts'o:Theodore 'Ted' Ts'o], Hauptentwickler des Dateisystems ext, [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size beschreibt] {en} , kann man bei modernen SSD das sogenannte [wikipedia:Journaling-Dateisystem:Journal] ebenfalls auf die SSD schreiben, ohne dass diese dadurch Schaden nehmen. Es gehe dabei eher um ältere Modelle der SSD, welche noch nicht vom [:SSD/Begriffsdefinitionen#Wear-Levelling:Wear Levelling] geschützt waren. Ts'o schreibt, dass Intel für seine SSD angibt, dass diese ''mindestens'' fünf Jahre laufen. Intel legte dazu den Parameter bei 10 Gigabyte an zu schreibenden Daten pro Tag fest (siehe auch [:SSD/Grundlagen#Haltbarkeit-einer-SSD:Haltbarkeit der SSD]). == Abschalten des Journalings == {{{#!vorlage warnung Das Abschalten des Journaling birgt einige schwerwiegende Risiken und sollte wirklich nur von Anwendern vollzogen werden, die wissen was sie tun! }}} Möchte man wirklich das [wikipedia:Journaling-Dateisystem:Journaling] abschalten, so kann man eine ext4-Partition wie folgt im Terminal [3] partitionieren: {{{#!vorlage befehl mke2fs -t ext4 -O ^has_journal /dev/sda }}} Des Weiteren sollte man, hat man das Journaling abgeschaltet, die Mountoption `data=writeback` in '''/etc/fstab''' eintragen. Im Abschnitt [#Links Links] gibt es eine ausführlichere Beschreibung der Option `data=writeback`. = Testen des TRIM der SSD = Um zu überprüfen, ob eine SSD die TRIM-Funktion unterstützt, nutzt man den folgenden Befehl in einem Terminal [1] mit Root-Rechten [2] : {{{#!vorlage befehl sudo hdparm -I /dev/sda | grep -i TRIM }}} Im Positivfall enthält die Ausgabe eine der folgenden Zeilen: {{{ * Data Set Management TRIM supported * Data Set Management TRIM supported (limit N blocks) * Data Set Management TRIM supported (limit unknown)}}} Der Stern (`*`) zeigt an, dass die Option verfügbar ist. Zu beachten ist außerdem, dass es mehrere Typen von SSDs gibt, die sich darin unterscheiden, welche Daten für per TRIM freigebene Datenblöcke zurückgeliefert werden. Zu erkennen ist der Typ an einer zusätzlichen Ausgabezeile: * Typ 1 – liefert beliebige Daten zurück, nicht jedoch die Ausgangsdaten vor TRIM: {{{ * Deterministic read data after TRIM}}} * Typ 2 – liefert Nullen zurück: {{{ * Deterministic read ZEROs after TRIM}}} * Typ 3 – keine zusätzliche Ausgabezeile, das Verhalten für freigegebene Datenblöcke ist undefiniert. = Testen des TRIM des Kernels = Nur für SSDs des oben beschriebenen Typ 2 kann man in einem Terminal [1] mit Root-Rechten [2] sehr einfach testen, ob der automatische TRIM (ab [:Kernel:] 2.6.33) funktioniert. Das folgende Verfahren zeigt, wie man vorgeht: {{{#!vorlage befehl cd / # man kann auch nach home wechseln, wenn es auf der SSD liegt sudo dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct # man braucht kein sudo, wenn home auch auf der SSD liegt }}} Die Ausgabe zeigt in etwas das Folgende: {{{ 100+0 Datensätze ein 100+0 Datensätze aus 52428800 Bytes (52 MB) kopiert, 8,23889 s, 6,4 MB/s }}} Der nächste Befehl generiert Informationen zum eben erzeugten `tempfile`: {{{#!vorlage befehl sudo hdparm --fibmap tempfile }}} Das Ganze sieht wie folgt aus: {{{ tempfile: filesystem blocksize 4096, begins at LBA 54528000; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 0 57438208 57439231 1024 524288 57469952 57477119 7168 4194304 57632768 57673727 40960 25165824 57722880 57755647 32768 41943040 57968640 57989119 20480 }}} Davon kopiert/merkt man sich die erste Nummer, die unter `begin_LBA` steht, da diese im nächsten Befehl gebraucht wird. In diesem Fall ist das die Nummer `57438208`. Die nachfolgenden Befehle setzen voraus, dass die SSD unter '''/dev/sda''' zu finden ist. {{{#!vorlage befehl sudo hdparm --read-sector 57438208 /dev/sda # die Zahl 57438208 muss mit der eigenen ersetzt werden }}} Man erhält daraufhin eine lange Liste vierstelliger Buchstaben und Zahlen. Wichtig ist die folgende Ausgabe: {{{ /dev/sda: reading sector 57438208: succeeded }}} Mit den nächsten beiden Befehlen löscht man das oben erzeugte `tempfile` und synct dann die SSD: {{{#!vorlage befehl sudo rm tempfile sync }}} Auch nachdem man das `tempfile` gelöscht hat, sind die Sektoren der SSD noch nicht geleert. Man wartet nun einige Sekunden/Minuten und gibt dann zur Kontrolle erneut den obigen Befehl ein: {{{#!vorlage befehl sudo hdparm --read-sector 57438208 /dev/sda # die Zahl 57438208 muss mit der eigenen ersetzt werden }}} Bei erfolgreichem automatischem TRIM erhält man als Ausgabe erneut {{{ /dev/sda: reading sector 57438208: succeeded }}} dieses Mal jedoch gefolgt von einer langen Liste vierstelliger Nullen (statt der vorher kryptischen Zahlen/Buchstaben). Dies bedeutet, dass das automatische TRIM funktioniert. = Testen des Kernel-TRIM allgemein = Da die obige Methode nicht bei der Verwendung von LUKS oder LVM funktioniert (bzw nur mit zusätzlichem Aufwand) hier eine allgemeinere Version. Zuerst wechselt man in einen Ordner, der auf der SSD liegt, in diesem Beispiel '''"/"''' (das Wurzeldateisystem). Dann erstellt man dort die Testdatei. {{{#!vorlage befehl cd / yes | sudo dd iflag=fullblock bs=1M count=1 of=trim.test }}} Nun muss man noch herausfinden wo die Datei genau liegt, dazu braucht man die Position im Dateisystem und den Gerätenamen, auf dem das Dateisystem liegt. {{{#!vorlage befehl filefrag -s -v trim.test }}} Dies führt zu so einer ähnlichen Ausgabe: {{{ Filesystem type is: ef53 File size of trim.test is 1048576 (256 blocks, blocksize [mark]4096[/mark]) ext logical physical expected length flags 0 0 [mark]34048[/mark] [mark]256[/mark] eof trim.test: 1 extent found }}} Wichtige Werte sind hier gelb Markiert. Die Anzahl der Blöcke 256, die Blockgröße 4096 in Bytes und der Offset (Versatz zum Anfang des Gerätes) 34048 in Blöcken. Mit diesen Werten muss man später die Datei vom Datenträger lesen, da sie nach dem Löschen nicht mehr über ihren Dateinamen ansprechbar ist. Jetzt noch schnell den Gerätenamen bestimmen: {{{#!vorlage befehl df trim.test }}} Hier sollte folgende Ausgabe kommen (das Gerät wurde gelb markiert): {{{ Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf [mark]/dev/mapper/Tarsius-root[/mark] 32896880 11722824 20838512 37% / }}} Mit diesen (gelb markierten) Werten liest man jetzt die Datei direkt vom Gerät. {{{#!vorlage befehl sudo dd count=[mark]256[/mark] bs=[mark]4096[/mark] skip=[mark]34048[/mark] if=[mark]/dev/mapper/Tarsius-root[/mark] | hexdump -C }}} Die Ausgabe sollte so aussehen: {{{ 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| * 256+0 Datensätze ein 256+0 Datensätze aus 1048576 Bytes (1,0 MB) kopiert, 0,0255604 s, 41,0 MB/s 00100000 }}} Nun kann man die Datei löschen. {{{#!vorlage befehl sudo rm trim.test sync }}} Sollte man in den Mountoptionen (fstab) kein discard verwenden muss man noch manuell trimmen. {{{#!vorlage befehl sudo fstrim -v ./ }}} Das Dateisystem sollte jetzt getrimmt worden sein und nun wird mit dem Befehl von weiter oben die (gelöschte) Datei erneut gelesen. {{{#!vorlage befehl sudo dd count=[mark]256[/mark]bs=[mark]4096[/mark] skip=[mark]34048[/mark] if=[mark]/dev/mapper/Tarsius-root[/mark] | hexdump -C }}} Ist die Ausgabe die gleiche wie oben (eine Zeile mit y.y.y.y.y.y.y.y.) dann wurde nicht getrimmt, hat sich die Ausgabe geändert, dann war der Trim erfolgreich. Hier noch 2 Beispiele für die Ausgabe mit Verschlüsselung {{{ 00000000 1f c9 55 7d 07 15 00 d1 4a 1c 41 1a 43 84 15 c0 |..U}....J.A.C...| 00000010 24 35 37 fe 05 f7 43 93 1e f4 3c cc d8 83 44 ad |$57...C...<...D.| 00000020 46 80 c2 26 13 06 dc 20 7e 22 e4 94 21 7c 8b 2c |F..&... ~"..!|.,| 00000030 1f 48 0e 4e 30 f3 63 e1 15 b8 aa 1e d3 ec ef 48 |.H.N0.c........H| ... }}} und ohne Verschlüsselung {{{ 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * }}} = TRIM (ext4) = Eine SSD lässt sich ausgezeichnet unter dem aktuellen Ubuntu-[:Dateisystem:] namens '''[:ext#ext4:ext4]''' betreiben. {{{#!vorlage hinweis '''[:ext#ext4:ext4]''' ist seit Ubuntu 9.10 [:Karmic Koala:] das Standard-[:Dateisystem:] Ubuntus. Demnach geht dieser Artikel auch nur auf '''ext4''' als Dateisystem ein. Bei Fragen zu Unterschieden zwischen '''[:ext#ext2:ext2]''', '''[:ext#ext3:ext3]''' und '''[:ext#ext4:ext4]''' sei auf das [https://ext4.wiki.kernel.org ext-Wiki] {en} verwiesen (siehe [#Links Links]). }}} Linux unterstützt zwei Arten des Discard (nähere Details in der nachfolgenden Tabelle): * '''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. {{{#!vorlage Tabelle <-4 rowclass="titel">Fähigkeit des Dateisystems einen „Batched Discard“ oder „Online Discard“ durchzuführen +++ <-2 rowclass="kopf" :>Batched Discard <-2:>Online Discard +++ Dateisystem '''[:ext#ext4:ext4]''' ab Kernel 2.6.37 Dateisystem '''[:ext#ext4:ext4]''' ab Kernel 2.6.33 +++ Dateisysteme '''[:ext#ext2:ext2]''', '''[:ext#ext3:ext3]''', '''[wikipedia:XFS_(Dateisystem):XFS]''' ab Kernel 2.6.38 Dateisystem '''[wikipedia:XFS_(Dateisystem):XFS]''' ab Kernel 3.0 +++ Dateisystem '''[:btrfs:]''' ab Kernel 2.6.39 Dateisystem '''[:btrfs:]''' ab Kernel 2.6.32 +++ Dateisysteme '''[wikipedia:NTFS-3G:]''', '''[wikipedia:File_Allocation_Table:FAT]''' <:>– Dateisysteme '''[wikipedia:NTFS-3G:]''', '''[wikipedia:File_Allocation_Table:FAT]''' <:>– }}} == TRIM per Batched Discard == Trimmen per „Batched Discard“ ist sehr einfach. Dies kann man manuell mit folgendem Befehl in einem Terminal [1] mit Root-Rechten [2] oder aber regelmäßig zum Beispiel per [:Cron:Cronjob] durchführen. {{{#!vorlage befehl sudo fstrim -v / ## oder sudo fstrim -v /home }}} Als Ausgabe erhält man mit der Option `-v` eine Ausgabe, wie viele Bytes getrimmt wurden: {{{ /home: 1825476608 bytes were trimmed }}} In diesem Beispiel wurden ungefähr 1,825 GB getrimmt. Wie oft man dieses Verfahren anwenden muss und wie lange es dann jeweils dauert, hängt sehr stark vom eigenen Gebrauch der SSD bzw deren Benutzung ab, so dass man dafür keinerlei Empfehlung abgeben kann. Will man ein Batched Discard regelmäßig automatisch ausführen lassen, so erzeugt man mit einem [:Editor#Root-Rechte-Bearbeiten-von-Systemdateien:Editor mit Root-Rechten] die Datei '''/etc/cron.weekly/batched_discard''' (wöchentlich) bzw. '''/etc/cron.daily/batched_discard''' (täglich) mit folgendem Inhalt: {{{#!code bash #!/bin/sh LOG=/var/log/batched_discard.log echo "*** $(date -R) ***" >> $LOG fstrim -v / >> $LOG fstrim -v /home >> $LOG }}} Da der Cronjob mit Root-Rechten ausgeführt wird, ist hier ''kein'' sudo erforderlich. Danach muss die Datei noch [:Rechte#Datei-ausfuehrbar-machen:ausführbar] gemacht werden: {{{#!vorlage Befehl sudo chmod 755 /etc/cron.weekly/batched_discard }}} Dieses Beispiel setzt voraus, dass sich auf der SSD eine Root- und eine Home-[:Partitionierung:Partition] befinden - ist dies nicht der Fall, muss der Code entsprechend angepasst werden. Die Ergebnisse des Cronjobs werden mit Zeitstempel versehen in die Logdatei '''/var/log/batched_discard.log''' geschrieben. Zum Ansehen verwendet man das Kommando {{{#!vorlage befehl tail /var/log/batched_discard.log }}} == TRIM per Online Discard == {{{#!vorlage hinweis Bei SSDs der ersten Baureihe fanden sich Berichte, wodurch die per „Online Discard“ entstehenden TRIM-Befehle die Performance der SSD reduzieren oder diese unbenutzbar machen ''könnten''. Bei aktuellen SSDs ist dieses Problem nicht bekannt. }}} Um die TRIM-Funktion „Online Discard“ nutzen zu können, mit deren Hilfe das Betriebssystem der SSD mitteilt, welche Datenbereiche nicht mehr benötigt werden und damit als gelöscht angesehen werden können, müssen einige [:mount#Optionen:Mountoptionen] in der '''[:fstab:/etc/fstab]''' gesetzt werden. Man öffnet dazu mit Root-Rechten [2] einen Editor [3] und ergänzt in der Datei '''/etc/fstab''' [4] die bestehenden Zeilen mit den Optionen `discard` und `noatime` : {{{ UUID=EIGENE_FESTPLATTE / ext4 [mark]discard[/mark],noatime,errors=remount-ro 0 1 }}} Die Option `discard` sorgt dabei dafür, dass TRIM-Befehle vom ext4-Dateisystem an den [wikipedia:Controller_(Hardware):Controller] der SSD durchgereicht werden, wenn Blöcke frei werden. Diese Option muss manuell gesetzt werden, da sie zurzeit noch [http://www.kernel.org/doc/Documentation/filesystems/ext4.txt deaktiviert ist] {en} („…but it is off by default until sufficient testing has been done.“). Die Option `noatime` sorgt dafür, dass durch die Nicht-Protokollierung von Zugriffszeiten die Festplattenaktivitäten reduziert werden, da nicht jedes mal bei einem Dateizugriff die [wikipedia:Inode:Inodetabelle] aktualisiert werden muss. Nach einem Neustart des Rechners sind beide Optionen aktiv. == Exkurs - Mountoption relatime == Aktuelle Ubuntuversionen binden Laufwerke von Haus aus mit der [:Mount:]option `relatime` (Relative Access Time) ein, was die Arbeit der SSD deutlich erleichtert. (Das ausdrückliche Hinzufügen dieser Mountoption in der '''[:fstab:/etc/fstab]''' ist seit Ubuntu 8.04 nicht mehr notwendig.) Der Kernel aktualisiert die letzte Zugriffszeit (Access Time) auf Dateien dann nur in bestimmten Zeitintervallen, die jedoch für nahezu alle Programme vollkommen ausreichend sind. Des Weiteren kann man, möchte man das Journaling nicht komplett abschalten (siehe [#Exkurs-Journaling-auf-SSD Exkurs: Journaling auf SSD]), die Mountoption `data=ordered` in '''/etc/fstab''' eintragen, welche einen guten Kompromiss zwischen vollem Journaling und gar keinem darstellt. Ein Vergleichstest zwischen de- und aktivierter Mountoption `discard` ist unter [#Links Links] zu finden. = TRIM mit Festplattenverschlüsselung = Damit ein „Batched Discard“ oder „Online Discard“ auf einer mit dm_crypt ([:LUKS:]) verschlüsselten Festplatte funktioniert, muss in der Datei '''/etc/crypttab''' die discard-Option eingetragen werden [2][3]: {{{ lvm_crypt UUID=e364d03f-[...]6cd7e none luks[mark],discard[/mark] }}} Danach ist noch das [wikipedia:initramfs:] mit {{{#!vorlage befehl sudo update-initramfs -u -k all }}} zu aktualisieren. Nach dem Neustart sollte TRIM tadellos funktionieren. Mit {{{#!vorlage befehl sudo dmsetup table /dev/mapper/lvm_crypt --showkeys }}} kann überprüft werden ob die discard-Option aktiv ist {{{ 0 975718448 crypt aes-xts-plain ca8cc8d753cdde99db20843ba783a8b78f5357a0f5073abc0d21c19525774c986eba3be44ddc065492d7562b880673ea6532b269136478da2efb9cf37ea58b0f 0 8:2 4096 1 allow_discards }}} falls am Ende 1 allow_discard steht ist alles ok. = TRIM der Swap-Partition = Seit Version 2.6.29 kann der Kernel TRIM per Discard auf [:Swap:]-Partitionen durchführen. „Online Discards“ können auch hier zu Einbußen der Performance der SSD führen. Seit Kernel 2.6.36 ist TRIM auf Swap-Partitionen daher optional und muss vom Anwender über die [:Swap#Swap-leeren:Swapon-Option] `-d` oder über '''[:fstab:/etc/fstab]''' und der Option `discard` aktiviert werden. Davon unabhängig führt [:Swap#Swap-leeren:Swapon] beim ersten Start des Swap einen Discard aus, was für normale Desktops und Notebooks, die nur ab und zu Speicher in den Swap auslagern, vollkommen ausreichend ist. Anwender, die damit leben können, brauchen also für die Swap-Partition keine Vorkehrungen bezüglich TRIM/Discard treffen. = TRIM mit Btrfs = {{{#!vorlage warnung [:Btrfs:] ist nach wie vor in der Entwicklung! Man sollte es daher nicht auf Produktivsystemen einsetzen und, wenn man es zum Testen einsetzt, vorher Backups machen! Vor allem sollte man das Skript '''wiper.sh''' auf keinen Fall anwenden, wenn man '''btrfs''' nutzt (siehe Abschnitt [#Links Links – Projekt hdparm/wiper.sh]). }}} Setzt man '''btrfs''' als [:Dateisystem:] ein, so ist das Journaling nicht so umfangreich, wie beim Dateisystem '''[:ext:]''', da '''btrfs''' nur [wikipedia:Metadaten:] speichert. Metadaten-Journaling garantiert lediglich die Konsistenz des Dateisystems, wohingegen beim Full-Journaling ('''ext3'''/'''ext4''') auch die Konsistenz der Dateiinhalte gewährleistet wird. (siehe [wikipedia:Journaling-Dateisystem:]). Btrfs setzt automatisch die Mountoption `-o ssd`, sofern es eine SSD als Festplatte erkennt. Laut [https://btrfs.wiki.kernel.org/index.php/FAQ#Is_Btrfs_optimized_for_SSD.3F Btrfs-Wiki] {en} geschieht dies per Standard ab Kernel 2.6.31. Nichtsdestotrotz kann man die Datei '''/etc/fstab''' [4] manuell anpassen , so dass sie wie folgt aussieht: {{{ UUID=EIGENE_FESTPLATTE / btrfs defaults,[mark]ssd,noatime,compress,[/mark]subvol=@ 0 1 }}} Die [:mount#Optionen:Mountoption] `ssd` sorgt für Folgendes: * Platziert neue Abgrenzungen in Bereiche, die mehrheitlich nicht belegt sind (''Places new extents into areas that are mostly free'') * Kombiniert neue Schreibvorgänge von vielen verschiedenen Dateien ohne eine [wikipedia:Fragmentierung_(Dateisystem):Fragmentierung] zu verhindern (''Combines new writes from many different files without trying to prevent fragmentation'') * Effektiv mit high-end SSD (''Effective on high end SSD'') Des Weiteren kann man auch die folgenden [:Btrfs-Mountoptionen:] setzen: * `ssd_spread` * Platziert neue Abgrenzungen in Bereiche, die mehrheitlich nicht belegt sind (''Places new extents into areas that are mostly free'') * Überschreibt einen kompletten gelöschten Block auf der SSD (''More likely to overwrite an entire erasure block in the SSD'') * Man sollte __nicht__ die Option `discard` (ab [:Kernel:] 2.6.32) verwenden, siehe [:Btrfs-Mountoptionen#Verbotene-Mountoptionen:Verbotene-Mountoptionen]. Mit dem Befehl {{{#!vorlage befehl cat /sys/block/sda/queue/rotational }}} im Terminal [3] kann man überprüfen, ob die eben gemachten Änderungen in '''/etc/fstab''' – nach einem Neustart des Rechners – korrekt übernommen wurden. Das Ergebnis sollte `0` sein. = Links = * Weiterführende Informationen zu TRIM: * [http://www.anandtech.com/show/2738/10 AnandTech.com: The Trim Command: Coming Soon to a Drive Near You] {en} * [askubuntu:18903:How to enable TRIM?] * [https://wiki.archlinux.de/title/Ext4#SSD_Trim_Support wiki.archlinux.de: Ext4-TRIM Support] {de} * [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=18f0f97850059303ed73b1f02084f55ca330a80c kernel.org: libata: add translation for SCSI WRITE SAME (aka TRIM support)] {en} * [http://www.ocztechnologyforum.com/forum/showthread.php?96382-Deterministic-Read-After-Trim ocztechnologyforum.com: Deterministic Read After Trim] {en} * Informationen zu manuellem TRIM (wiper.sh und DiskTRIM): * [http://www.ocztechnologyforum.com/forum/showthread.php?60882-wiper.sh-discussion-thread-%28Linux-TRIM-tool%29 ocztechnologyforum.com: wiper.sh discussion thread (Linux TRIM tool)] {en} * [http://www.ocztechnologyforum.com/forum/showthread.php?64684-DiskTRIM-Automated-graphical-user-interface-for-wiper.sh&p=455180&viewfull=1#post455180 ocztechnologyforum.com: DiskTRIM - Automated graphical user interface for wiper.sh] {en} * TRIM pro und contra: * [askubuntu:256:Does Ubuntu have support for the TRIM command for use with SSD?] * [http://thread.gmane.org/gmane.comp.file-systems.ext4/21914 gmane.org: Do not dispatch FITRIM through separate super_operation] {en} * [http://lwn.net/Articles/417485/ lwn.net: The best way to throw blocks away] {en} * [http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support#Kernel_realtime_discard_support opensuse.org: Kernel realtime discard support] {en} * [post:2799256: forum.ubuntuusers.de SSD Kaufberatung] * Projekt hdparm/wiper.sh: * [sourceforge:hdparm:] * [http://sourceforge.net/projects/hdparm/files/ Download des Skriptes wiper.sh] * [http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support#How_Often_should_I_run_wiper.sh opensuse.org: How Often should I run wiper.sh ] {en} * Informationen zu '''ext4''': * [https://ext4.wiki.kernel.org Informationen zu ext4 im ext-Wiki von kernel.org] {en} * [https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_is_the_difference_between_ext2.2C_ext3.2C_and_ext4.3F Unterschiede zwischen ext2, ext3, und ext4] {en} * [https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#File_System_Features Eigenschaften von ext2, ext3 und ext4] {en} * [https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_the_key_differences_between_ext3_and_ext4.3F Hauptunterschiede zwischen ext3 und ext4] {en} * [http://www.kernel.org/doc/Documentation/filesystems/ext4.txt Dokumentation des Filesystems ext4] {en} * [http://www.thomas-krenn.com/de/wiki/SSD_Performance_optimieren#Standardkonfiguration_ohne_ATA_TRIM Vergleichstest zur aktivierten/deaktivierten Mountoption "discard"] {de} * [http://people.redhat.com/lczerner/discard/test_discard.html people.redhat.com: test-discard results] {en} * Journaling bei '''ext4''': * [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#165 Linux Kernel Documentation: data=ordered] {en} * [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#169 Linux Kernel Documentation: data=writeback] {en} * Informationen zu '''btrfs''': * [https://btrfs.wiki.kernel.org/index.php/FAQ#Is_Btrfs_optimized_for_SSD.3F btrfs und SSD] {en} * [http://events.linuxfoundation.org/slides/2010/linuxcon2010_mason.pdf btrfs Filesystem – SSD Optimizations (PDF)] {en} Folie 16 des Oracle-Vortrages auf der LinuxCon North America 2010 * [http://www.madeo.co.uk/?p=346 madeo.co.uk: Intel X25-M Gen2 on linux – migrating to btrfs on kernel 2.6.33] {en} #tag: Hardware, Wiki, System