SSD Trim unter Wheezy (3.0.0.1)

[fluetke]

nach der Neuinstallation meines Systems auf eine 64GB Kingston SSD funktioniert unter Wheezy das Trimmen der SSD nicht.
Trotz discard Option in der fstab und TRIM Unterstützung der Festplatte, zeigt der geläufige Trimtest mittels hdparm keine leeren Sektoren an.
Kann mir evtl. jemand von euch nen Tipp geben, woran das liegen könnte? Evtl. weiß ja noch jemand über irgendwelche undokumentierten Switches Bescheid.

Die diversen Einträge und Ausgaben häng ich euch mal an, falls ihr noch mehr Infos braucht, sagt Bescheid:

hdparm -I: 35861

Code: Alles auswählen

cat /etc/fstab | grep UUID
# device; this may be used with UUID= as a more robust way to name devices
UUID=24c1ccc1-3e30-4b1b-8858-33d336170333 /               ext4    discard,noatime,errors=remount-ro 0       1

Code: Alles auswählen

cat /etc/mtab | grep sdb
/dev/sdb1 / ext4 rw,noatime,discard,errors=remount-ro,commit=0 0 0

Code: Alles auswählen

fluetke@terra$ dmesg | grep sdb
[    1.509409] sd 2:0:0:0: [sdb] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
[    1.509481] sd 2:0:0:0: [sdb] Write Protect is off
[    1.509484] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    1.509506] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.510202]  sdb: sdb1
[    1.510442] sd 2:0:0:0: [sdb] Attached SCSI disk
[    2.076527] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[    5.779181] EXT4-fs (sdb1): re-mounted. Opts: (null)
[    5.801119] EXT4-fs (sdb1): re-mounted. Opts: discard,errors=remount-ro
[   13.282647] EXT4-fs (sdb1): re-mounted. Opts: discard,errors=remount-ro,commit=0

[syssi]

Siehst du spaeter moeglicherweise in Nachricht in Richtung:

Code: Alles auswählen

EXT4-fs warning (device dm-3): release_blocks_on_commit:2677: discard not supported, disabling

Gruss syssi

[fluetke]

nee,
nichts dergleichen dmesg schweigt zu dem Thema komplett.

[srevilo]

Hallo,

stehe im Moment vor dem gleichen Problem.
SSD ist hier eine Crucial m4 128 GB.

hdparm -I /dev/sda | grep -i trim

Code: Alles auswählen

           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read data after TRIM

cat /proc/version

Code: Alles auswählen

Linux version 3.0.0-1-486 (Debian 3.0.0-3) (ben@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-8) ) #1 Sat Aug 27 15:56:48 UTC 2011

cat /etc/fstab | grep UUID

Code: Alles auswählen

# device; this may be used with UUID= as a more robust way to name devices
UUID=c3744bfa-4629-45c5-879e-7e76d2c877d4 /               ext4    errors=remount-ro 0       1
UUID=9c84b088-4b04-45fd-9337-2ccfc1842bea /home           ext4    defaults        0       2
UUID=a434b30d-4541-4f91-b72a-f2ab7b869513 none            swap    sw              0       0

Sobald man als Parameter "noatime" bzw. "discard" (oder eine Kombination) für "/" und/oder "/home" angibt erhält man:
mount -a

Code: Alles auswählen

[mntent]: line 10 in /etc/fstab is bad
[mntent]: line 12 in /etc/fstab is bad

Benötigt man die Parameter eventuell bei Verwendung des Kernel V 3.0 nicht mehr?
Bzw. gibt es hierzu Neuigkeiten?

[habakug]

Hallo!

[mntent]: line 10 in /etc/fstab is bad

Meistens ist hier nur ein Leerzeichen zuviel:

Code: Alles auswählen

errors=remount-ro, noatime

statt

Code: Alles auswählen

errors=remount-ro,noatime

Gruß, habakug

[srevilo]

Danke.
Hat das Problem gelöst.

[maledora4]

...funktioniert unter Wheezy das Trimmen der SSD nicht.

Mich würde da die Ausgabe von

Code: Alles auswählen

fdisk -luc

aber noch interessieren.

[srevilo]

"fdisk -luc" funktioniert bei mir nicht - es erfolgt nur die Anzeige wie beim Aufruf mit "--help".
Zum Partitionieren habe ich gdisk verwendet.
Ausgabe von "gdisk /dev/sda" und Option "p" (für "print the partition table") liefert:

Code: Alles auswählen

