TRIM und Alignment unter Linux

[Eggcake]

Bin nun beim Laptop, wo die UltraDrive GX drin ist auf Ubuntu 10.04 umgestiegen. Ich bin wirklich totaler Linux Neuling, habe dazu zwei Fragen:

1) Ich habe gelesen, dass Ubuntu in der Version 10.04 mittlerweile ein korrektes Alignment durchführt...keine Ahnung ob das stimmt und ich habe es auch mit Anleitungen nicht geschafft etwas zu verändern bzw. weiss nichtmal wie man es nachträglich überprüfen kann...

2) TRIM. Es gibt ja eine wiper.sh welche man manuell durchführen kann. Die habe ich - jedoch muss ich hdparm auf eine neue Version updaten und weiss auch nicht wie das gehen soll :S


War schon etwas einfacher unter Win7 ^^

 

[pinki]

und genau deswegen bleib ich Linux fern, bin zu doof für Linux ^^
Habs vor jahren mal getetstet und bereits nach dem 3. start zum abstürzen gebracht lol

 

[antiram]

1) Ich habe gelesen, dass Ubuntu in der Version 10.04 mittlerweile ein korrektes Alignment durchführt...keine Ahnung ob das stimmt und ich habe es auch mit Anleitungen nicht geschafft etwas zu verändern bzw. weiss nichtmal wie man es nachträglich überprüfen kann...

sudo fdisk -clu /dev/sda
"c" schaltet die doskompatibilitätsmeckermeldungen ab, "u" schaltet auf sektornummeranzeige um, "l" listet auf, sda ist die erste festplatte zb. startsektor 2048 =1MB align

2) TRIM. Es gibt ja eine wiper.sh welche man manuell durchführen kann. Die habe ich - jedoch muss ich hdparm auf eine neue Version updaten und weiss auch nicht wie das gehen soll :S

cronjob täglich, steht in morphogs hilfe

hdparm installieren:
entpacken und dann:
make
sudo make install
wenns nicht geht dann vorher package build-essential installieren

oder neueren kernel installieren zb. 2.6.33.x oder .34 und mount option "discard" in /etc/fstab
UUID=123bla / ext4 discard,errblabla 0 0
Index of /~kernel-ppa/mainline

neueren kernel kann aber schwierigkeiten mit amd und nvidia grafiktreibern geben, mit den opensource treibern aber kein problem

 

[ulukay]

klar weil 100 doppelklicks ja soviel einfacher sind :P

 

[Eggcake]

Okay, aligned scheint es zu sein - Beginn Sektor 2048. Das scheint Ubuntu also mittlerweile richtig zu machen, sehr erfreulich
Rest hat jetzt auch geklappt. Mit make das neue hdparm installiert, nun funkt wiper. Das reicht mir schon, auf autotrim verzichte ich für's erste

Dankeschön


Edit: Oder funktioniert das "Auto" TRIM mit dem neuen Kernel denn mittlerweile wirklich zufriedenstellend?

 

[antiram]

kerneltrim funktioniert mit indilinx 1916 tadellos. ich benutze es seit 2.6.33-rc4, bin aber kurz danach von ext4 auf btrfs umgestiegen wegen ssd mode und besseres trim als bei ext4.

andere trim lösung ist wohl in arbeit, aber derzeit bringts nichts weil viele ssd-controller irgendwelche mucken haben bei trim. bei intel kann man nur 512 Teilbereiche pro trim befehl trimmen, bei sandforce bloß 64 und lahm, indilinx 1819 lahmt bei mehreren unmittelbar aufeinanderfolgenden trims.
Gmane Loom

 

[Eggcake]

Hm werde wohl doch erstmal darauf verzichten. Wie du siehst bin ich wirklich noch Neuling und muss mich erst mal etwas einarbeiten, von daher lass ich das Kernelupdate lieber für's erste

Aber gut zu wissen, dass es diesbezüglich vorwärts geht.

 

[ulukay]

@antiram, hast beim umstieg auf btrfs irgendwelche veraenderungen bemerkt?

 

[TheCritter]

Und nicht vergessen, das automat. TRIM funktioniert nur mit ext4, nciht aber mit ext3. Bei ext3 muss man offline manuell trimmen.

 

[antiram]

@antiram, hast beim umstieg auf btrfs irgendwelche veraenderungen bemerkt?

karmic auf btrfs mit 2.6.33 (und grub1):
1. kam öfter der fehler von hier beim booten
HowTO: Btrfs Root Installation - Ubuntu Forums
Part 3: Common Errors
udev failing to configure
mit lucid kam der fehler nicht mehr

