staging.inyokaproject.org

Die Diskussion stellt die Fortsetzung von Artikel zu SSD dar. Evtl wird auf dortige Posts bezug genommen.

UbuntuFlo schrieb:

noisefloor schrieb:

* Baustelle/SSD/TRIM in Teilen redundant mit Artikel zu Dateisystemen (z.B. der Teil zum Journaling von ext). Ist Trim wirklich SSD-spezisch oder bringt das bei allen HDs Vorteile?

Kann ich nicht sagen, da ich mich, aufgrund meines SSD-Kaufs, nur mit den Auswirkungen auf SSD beschäftigt habe.

UbuntuFlo schrieb:

noisefloor schrieb:

* Ist Trim wirklich SSD-spezisch oder bringt das bei allen HDs Vorteile?

Kann ich nicht sagen, da ich mich, aufgrund meines SSD-Kaufs, nur mit den Auswirkungen auf SSD beschäftigt habe.

So wie ich es verstanden habe ist das SSD-spezifisch. Wikipedia-Artikel sagt:

In computing, a TRIM command allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally. TRIM was introduced soon after SSDs started to become an affordable alternative to traditional hard disks as permanent storage in PCs.

Die von noisefloor angemerkte Überschneidung mit dem Artikel Dateisystem kann ich so erstmal nicht wieder finden.

Anmerkungen bzw. Wünsche von meiner Seite wären:

• Unter Baustelle/SSD/TRIM (Abschnitt „TRIM-mit-btrfs“) sind die Aufzählungen in englischer Sprache. Das ist an dieser Stelle nicht nötig.

• das wars eigentlich schon 😀

Syntaktisch hab ich gerade nochmal ein bisschen gebügelt und bin damit durch. Ist der Artikel inhaltlich vollständig, oder fehlt noch was?

Huhu!

Oh, stimmt, die englischen Begriffe. Die sind da schon seit Ewigkeiten drin, weil ich damals zu müde war, die zu übersetzen. ROFL!

Wenn jemand will, gerne. Ansonsten mache ich das, wenn ich fünf Minuten habe.

Der Artikel ist ansonsten feddich, jo. Jedoch könnte noch FITRIM und batched discard [1] mit rein. Auch der Kernel 2.6.27/38 findet sich noch nicht wirklich darin (in Bezug auf batched discard).

Liebe Grüße,

Flo

• 1: Quelle: http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support#Kernel_batched_discard_support

Huhu!

Übersetzungen habe ich versucht. Imho kann man das aber nicht wirklich übersetzen 😕 Wer andere/bessere Vorschläge hat, soll bitte Hand anlegen.

Erinnerung: UbuntuFlo schrieb:

Der Artikel ist ansonsten feddich, jo. Jedoch könnte noch FITRIM und batched discard [1] mit rein. Auch der Kernel 2.6.37/38 findet sich noch nicht wirklich darin (in Bezug auf batched discard).

Liebe Grüße,

Flo

• 1: Quelle: http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support#Kernel_batched_discard_support

Hab den Artikel nochmal gecheckt und auf wartend gestzt.

Der Artikel ist durchkontrolliert und wird voraussichtlich in den nächsten Tagen ins Wiki verschoben, wenn bis dahin keine Nachforderungen mehr kommen.

Der Artikel ist im Wiki. Mein Dank an alle Beteiligten für die konstruktive Zusammenarbeit. ☺

Liebe Grüße

martin

Hallo allerseits

Vielen Dank für eure Bemühungen. Ich habe schon einige Zeit auf genau diesen Artikel gehofft/gewartet. Hier ein kleines Feedback eines Users der sich irgendwo zwischen Anfänger und Fortgeschritten einordnen würde. Bitte entschuldigt, falls dieser Beitrag auf der falschen Seite ist. Ich dachte nur, dass man hier dann gleich den Wiki-Artikel verbessern könnte - deshalb habe ich ihn auf die Diskussionsseite gepackt.

Mit der Anleitung konnte ich feststellen, dass bei mir (Natty Narwal, ThinkPad T60, SSD vor 6 Monaten eingebaut) TRIM nicht automatisch funktioniert. Also bin ich der Anleitung für das Einstellen der "Trimmung" für das ext4-Filesystem gefolgt. Da entstanden die Probleme:

*Die Optionen die man im file /etc/fstab editiren soll, funktionieren meiner Meinung nach nicht, denn ein Leerzeichen nach "-o ..." bedeutet im fstab file ein Spaltenwechsel, den man ja noch nicht will, weil weitere Parameter folgen. Folge ich der Anleitung sieht meine fstab editiert folgendermassen aus (die UUID habe ich zur Sicherheit raus genommen):

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' 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>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda3 during installation
UUID='echte UUID' /               ext4    errors=remount-ro,-o discard,noatime 0       1
# /home was on /dev/sda5 during installation
UUID='echte UUID' /home           ext3    defaults        0       2
# /windows was on /dev/sda1 during installation
UUID='echte UUID' /windows        ntfs    defaults,umask=007,gid=46 0       0
# swap was on /dev/sda2 during installation
#UUID='echte UUID' none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

Wenn ich versuche die Datei neu zu laden (gemäss dem fstab-Artikel) erhalte ich:

sudo mount -a
[mntent]: Zeile 10 in /etc/fstab ist fehlerhaft

Das selbe passiert auch, wenn ich die vorgegebene Option "errors=remount-ro" lösche (was allerdings keine so gute Idee ist denke ich).