Disk /dev/sda: 250069680 sectors, 119.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): B27D38D2-6B12-4806-9D49-86C129341C75      
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
  
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         8390655   4.0 GiB     8200  Linux swap
   2         8390656        37750783   14.0 GiB    8300  Linux filesystem
   3        37750784       250069646   101.2 GiB   8300  Linux filesystem

[maledora4]

Du warst zwar nicht gemeint, ...

Code: Alles auswählen

fdisk -luc
verlangt ab
fdisk -v (2.17.2)

Dafür kenne ich gdisk nicht. Dein Alignment sieht i.O. aus.

[fluetke]

hi da bin ich wieder,

fdisk -luc gibt mir:

Code: Alles auswählen

sudo fdisk -lc -u cylinders /dev/sdb

Disk /dev/sdb: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0001ba00

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   117186559    58592256   83  Linux

da nur 1 Partition auf der Platte existiert und die am Anfang losgeht, sollte das Alignment doch eigentlich stimmen, oder?

[maledora4]

Das Alignment sieht auch i.O. aus.

Wenn Du den Test so ausgeführt hast und dennoch keine Nullen angezeigt bekommst, dann sind der Möglichkeiten falscher Einstellung / Bedienung derart umfangreich,
daß es der Wissens-Aneignung dieser fleisigen Leute bedarf.

Viel Spaß beim Lesen!

[fluetke]

so, ich habe nun erneut den verlinkten TRIM-Test Anweisung für Anweisung genauestens durchgeführt(natürlich unter Anpassung des Devices und des Sektors) -- leider wie schon bei Eröffnung dieses Threads, ohne jeglichen Erfolg.
Was mir allerdings bei einem neuerlichen Check von dmesg | grep ATA auffiel,
ist das die SSD anscheinend momentan nur mit UDMA/100 läuft,
evtl. liegt da der Hase im Pfeffer(ihr merkt die Verzweiflungsvermutungen beginnen )

[maledora4]

Es stellt sich die Frage, wie Du die SSD in Betrieb genommen hast.
Welche BIOS-Einstellungen liegen bei Dir vor?
Warum weißt die Platte eine Konfiguration als sdb aus?

[fluetke]

naja in betrieb genommen in etwa so:
Anschließen
Checken das im BIOS AHCI aktiviert ist.
Debian testing installieren,ext4.
fstab für sdb += discard,noatime

1 Partition fürs System
sdb ist die Platte weil sie bei mir am 2ten SATA-port hängt, direkt hinter der win-Platte auf der auch meine Homepartition liegt.
Abgesehen vom SATAMode auf AHCI ist im BiOs nix Plattenartiges verstellt.

[maledora4]

Danke für Deine Antwort.

Meine Frage nach der Inbetriebnahme richtete sich darauf, weil es ja auch sein konnte, daß Du keine Neu-Installation gemacht sondern ein vorhandenes System auf die Platte "übernommen" hast. Stichwort der Befehl

Code: Alles auswählen

dd

nachzulesen in den Grundlagen der von mir oben verlinkten Artikel.
Gleichfalls gehe ich davon aus, die SSD war jungfräulich.

Ob UDMA100 eine Rolle spielt kann ich nicht beantworten, sehe selbst

Code: Alles auswählen

 DMA Setup Auto-Activate optimization

Was mir aber merkwürdig erscheint, ist

Code: Alles auswählen

*   Data Set Management TRIM supported (limit unknown)

m.E. müßte hier 4 oder 8 blocks stehen, weil

Auch SSDs arbeiten mit einer Pagegröße von 4 KiB bzw. 8 KiB.
und
Wenn Sie nämlich diese Partition mit einem Dateisystem mit einer typischen Blockgröße von 4 KiB formatieren, passen die 4 KiB Dateisystem-Blöcke nicht direkt in die 4 KiB Sektoren der Festplatte bzw. 4 KiB / 8 KiB Pages der SSDs. Beim Schreiben eines einzelnen 4 KiB Dateisystem-Blockes müssen dann zwei 4 KiB Sektoren bzw. Pages verändert werden.

Nachzulesen

Würde aber bedeuten, die Platte wurde schon benutzt...

[fluetke]

Naja, auch wenn die Platte schonmal benutzt worden wäre, sollte das nach ner Neuinstallation mit Repartitionierung eigentlich Wurscht sein.

[George Mason]

Naja, auch wenn die Platte schonmal benutzt worden wäre, sollte das nach ner Neuinstallation mit Repartitionierung eigentlich Wurscht sein.

Wieso denkst Du das?

[fluetke]