2. in riesendateien rumschreiben (virtuelle festplatte als datei) geht nicht. die vm schrieb mit 20kb/s, derweil der host extreme mengen schreiben mußte. liegt wohl am copy on write. laut mason soll es mit writeback (bei der virtuellen festplatte) gehen und später richtig gefixt werden.
mit lucid nicht mehr probiert.

btrfs ssd mode um die lifetime zu erhöhen:
keine Ahnung wieviel das bringt, aber
mit ext4+discard und winxp als vm (kvm) mit partition als virtuelle platte (default writethrough) hatte ich 5-15 zyklen/tag wearout
mit btrfs+discard+ssdmode+nobarrier und winxp als vm (kvm) mit partition als virtuelle platte (writeback) habe ich 1-3 zyklen/tag wearout.
das liegt aber ganz überwiegend an dem writeback der virtuellen platte

btrfs schickt weniger trims als ext4, theoretisch also besser. zb. kerneltree löschen mit btrfs 10-100 trims, mit ext4 450-900 trims.
Man merkt aber keinen Unterschied zw. btrfs und ext4 im Alltag mit indilinx, vielleicht aber mit anderen ssds:
http://people.redhat.com/jmoyer/discard/ext4_batched_discard/

hier ist ein wiper.sh mit patches für intel, sandforce, ntfs, hfsplus:
General Discussion wiper.sh discussion thread (Linux TRIM tool)
hier ist ein wiper.sh patch für lvm und dm-crypt:
SourceForge.net: hdparm: Detail: 2997551 - TRIM support on LVM and dm-crypt

 

[ulukay]

wie liest du die zyklen/tag aus?

 

[antiram]

mit dem script von alloc
Guide Linux - Tips, tweaks and alignment
bißchen rumgebastelt, damit es alles loggt und in einem format abspeichert das man mit tabellenkalkulation einlesen kann und als /etc/cron.hourly/ssd_log gespeichert. kann man dann grafiken machen, irgendwann

für supertalent muss man noch smartmontools bauen und vorher im file knowndrives.cpp supertalent einbauen:

  { "Supertalent Ultradrive SSD",
    "STT[ _]FT[MD][0-9][0-9]G.*",
    "", "",
    " -v 9,raw64"
    " -v 12,raw64"
    " -v 184,raw64,Initial_Bad_Block_Count"
    " -v 195,raw64,Program_Failure_Blk_Ct"
    " -v 196,raw64,Erase_Failure_Blk_Ct"
    " -v 197,raw64,Read_Failure_Blk_Ct"
    " -v 198,raw64,Read_Sectors_Tot_Ct"
    " -v 199,raw64,Write_Sectors_Tot_Ct"
    " -v 200,raw64,Read_Commands_Tot_Ct"
    " -v 201,raw64,Write_Commands_Tot_Ct"
    " -v 202,raw64,Error_Bits_Flash_Tot_Ct"
    " -v 203,raw64,Corr_Read_Errors_Tot_Ct"
    " -v 204,raw64,Bad_Block_Full_Flag"
    " -v 205,raw64,Max_PE_Count_Spec"
    " -v 206,raw64,Min_Erase_Count"
    " -v 207,raw64,Max_Erase_Count"
    " -v 208,raw64,Average_Erase_Count"
    " -v 209,raw64,Remaining_Lifetime_Perc"
  },

 

[Alloc]

mit dem script von alloc

Ui, es wird sogar von noch jemand genutzt

bißchen rumgebastelt, damit es alles loggt und in einem format abspeichert das man mit tabellenkalkulation einlesen kann und als /etc/cron.hourly/ssd_log gespeichert. kann man dann grafiken machen, irgendwann

Das willst du nicht zufällig veröffentlichen? Wäre zwar nicht viel Arbeit das dahingehend anzupassen, aber wenn sich eh schon jemand die Arbeit gemacht hat ... =)

für supertalent muss man noch smartmontools bauen und vorher im file knowndrives.cpp supertalent einbauen:

Hm, das man die smartmontools bauen muss (zumindest war das bei Ubuntu9.04 noch der Fall) stimmt, aber eintragen musste man eigentlich nichts, da ich im Skript die Tools mit den entsprechenden Parametern aufrufe, damit die Werte als RAW angezeigt werden.
Sicher, dass das bei dir nötig war?

Grüße,
Chris

 

[Eggcake]

Hm also so ganz geheuer ist mir das jetzt auch nicht.

Ich habe grade nochmals getrimmt (sudo wiper.sh --commit /). Hat problemlos funktioniert.

Als ich danach Chromium öffnete, dauerte es etwa 10 Sekunden. Meinte dann, dass mein Profil nicht geladen werden konnte.
Habe dann einen Neustart durchgeführt - dann wurde die SSD überprüft. Hat keine Fehler gefunden. Jetzt funktioniert alles normal (scheint so zumindest).