*Danach habe ich die Datei in den Originalzustand versetzt (unter <options> steht dann lediglich "errors=remount-ro") und versucht die "Trimmung" manuel zu machen. Ich habe mich dann für DiskTrim entschieden da ich mich auf unbekanntem Terain bewege und mit einem GUI etwas mehr Übersicht herrscht. Nun sagt mir aber das Software-Center, dass DiskTrim eine "falsche Architektur (amd64)" hat und damit kann ich das Tool nicht installieren. (Beschreibt "amd64", dass das Tool nur für 64bit System auf AMD-Prozessoren taugt?) Da traute ich mich auch nicht mehr die Shell Version zu bemühen. Denn wenn die auch nicht wirklich geeignet ist, dies nicht meldet und mir das System zerschiesst - nein Danke.

Somit meine Fragen:

Wie passt man fstab korrekt an? oder

Ist hdparm auf für intel 32bit Systeme geeignet?

Besten Dank Quesst

Hi quesst,

das "-o" in der fstab ist nicht zwingend erforderlich. Allerdings kommen danach immer die Mountoptionen. Zu Diesen gehoert auch "errors=remount-ro". Also muesste dein Eintrag in der /etc/fstab folgendermassen lauten:

UUID='echte UUID' /               ext4    discard,noatime,errors=remount-ro 0       1

Oder Alternativ: {{{ UUID='echte UUID' / ext4 -o discard,noatime,errors=remount-ro 0 1 }}}

Gruss Lasall

EDIT: Kommentar nach Anmerkung nox24s berichtigt.

quesst schrieb:

*Die Optionen die man im file /etc/fstab editiren soll, funktionieren meiner Meinung nach nicht, denn ein Leerzeichen nach "-o ..." bedeutet im fstab file ein Spaltenwechsel, den man ja noch nicht will, weil weitere Parameter folgen. Folge ich der Anleitung sieht meine fstab editiert folgendermassen aus (die UUID habe ich zur Sicherheit raus genommen):

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' 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>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda3 during installation
UUID='echte UUID' /               ext4    errors=remount-ro,-o discard,noatime 0       1
# /home was on /dev/sda5 during installation
UUID='echte UUID' /home           ext3    defaults        0       2
# /windows was on /dev/sda1 during installation
UUID='echte UUID' /windows        ntfs    defaults,umask=007,gid=46 0       0
# swap was on /dev/sda2 during installation
#UUID='echte UUID' none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

Wenn ich versuche die Datei neu zu laden (gemäss dem fstab-Artikel) erhalte ich:

sudo mount -a
[mntent]: Zeile 10 in /etc/fstab ist fehlerhaft

Das selbe passiert auch, wenn ich die vorgegebene Option "errors=remount-ro" lösche (was allerdings keine so gute Idee ist denke ich).

Die Angabe im Wiki war fehlerhaft. Ich habe dies eben korrigiert. Die -o darf man nur in der Shell bzw. Terminal anwenden aber nicht in der /etc/fstab. Einfach das -o weglassen.

Liebe Grüße

Benjamin

Mir ist aufgefallen, dass

sudo hdparm --fibmap tempfile 
0,17: device not found in /dev

dies als ein Gerät in /dev sucht. Warum? Kann es daran liegen, dass ich BTRFS nutze oder/und Ubuntu 11.04? Demzufolge kann ich nicht weitermachen mit dem testen ob das automatische TRIM meiner SSD greift. Jemand eine Idee?

Suuper - funktioniert nun alles bestens vielen Dank.

Nochmals eine kleine Frage. Die automatische Trimmung ist ja mit diesem Vorgehen nur für ext4 Partitionen. Nun habe ich aber auch noch eine ext3 (Daten)partition da ich diese zusammen mit Win7 verwende. Gibt es TRIM-Lösungen unter Linux für ext3 Partitionen?

Sollte wiper diese Aufgabe übernehmen können, steht meine ursprüngliche Frage noch immer im Raum betreffend der Systemkompatibilität mit dem Verfügbaren Paket.

Grüsse aus der CH Quesst

PS: Habe noch eine überflüssige Befehlsvolage-Zeile "sudo hdparm --fibmap tempfile" im ersten Kasten von "Testen des automatischen TRIM" entfernt, da die nächste Befehlsvorlage diesen genau nochmal bringt.

Letzhin gab es hier eine Änderung am Artikel, s. hier. Ich schätze mal, da ist etwas schief gelaufen - vielleicht bei der Arbeit am "Schlangentier"? Jedenfalls ist der eingefügte Text unpassend. Ich möchte das nicht selbst ändern, da sollte man ggf. den Author LarsT informieren?

Viele Grüße,
Ingo

Danke ingo2,

ich habe die Anmerkung entfernt, stelle sie hier aber zur Diskussion, da ich nicht weiß in wie fern sie stimmt.

LarsT schrieb:

Hallo, damit du TRIM unter Ubuntu 10.04 nutzen kannst, musst du den Kernel ab 2.6.33 nachinstallieren aus den Repos. Diese sind in den Repos enthalten.

Ich finde, wenn es denn stimmt, sollte das im Artikel vermerkt sein. Allerdings Wikikonform ☺

Gruß
kaputtnik

Es steht eigentlich schon im Artkel, s. den ersten Satz in diesem Abschnitt. Das sollte doch ausreichen? Ich habe den Verdacht, da ist aus Verehen ein Posting aus einem anderen Forums-Thred reingeraten?

Ingo