Weil ich davon ausgehe, dass sich die Platte danach an meine Partitionierung hält und nicht an die die davor drauf war. Die Extrafeatures wie Trim, etc. sollten sich daran doch nicht stören, oder bin ich da auf dem Holzweg? Sonst würde ja jeder Stichprobentest im Werk dazu führen, dass man die Platte danach quasi nicht mehr sinnvoll verkaufen kann.

[George Mason]

Bei einer Repartitionierung wird nicht viel auf die Platte geschrieben.. und eine Neuinstallation schreibt vielleicht ein paar hundert MB auf die Platte - bei heutigen Plattengrößen sind das nicht einmal 1% der Kapazität. Geh danach einmal mit nem Datenrettungstool drüber und dann frag dich nochmal, was für einen Unterschied die Neupartitionierung wirklich macht. Zum anderen findet das Schreiben von Daten und das Partitionieren auf dem User-Level statt - das Allozieren der Sektoren und Trimmen einen Level dadrunter. Ich wage zu behaupten, dass die Neupartitionierung und Neuinstallation überhaupt keinen Unterschied macht, solange kein Trim durchgeführt wird - aber ich kann mich irren.

[fluetke]

Ok, also was tun?
Ich hab nochmal in die Smart-Werte geguckt,
Betriebszeit der Platte ist 1Tag, damit könnte die Gebrauchtoption aus dem Rennen sein, denn das ist so ziemlich genau auch die Zeit die ich sie hier insgesamt in Betrieb habe.
Falls Smart nicht lügt, bzw. FW-Flashes den Zähler zurücksetzen.

[George Mason]

Mein fstab-Eintrag sieht so aus:

# / was on /dev/sda1 during installation
UUID=6c16df4a-e777-4033-ad44-d1062ffa8fd6 / ext4 defaults,noatime,discard,errors=remount-ro 0 1

Ich habe jetzt auch eine SSD und Trim funktioniert, wenn ich diesen Test mache:
http://wiki.aptosidusers.de/index.php?t ... RIM_testen

Gruß

[fluetke]

ah, Danke für diesen Link, ich glaube ich hab den Fehler gefunden:

Wichtig ist hier die Zeile: 32 heads, 32 sectors/track, 14593 cylinders Wenn wir bei fdisk nicht -H 32 -S 32 angegeben hätten, sähe die Zeile so aus: 255 heads, 63 sectors/track, 14593 cylinders und die Partition wäre für das blockweise Löschen einer SSD nicht korrekt ausgerichtet.

Bei mir sinds allerdings 63 sectors/track, könnte es evtl. daran liegen?

[George Mason]

Nicht unbedingt, denn fdisk unterstützt die GPT-Partitionierung nicht. Wenn ich die Werte mit fdisk auslese, meldet es mir auch:

255 heads, 63 sectors/track, 4865 cylinders, total 78165360 sectors

und gibt vorher die Meldung aus:

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.

Guck Dir mal gdisk an, verwende die Kommandos 'p' für print partition table und 'i' für information.

[fluetke]

Ok, also die Platte ist bei mir mit MBR formatiert,
gdisk spuckt folgendes aus:

Code: Alles auswählen

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if
you don't want to convert your MBR partitions to GPT format!
***************************************************************


Command (? for help): p
Disk /dev/sdb: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2D562FA5-45F9-4B62-A825-CA1915FAA6D6
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 7860845 sectors (3.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       117186559   55.9 GiB    8300  Linux filesystem

Command (? for help): i
Using 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 46E538E3-0CBD-4BDC-8B3E-AF20ED1F3DCD
First sector: 2048 (at 1024.0 KiB)
Last sector: 117186559 (at 55.9 GiB)
Partition size: 117184512 sectors (55.9 GiB)
Attribute flags: 0000000000000000
Partition name: 'Linux filesystem'

[George Mason]

mbr? Steht in den Guides nicht ausdrücklich, dass GPT die empfohlene Methode ist?

Das steht bei mir da:

Code: Alles auswählen

GPT fdisk (gdisk) version 0.7.2

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 78165360 sectors, 37.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3DB3BC49-B59A-4EB8-AB66-C7F4120E13A9
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 78165326
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        78165326   37.3 GiB    EF00  Root

Command (? for help): i
Using 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 8ED9AF16-C3B4-4AD5-B9AA-B18CCC171DAE
First sector: 2048 (at 1024.0 KiB)
Last sector: 78165326 (at 37.3 GiB)
Partition size: 78163279 sectors (37.3 GiB)
Attribute flags: 0000000000000000
Partition name: 'Root'