Das hinterlässt jetzt aber keinen wirklich beruhigenden Eindruck...

 

[antiram]

fsck läuft in regelmäßigen Abständen, zb. alle 30 reboots. kann man einstellen mit zb. tune2fs -c 50 /dev/sda1

checksumme über alle Dateien im aktuellen Verzeichnis erstellen geht damit:
find . -type f -name "*" |sort | xargs md5sum | md5sum
müsste vor/nach trim gleich sein.

Hm, das man die smartmontools bauen muss (zumindest war das bei Ubuntu9.04 noch der Fall) stimmt, aber eintragen musste man eigentlich nichts, da ich im Skript die Tools mit den entsprechenden Parametern aufrufe, damit die Werte als RAW angezeigt werden.
Sicher, dass das bei dir nötig war?

ne nicht sicher, dein Script benutzt ja die Nummern und nicht die Namen. Müsste also egal sein. Bei mir lief es aber nach lucid upgrade nicht mehr und nach patchen und bauen läufts wieder.

geändertes script ist oben im anhang. txt Endung wegen Forumsupload

 

[Eggcake]

Das mit der Checksumme werde ich das nächste Mal testen.
Kann natürlich sein, dass es direkt zufällig der 30. Reboot war ...

Während dem TRIM wird wohl alles gelockt o.ä., könnte auch sein, dass ich den Browser zu "schnell" gestartet habe und er deshalb auf diverse Dateien nicht zugreifen konnte.

 

[antiram]

eigentlich wird nichts gelockt. bei gemountetem filesystem wird fast der ganze freie platz für ein großes file reserviert, die sektoren des files ermittelt, getrimmt und das file gelöscht. bei karmic kam manchmal ein "datenträger fast voll" popup. Könnte man sicher verhindern, aber nicht so wichtig.

 

[Eggcake]

Achso, also wirklich sehr ähnlich wie der wiper unter Windows.
Hm naja, keine Ahnung dann.

 

[Alloc]

Hi,

für die, die es interessiert: Hab das ssd_status.sh-Skript aktualisiert. Konfiguration kann nun am Anfang der Datei angepasst werden (smartctl-binary, Log-Einstellungen) und Statuswerte können optional in eine CSV-Datei geloggt werden, die man dann einfach mit einer Tabellenverarbeitung öffnen kann.
Danke an antimon für die Idee.
(Ansonsten ist das Skript etwas aufgeräumt und strukturierter als vorher und fängt auch mehr Fehler ab).

Zu finden ist die neue Version wieder unter http://chrilly.net/fi/ssd/

Grüße,
Chris

/Edit:
Achja, wer das Log-Feature sinnvoll nutzen will kann zB in der crontab (/etc/crontab) eine Zeile der folgenden Art einfügen:

*/30 * * * * root /home/ci/Desktop/SSD/ssd-status/ssd_status.sh

Der hinterste Teil ist einfach der Pfad zum Skript. "root" der Benutzer unter dem das Skript ausgeführt wird (muss ja für das Skript eh root sein), davor stehen die Zeitangaben, wann das Skript ausgeführt wird, in der Reihenfolge Minuten, Stunden, Tag des Monats, Monate, Tage der Woche. In dem Fall wird das Skript also an egal welchem Wochentag in egal welchem Monat in egal welcher Stunde alle 30 Minuten (*/30, */10 wäre zB alle 10 Minuten) ausgeführt.

 

[Eggcake]

Wieder gewipert, wieder dieselbe Meldung, 5 Minuten danach in Chromium (habe ich sonst nie) :

Your profile could not be opened correctly.

Some features may be unavailable. Please check that the profile exists and you have permission to read and write its contents.

 

[antiram]

habs grad nachgestellt auf ext4 mit neuem user und mein chromeprofil reinkopiert. kein fehler mit chromium und checksumme vor/nach trim gleich.

die checksumme mit dem "find.." von oben zickt bei dateinamen mit leerzeichen, damit gehts:
tar -c -C ~/.config/chromium/ . |md5sum

probiers mal, alle chromiums beenden vorher. die checksumme ändert sich bei jedem aufruf von chrom. benutzt du komische mount options?

 

[Eggcake]

Bisher nur -noatime.

Es ist mir jetzt aber auch mal während dem Betrieb passiert, dass das Profil nicht geladen werden konnte (ohne vorheriges TRIM). Weiss der Geier was das soll, es liegt aber zumindest wohl nicht an TRIM...
Ist aber auch nicht so ein übler Bug, wenn's nur alle paar Tage auftritt kann ich damit leben.

 

[frief]

In den aktuellen (svn) smartmontools ist die ssd übrigends in der smartctl database

