Hallo!
Welches Filesystem empfiehlt sich fuer eine SSD (und warum) und welche Mount-Optionen sollte man verwenden? Beherrscht Linux mittlerweile eigentlich den vollen TRIM-Support?
Man findet zu diesem Thema einige Beitraege im Internet oder im Listenarchiv, aber die scheinen oft veraltet. Vielleicht hat ja jemand *aktuelle* Infos und Ratschlaege. Auch zum TRIM-Support unter Linux findet man verschiedene Angaben - libata scheint es zu implementieren, aber wohl nicht so optimal wie vom ATA-8 Standard gefordert. Keine Ahnung ob das stimmt, aber solche Sachen findet man im Netz. Anybody?
Sollte man /tmp und /var besser nicht auf eine SSD legen?
Gruesse aus London, Thomas
PS: Es geht um eine OCZ Vertex 2E, die native TRIM Support unterstuetzt.
Hallo Thomas,
Am Mittwoch, 25. August 2010 schrieb Thomas Hertweck:
Hallo!
Welches Filesystem empfiehlt sich fuer eine SSD (und warum) und welche Mount-Optionen sollte man verwenden? Beherrscht Linux mittlerweile eigentlich den vollen TRIM-Support?
soweit ich weiß, wird allgemein eigentlich geraten, keine journaling filsysteme auf SSD's zu legen - um die zusätzlichen (kleinen, aber häufigen) Schreibzugriffe zu sparen. Wenn Du wie unten geschrieben aber nach Möglichkeit alles von der SSD verbannst, was ständig schreibt, dann erübrigt sich diese Frage so ziemlich - jedenfalls ist das dann nicht mehr unbedingt von der Art der Platte abhängig.
Man findet zu diesem Thema einige Beitraege im Internet oder im Listenarchiv, aber die scheinen oft veraltet. Vielleicht hat ja jemand *aktuelle* Infos und Ratschlaege. Auch zum TRIM-Support unter Linux findet man verschiedene Angaben - libata scheint es zu implementieren, aber wohl nicht so optimal wie vom ATA-8 Standard gefordert. Keine Ahnung ob das stimmt, aber solche Sachen findet man im Netz. Anybody?
keine Ahnung...
Sollte man /tmp und /var besser nicht auf eine SSD legen?
Wenn Du /temp, /var und /home nicht auf die SSD legst, vermeidest Du damit alles, was eine SSD vorzeitig altern lässt. Aber es gibt sicher auch Anwendungsfälle, in denen Dateien in diesen Verzeichnissen zwar nicht ganz so oft geschrieben, aber dafür aus fragmentierten Stückchen oft gelesen werden - damit würdest Du u.U. eine Menge an Performance verschenken. Es ist eine Abwägung zwischen der Art der Datenzugriffe und der dabei zu erwartenden Performance und dem Stress, dem Du die SSD damit aussetzen würdest...
Gruesse aus London, Thomas
Grüße aus Neukirchen-Vluyn Martin
Hallo!
On 25/08/10 23:32, Martin Hofius wrote:
soweit ich weiß, wird allgemein eigentlich geraten, keine journaling filsysteme auf SSD's zu legen - um die zusätzlichen (kleinen, aber häufigen) Schreibzugriffe zu sparen. Wenn Du wie unten geschrieben aber nach Möglichkeit alles von der SSD verbannst, was ständig schreibt, dann erübrigt sich diese Frage so ziemlich - jedenfalls ist das dann nicht mehr unbedingt von der Art der Platte abhängig.
Ich habe jetzt eine 11.3 komplett auf SSD installiert, incl. /var und /tmp. Schliesslich benutze ich ja die SSD wegen der Performance. Lediglich /home liegt auf einer anderen Platte, weil die grossen SSD doch noch ein bissl zu teuer sind.
[...] Wenn Du /temp, /var und /home nicht auf die SSD legst, vermeidest Du damit alles, was eine SSD vorzeitig altern lässt. Aber es gibt sicher auch Anwendungsfälle, in denen Dateien in diesen Verzeichnissen zwar nicht ganz so oft geschrieben, aber dafür aus fragmentierten Stückchen oft gelesen werden - damit würdest Du u.U. eine Menge an Performance verschenken. Es ist eine Abwägung zwischen der Art der Datenzugriffe und der dabei zu erwartenden Performance und dem Stress, dem Du die SSD damit aussetzen würdest...
Naja, wenn die SSD zwei oder drei Jahre haelt, waere das ja schon ausreichend. Wenn sie nach ein paar Wochen den Geist aufgibt, waere das nicht so gut. Mal liest da auch ziemlich viele unterschiedliche Infos im Internet, das ist doch alles etwas verwirrend. Greg Freemyer hat auf der Kernel Mailingliste geantwortet und auch einen Wiki Artikel gestartet: http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support Allerdings laesst der auch gewisse Fragen offen.
Cheers, Thomas
Hallo,
Am Sonntag, 29. August 2010 schrieb Thomas Hertweck:
Hallo!
On 25/08/10 23:32, Martin Hofius wrote:
soweit ich weiß, wird allgemein eigentlich geraten, keine journaling filsysteme auf SSD's zu legen - um die zusätzlichen (kleinen, aber
...
Ich habe jetzt eine 11.3 komplett auf SSD installiert, incl. /var und /tmp. Schliesslich benutze ich ja die SSD wegen der Performance. Lediglich /home liegt auf einer anderen Platte, weil die grossen SSD doch noch ein bissl zu teuer sind.
je nach System (Speicherausbau) könnte man z.B. /tmp auch in eine Ramdisk legen...
[...] Wenn Du /temp, /var und /home nicht auf die SSD legst, vermeidest Du
...
der dabei zu erwartenden Performance und dem Stress, dem Du die SSD damit aussetzen würdest...
Naja, wenn die SSD zwei oder drei Jahre haelt, waere das ja schon ausreichend. Wenn sie nach ein paar Wochen den Geist aufgibt, waere das nicht so gut. Mal liest da auch ziemlich viele unterschiedliche Infos im
naja, es gibt schon lange Leute, die zumindest einige Dinge seit Jahren auf einem USB-Stick liegen haben und fleißig damit arbeiten und auch schreiben (die ganzen portable-Lösungen für Windows z.B.) Und die halten schon etwas länger als nur ein paar Wochen, obwohl die Dinger vom eingebauten Controller her sicher weniger ausgefuchst sind als heutige SSD's. Die Haltbarkeit dürfe u.a. auch sehr vom Füllgrad abhängen - schließlich versuchen die Controller ja, Schreibzugriffe möglichst zu verteilen. Und das funktioniert umso besser bzw. länger, je mehr freie Bereiche vorhanden sind. Soweit ich das in Erinnerung habe, hat die c't mal einige Platten (und vorher auch USB-Sticks) einige Zeit mit Schreibzugriffen malträtriert, um die Lebensdauer zu testen. Und dabei sind eigentlich keine Ausfälle aufgetreten. Also würde ich grundsätzlich schon mal davon ausgehen, dass eine ansonsten intakte SSD auch bei ruppiger Behandlung ein Jahr oder länger halten wird...
Gruß Martin
On 26.08.2010, Thomas Hertweck wrote:
Welches Filesystem empfiehlt sich fuer eine SSD (und warum) und welche Mount-Optionen sollte man verwenden?
Ich wuerde XFS verwenden, wenn du etwas mehr "experimental" vertragen kannst, ist auch btrfs eine sehr gute Wahl.
XFS solltest du fuer eine SSD (und meiner Meinung nach auch sonst) unbedingt mit "nobarrier" mounten. Belies' dich bitte vorher auch ueber den Sinn und die Risiken, es wird gut auf den Seiten von SGI erklaert und auch im XFS Wiki. Btrfs bietet dir die mount option "ssd_spread". Ich habe sowohl xfs wie auch btrfs laengere Zeit auf einer SSD benutzt, die als schneller cache fuer einen squid webproxy dient(e), mit sehr guten Resultaten.
Beherrscht Linux mittlerweile eigentlich den vollen TRIM-Support?
Ich habe die Diskussionen ueber den block layer nicht weiter verfolgt, Linux war aber bereits bei 2.6.28/29 so weit, dass TRIM so weit moeglich unterstuetzt wurde. Dafuer ist im Kernel der block layer zustaendig, via BLKDISCARD, dem sog. "block layer discard request" blkdev_issue_discard(), blk_queue_set_discard(). Da auch der disk scheduler am Geschehen beteiligt ist, muss der auch mitspielen. Habe nicht nachgesehen, ob das damalige patchset implementiert wurde. Ich denke, wenn du zu den genannten Stichpunkten suchst, wirst du schnell das Noetige finden.
Man findet zu diesem Thema einige Beitraege im Internet oder im Listenarchiv, aber die scheinen oft veraltet. Vielleicht hat ja jemand *aktuelle* Infos und Ratschlaege. Auch zum TRIM-Support unter Linux findet man verschiedene Angaben - libata scheint es zu implementieren, aber wohl nicht so optimal wie vom ATA-8 Standard gefordert.
Suche nach den oben genannten Stichworten/Funktionen, TRIM wird ueber den block layer implementiert.
Sollte man /tmp und /var besser nicht auf eine SSD legen?
Ich wuesste nicht, was dagegen sprechen sollte.
On 26/08/10 07:49, Heinz Diehl wrote:
[...] Ich wuerde XFS verwenden, wenn du etwas mehr "experimental" vertragen kannst, ist auch btrfs eine sehr gute Wahl.
XFS solltest du fuer eine SSD (und meiner Meinung nach auch sonst) unbedingt mit "nobarrier" mounten. Belies' dich bitte vorher auch ueber den Sinn und die Risiken, es wird gut auf den Seiten von SGI erklaert und auch im XFS Wiki. Btrfs bietet dir die mount option "ssd_spread". Ich habe sowohl xfs wie auch btrfs laengere Zeit auf einer SSD benutzt, die als schneller cache fuer einen squid webproxy dient(e), mit sehr guten Resultaten.
XFS is fuer grosse Filesysteme ausgelegt, wir benutzen das bei der Arbeit (allerdings reden wir da von insg. > 2PT storage), ich kenne mich daher mit dem Filesystem aus. Ich habe jetzt mal ein System mit ext4 aufgesetzt. Das hat auch eine eigene "discard" Funktionalitaet.
Ich habe die Diskussionen ueber den block layer nicht weiter verfolgt, Linux war aber bereits bei 2.6.28/29 so weit, dass TRIM so weit moeglich unterstuetzt wurde. Dafuer ist im Kernel der block layer zustaendig, via BLKDISCARD, dem sog. "block layer discard request" blkdev_issue_discard(), blk_queue_set_discard(). Da auch der disk scheduler am Geschehen beteiligt ist, muss der auch mitspielen. Habe nicht nachgesehen, ob das damalige patchset implementiert wurde. Ich denke, wenn du zu den genannten Stichpunkten suchst, wirst du schnell das Noetige finden.
Deine Info ist nicht vollstaendig. Genereller TRIM support ist im Kernel schon seit 2.6.28 oder .29, das stimmt. Allerdings eben nicht wie vom ATA-8 Standard vorgeschlagen. Der Kernel erlaubt momentan nur einen zusammenhaengenden Bereich pro TRIM Kommando, waehrend der ATA Standard einen Vektor von nicht-zusammenhaengenden Bereichen erlaubt. Es gibt ein wiper.sh Skript (Teil des hdparm Pakets), das das TRIM Kommando so absetzt, allerdings funktioniert das bei meiner OCZ Vertex 2e nicht...
Cheers, Thomas
On Wednesday 25 August 2010 22:37:24 Thomas Hertweck wrote:
Welches Filesystem empfiehlt sich fuer eine SSD (und warum)
Ich bin einfach davon ausgegangen, dass das Dateisystem, das auf einer Festplatte zu mir passt, diese Eigenschaft auf einer SSD nicht verlieren wird.
und welche Mount-Optionen sollte man verwenden?
Die Fragen fangen schon beim Partitionieren an: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase... block-size/
Zum Journaling und Mount-Optionen relatime und noatime: http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/ Da steht auch was über den Mythos, kein ext3/4 für SSDs einzusetzen (auch in den Kommentaren)! Ein Link aus den Kommentaren über die Probleme früherer SSDs: http://www.extremetech.com/article2/0,2845,2329594,00.asp
Beherrscht Linux mittlerweile eigentlich den vollen TRIM-Support? [...]
http://en.opensuse.org/SDB:SSD_discard_(trim)_support Da dort von aktuellen 11.3-Kernel und dem 2.6.35 die Rede ist, scheint er aktuell zu sein.
Sollte man /tmp und /var besser nicht auf eine SSD legen?
Willst du die lieber auf eine normale Festplatte legen, weil dir der Zugriff sonst zu schnell ist? ;) Bei den momentanen Größen von SSDs gehe ich eh davon aus, dass mir spätestens in zwei Jahren eine neue kaufe.
Gruß Jan
Hallo,
On 26/08/10 09:03, Jan Ritzerfeld wrote:
Ich bin einfach davon ausgegangen, dass das Dateisystem, das auf einer Festplatte zu mir passt, diese Eigenschaft auf einer SSD nicht verlieren wird.
Naja, das ist dann vielleicht doch etwas naiv. SSDs haben besondere Eigenschaften, z.B. kann TRIM eine grosse Rolle spielen, und daher lohnt es sich schon ein wenig zu schauen, welches Filesystem fuer eine SDD evtl. am Besten geeignet ist und welches Filesystem aufgrund seiner Eigenschaften vielleicht eine SSD vorzeitig altern laesst.
http://en.opensuse.org/SDB:SSD_discard_(trim)_support Da dort von aktuellen 11.3-Kernel und dem 2.6.35 die Rede ist, scheint er aktuell zu sein.
Siehe meine anderen Antworten, es ging um den TRIM Support nach ATA-8 Standard.
Cheers, Thomas
Am Sonntag, 29. August 2010 schrieb Thomas Hertweck:
Hallo,
On 26/08/10 09:03, Jan Ritzerfeld wrote:
Ich bin einfach davon ausgegangen, dass das Dateisystem, das auf einer Festplatte zu mir passt, diese Eigenschaft auf einer SSD nicht verlieren wird.
Naja, das ist dann vielleicht doch etwas naiv.
Das kommt auf das Ziel an. Weder Schreib-Performance noch 100-jährige Haltbarkeit sind meine Ziele, die ich mit dem Einsatz von SSDs erreichen will. Daher sind die Eigenschaften von Dateisystemen für mich wichtiger, die sich eins zu eins von Festplatten auf SSDs übertragen lassen.
SSDs haben besondere Eigenschaften,
SSDs sind keine einfachen, rohen Flash-Speicher. Sie können schon von sich aus Wear Leveling und Garbage Collection.
z.B. kann TRIM eine grosse Rolle spielen,
http://www.heise.de/ct/hotline/Kein-Trim-Befehl-im-SSD-RAID-991529.html http://www.heise.de/newsticker/meldung/SSD-Hersteller-optimieren-Firmware- fuer-Windows-7-2-Update-842820.html http://en.wikipedia.org/wiki/Write_amplification#Limitations_and_dependencie...
und daher lohnt es sich schon ein wenig zu schauen, welches Filesystem fuer eine SDD evtl. am Besten geeignet ist
Sicher, wenn es nur nach der SSD ginge, würde ich btrfs mit der Option ssd nehmen. Aber solange "am Besten geeignet" nicht "10x schneller" bedeutet, ist das für meine Zielerreichung unerheblich.
und welches Filesystem aufgrund seiner Eigenschaften vielleicht eine SSD vorzeitig altern laesst.
http://www.storagesearch.com/ssdmyths-endurance.html Solange "vielleicht vorzeitig" nicht "in weniger als 3 Jahren" bedeutet, ist das für meine Zielerreichung unerheblich.
http://en.opensuse.org/SDB:SSD_discard_(trim)_support Da dort von aktuellen 11.3-Kernel und dem 2.6.35 die Rede ist, scheint er aktuell zu sein.
Siehe meine anderen Antworten, es ging um den TRIM Support nach ATA-8 Standard.
Ich dachte, in dem Wiki-Artikel geht es genau darum.
Gruß Jan
Wer sich fuer SSD interessiert und des Englischen maechtig ist, kann einen Blick auf den Thread "SSD / filesystem / TRIM" auf der opensuse-kernel Liste werfen. Da gab es nuetzliche Informationen.
Gruesse, Thomas
On 04.09.2010, Thomas Hertweck wrote:
Wer sich fuer SSD interessiert und des Englischen maechtig ist, kann einen Blick auf den Thread "SSD / filesystem / TRIM" auf der opensuse-kernel Liste werfen. Da gab es nuetzliche Informationen.
Ich lese zwar taeglich mit, fuer mich selber ist es aber uninteressant, da mein Laptop nur verschluesselte Partitionen beinhaltet, und device-mapper kann kein TRIM.
-
Heinz Diehl -
Jan Ritzerfeld -
Martin Hofius -
Thomas Hertweck