ssd unf fstrim [gelöst]

[smutbert]

fstrim markiert immer die freien Blöcke als frei, unabhängig davon ob sie schon als frei markiert sind oder nicht. Ist also egal ob es zum 1., 2. oder 42. Mal ausgeführt wird. Die beanspruchte Zeit hängt außer von der Zahl der freien Blöcke auch sehr von der SSD und/oder dem SATA-Controller ab.

Um die SSD würde ich mir dabei keine Sorgen machen, habe noch nie gehört, dass das einer SSD geschadet hätte.

[Cae]

• 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.

tune2fs(8) schreibt dazu

Code: Alles auswählen

       -o [^]mount-option[,...]
[...]
                   discard
                          The file system will be  mounted  with  the  discard
                          mount  option.   This  will  cause  the  file system
                          driver to attempt to use the trim/discard feature of
                          some  storage devices (such as SSD's and thin-provi‐
                          sioned drives available in some  enterprise  storage
                          arrays)  to  inform  the  storage device that blocks
                          belonging to deleted files can be reused  for  other
                          purposes.   (This option is currently only supported
                          by the ext4 file system driver in 2.6.35+ kernels.)

Also scheint das im Kernel selbst drin zu sein (diese Manpage ist auch der einzige brauchbare 'trim'-Treffer im Source von e2fsprogs). mkfs.ext4 setzt dieses Flag im Dateisystem nur, fuehrt aber selbst nicht den Trim aus. Den muesste man demnach durch mindestens einmaliges Mounten triggern, moeglicherweise mit Idle-Zeit, falls Trim-Operationen als Optimierung mit niedriger Prioritaet laufen. Genaueres steht in den Kernel-Sourcen...

Gruss Cea

[Ulidor]

@ smutbert

Es scheint doch ein Unterschied zu sein, wann und wie oft man fstrim durchführt.

Beim ersten Mal nach fast 2 Jahren Benutzung:

Code: Alles auswählen

# fstrim -v /
/: 8230080512 bytes were trimmed

Da hatte ich die Zeit gestoppt, indem ich auf die Uhr geguckt habe, es waren ca. 4.20 Minuten.

Und beim zweiten Mal ein paar Stunden später:

Code: Alles auswählen

# time fstrim -v /
/: 406122496 bytes were trimmed

real    0m24.244s
user    0m0.004s
sys     0m0.060s

Beim zweiten Mal ging es viel schneller und es wurde nur ca. ein Zwanzigstel der Menge vom ersten Mal freigegeben.

[smutbert]

Ok, das ist bei mir anders. Zwei Mal direkt hintereinander:

Code: Alles auswählen

# time fstrim -v /mnt/fs.md1 
/mnt/fs.md1: 18000306176 bytes were trimmed

real	0m45.558s
user	0m0.000s
sys	0m0.864s
# time fstrim -v /mnt/fs.md1 
/mnt/fs.md1: 16733904896 bytes were trimmed

real	0m41.428s
user	0m0.004s
sys	0m0.760s

…hängt vielleicht auch von der Version von fstrim und/oder dem verwendeten Dateisystem ab.

[Ulidor]

Ok, das ist bei mir anders. Zwei Mal direkt hintereinander:

Wichtig wäre dann noch, wann du davor zuletzt fstrim ausgeführt hast. Wenn das ein deutlich größerer zeitlicher Abstand wäre als zwischen den beiden geposteten Aufrufen, dann wäre das tatsächlich anders als bei mir.

[smutbert]

vor einigen Wochen, schätzungsweise einem Monat, also tatsächlich eine deutlich längere Zeitspanne als die 1-2s zwischen den beiden geposteten Läufen.

Bei mir handelt es sich um btrfs, das sich insofern noch etwas anders verhält, als es gewissermaßen nur ungefähr den Speicher auf dem Medium (+ etwas Reserve) "belegt", den es tatsächlich verwendet, den Rest läßt es komplett links liegen. Das könnte erklären, warum beim zweiten Durchgang doch deutlich weniger Byte getrimmt wurden:
Nach oder vielleicht sogar während dem ersten Durchgang hat btrfs gemerkt, dass ~18GB Reserve etwas viel sind und hat den Datenbereich um einige GB verkleinert — bei einem dritten Lauf wäre es vermutlich bei den ~16-17GB geblieben (das ist zumindest meine naive Vorstellung von den Vorgängen).