Sieht jemand ausser mir ein Verhältnis von gelöschten zu geschriebenen Sektoren in der Größenordnung von 100??

Hier habe ich bei einer SuperTalent UltraDrive GX SSD STT_FTM64GX25H Firmware Version 1916 :

User Capacity: 64,023,257,088 bytes
Write_Sectors_Tot_Ct 302551716
Average_Erase_Count 295

daraus folgt mit 512 Byte/Sektor:

Faktor = Average_Erase_Count * User Capacity / (Write_Sectors_Tot_Ct * 512)
Faktor = (295 * 64,023,257,088 Byte) / (302551716 * 512 Bytes)
Faktor = 121.9 !!!

(Write amplification)

Grüße,
Frieder

 

[Kat-CeDe]

Hi,
ich konnte nur die 5.39-1 finden und da war STT noch nicht drin. Ich habe Vertex als Vorlage genommen und erhalte ca. 20. Ich habe average erase count von 78 und deutlich mehr Schreibzugriffe (470186690).

Bist Du sicher das 512 die richtige Sektorgröße ist? Waren die Einheiten auf einer SSD nicht 4K?

Ralf

 

[frief]

Hi,
ich konnte nur die 5.39-1 finden und da war STT noch nicht drin.

Ich hatte den Quellcode vom subversion Repository runtergeladen und kompiliert.

Ich habe Vertex als Vorlage genommen und erhalte ca. 20. Ich habe average erase count von 78 und deutlich mehr Schreibzugriffe (470186690).

Das ist deutlich günstiger!

Meine Platte habe ich wie ein rohes Ei behandelt: Fast ausschließlich Kernel >= 2.6.33, noatime, Partitionen auf 2 MByte aligned und wenig Nutzung.

Dadurch, dass diese SSD in den 563 Power_On_Hours sehr geschont wurde, könnte der Einfluss der Garbage Collection bei mir besonders deutlich sein (Ist zumindest meine Vermutung).

Bist Du sicher das 512 die richtige Sektorgröße ist? Waren die Einheiten auf einer SSD nicht 4K?

Ziemlich. Die Sektorgröße mit der das Betriebssystem Blockdevices behandelt beträgt normalerweise 512 Byte (die interne Sektorgröße eines Flashes ist davon unabhängig (und meist deutlich größer)).
Vielleicht sitze ich aber auch einem (Denk-)fehler auf.

 

[Kat-CeDe]

Hi frief,
ich habe nur 435 Stunden auf meinem Zähler.

Ziemlich. Die Sektorgröße mit der das Betriebssystem Blockdevices behandelt beträgt normalerweise 512 Byte (die interne Sektorgröße eines Flashes ist davon unabhängig (und meist deutlich größer)).
Vielleicht sitze ich aber auch einem (Denk-)fehler auf.

Tja aber nicht das Betriebssystem sondern die SSD zählt ja die Zugriffe. Ich würde mein Geld eher auf 4K setzen weiß es aber natürlich auch nicht genau.

btw. die 512 waren eine Größe die fest von Festplatten benutzt wurden. Betriebssysteme arbeiten schon lange mit Clustern oder Blöcken die meist bei 4K (oder größer) liegen.

Ralf

 

[frief]

Hi Kat-CeDe,

die Ausgabe von hdparm -I /dev/sda mit:
[..] Logical Sector size: 512 bytes [..]
deutet schon auf die 512 Byte Sektorgröße hin

Bei einer vermutlich vergleichbaren SSD wird hier in einem lesenswerten Artikel:
Guide SMART research - So how long will your SSD really last?
ein ähnlich hohes Verhältnis von gelöschten zu geschriebenen Sektoren beobachtet "practical write amplification due to erase block size and wear leveling is 55" ...

Und berechnet, dass aufgrund dieser Daten die dortige SSD noch 2.4 Jahre nutzbar sein sollte. Mit der Einschränkung: "[..] worse, probably the wear leveling is not so perfect and the drive could fail before [..]"

Indizien dafür, dass das wear leveling alles andere als perfekt ist, liegen bei meiner SSD vor:
206 Min_Erase_Count 2
207 Max_Erase_Count 791
208 Average_Erase_Count 356

Grüße,
Frieder

 

[antiram]

bei mir war write amplification 1:97,48 (berechnet aus 20 Tagen im Februar)
jetzt mit Optimierung sinds 1:26,35 (berechnet aus 20 Tagen im Mai).

hier ist auch noch was zum basteln, zb für chromium und firefox
https://launchpad.net/libeatmydata
einfach script mit
LD_PRELOAD=/usr/local/lib/libeatmydata.so chromium-browser $1
machen und anstatt chromium aufrufen