SSD: TRIM, Alignment und LVM

dirkk

Active member
Themenstarter
Registriert
15 Apr. 2006
Beiträge
1.507
Habe eine SSD per LVM partitioniert. Wie kann ich:
  1. das Alignment
  2. das Funktionieren von TRIM
überprüfen bzw. testen? Die herkömlichen Methoden (ohne LVM) scheitern. Z. B. macht /dev/sda schon keinen richtigen Sinn.
 
Zuletzt bearbeitet:
Hallo dirkk,

prüfe erstmal mit cat /sys/block/sda/queue/discard_zeroes_data ob deine SSDs getrimmte Bereiche überhaupt als 0 anzeigt. Das hat sich bei der Vertex 2 zum Beispiel irgendwann mal geändert, seit dem funktionieren die bekannten Tests nicht mehr (ob das an neueren Kerneln oder an der Vertex 2 Firmware liegt, weiß ich nicht). Wenn dieser Aufruf eine 0 als Antwort bringt, dann werden getrimmte Bereiche nicht als 0 angezeigt, dann sind keine Tests möglich.

Generell kannst du aber davon ausgehen, dass Trim funktioniert wenn du es aktivieren kannst, andernfalls bringt mount beim Einhängen Fehler, schau einfach mal die Ausgabe von dmesg durch.

Ansonsten gibts ja noch den bisherigen "Standardtest" (ich nehme mal an den kennst du), dafür verweise ich mal auf meinen Blog.

Eigentlich sollte das auch unter LVM klappen, weil es ja trotzdem "irgendwo" auf der /dev/sda liegen muss (bzw. auf einer der SSDs/Festplatten eben). Alternativ kannst du es auch mit den /dev/mapper/.. Devices deines LVM versuchen, vermute aber dass du dabei genauso wenig Erfolg hast.
 
Zuletzt bearbeitet:
Hallo Evilandi,

Ausgabe von
Code:
cat /sys/block/sda/queue/discard_zeroes_data
ist 1, bzw.
Code:
 $ sudo hdparm -I /dev/sda | grep -i TRIM  
       *    Data Set Management TRIM supported (limit 8 blocks)
       *    Deterministic read ZEROs after TRIM
Zum Alignment:
Code:
 $ sudo sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=     2048, size=  1024000, Id=83, bootable
/dev/sda2 : start=  1026048, size=311554048, Id=8e
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0

$ sudo fdisk -l -u /dev/sda

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 Köpfe, 63 Sektoren/Spur, 19457 Zylinder, zusammen 312581808 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c5eb2

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048   312580095   155777024   8e  Linux LVM
Sieht das gut aus? Wie ist das mit den logischen Partitionen innerhalb von /dev/sda2 ? Oder sind die irrelevant?
 
Falls das jetzt keine religiösen Gefühle verletzt, würde ich sagen, dass man solche Prüfungen vornimmt, indem man Windows bootet und die Intel SSD Toolbox ausführt. Das sollte ja nun auch nicht kosten, da jedes TP irgendwas mit Windows zu tun hat.
 
Da täuscht du dich aber, denn auf diesem TP befindet sich kein Windows, und war nie eins drauf, und wird es auch nie. Nicht nur aus religiösen Gründen.
 
Sowohl die Startsektoren von /dev/sda1 als auch von /dev/sda2 sind durch 2048 teilbar, somit stimmt meiner Meinung nach das Alignment.

Innerhalb von sda2 befinden sich keine "logischen Partitionen" (deren Ausrichtung übrigens auch wichtig wäre, außer der "logischen Hauptpartition"*, welche die logischen Partitionen selbst beinhaltet.). Bei LVM sind die Strukturen aber weitaus komplexer und es gibt (außer man legt es mit der entsprechenden Option an) keine zusammenhängenden Partitionensbereiche oder sowas, somit kannst du auf das Alignment meines Wissens nach keinen Einfluss nehmen, weil LVM Speicherbereiche selbstständig verteilt.

*= Keine Ahnung wie da der Fachbgeriff dafür ist.

Vllt. können wir die Windows <-> Linux Debatte lassen, da sie a) OT ist, b) dirkk keins drauf hat und c) dass die SSD Toolbox von Intel LVM oder Ext4 Partitionen anzeigt bzw. deren Alignment prüfen kann, wage ich mal zu bezweifeln (weiß es aber nicht).
 
Zuletzt bearbeitet:
auf das alignment von lvm kann man durchaus einfluss nehmen. lvm arbeitet mit extents fester größe. logical volumes bestehen immer aus ganzzahligen vielfachen dieser extents. standard ist eine größe von 4 mb. vor dem ersten extents liegen die metadaten. bei älteren versionen kamen "krumme" größen zum einsatz, wodurch das alignment im eimer war. der ext{2,3,4}-entwickler/maintainer theodore ts'o hat daher mal eine recht interessante anleitung geschrieben, wie man partitionen, lvm und ext4 das richtige alignment verpasst. mittlerweile sollten fdisk, lvm und mke2fs dies automatisch machen. der befehl
Code:
pvs -o +pe_start
liefert den beginn des ersten physical extent. bei meiner c300 kommt 192 kb heraus. somit passt das alignment zur pagesize von ssds (4 kb oder 8 kb) und hdd mit 4 kb-sektoren. wenn man lvm nicht nur an der pagesize, sondern auch an der erase block size ausrichten möchte, muss man pvcreate mit --dataalignment und passendem wert aufrufen. als ich meine k5 eingerichtet habe, konnte man das alignment nur über --metadatasize beeinflussen. der dort angegebene wert wurde allerdings gerundet und es wurden somit mehrere anläufe nötig. bei meiner anderen ssd, der k5, hab ich den anfang so auf 1mb gelegt.

bei ext4 hat tytso beim aufruf von mke2fs stride und stripe-width gesetzt um die internen strukturen an den erase blöcken auszurichten. bei meiner k5 hab ichs auch gemacht, bei meiner aktuellen c300 dagegen nicht.
 
@ yaptu

Und was bedeutet folgende Ausgabe?

Code:
$ sudo pvs -o +pe_start
  PV         VG        Fmt  Attr PSize   PFree  1st PE 
  /dev/sda2  vg_****** lvm2 a--  148,53g 16,84g   1,00m
 
die ausgabe besagt, dass das erste physical extent um 1 mb nach hinten verschoben ist. es kommt also dasselbe alignment zum einsatz, wie es auch von fdisk verwendet wird. ergo, perfekt
 
die ausgabe besagt, dass das erste physical extent um 1 mb nach hinten verschoben ist. es kommt also dasselbe alignment zum einsatz, wie es auch von fdisk verwendet wird. ergo, perfekt

Ich stehe vielleicht ein bischen auf der Leitung: das heisst, dass *alle* Alignments richtig sind?

Muss mich mal in LVM etwas einlesen. Allerdings habe ich zu sowas VOR einer Installation keine Lust, auch wenn es logischer wäre...
 
prüfe erstmal mit cat /sys/block/sda/queue/discard_zeroes_data ob deine SSDs getrimmte Bereiche überhaupt als 0 anzeigt.
...
Wenn dieser Aufruf eine 0 als Antwort bringt, dann werden getrimmte Bereiche nicht als 0 angezeigt, dann sind keine Tests möglich.

Das ist wohl auch die Erklärung, wieso bei mir die "standard"-Tests zu zeigen scheinen, dass TRIM nicht funktioniert. Hab ne crucial M4 unter Ubuntu 11.10 im Einsatz
 
wenn du die ssd mit einer aktuellen distri (mint12 wäre so eine) oder windows ab vista partitioniert hast, liegen die partitionen allesamt richtig. das lvm liegt richtig innerhalb der partition. somit wäre alles in ordnung. in den vergangenen monaten hat sich auf dem gebiet zum glück einiges getan.
 
wenn du die ssd mit einer aktuellen distri (mint12 wäre so eine) oder windows ab vista partitioniert hast, liegen die partitionen allesamt richtig. das lvm liegt richtig innerhalb der partition. somit wäre alles in ordnung. in den vergangenen monaten hat sich auf dem gebiet zum glück einiges getan.

Und ich nehme an, Fedora 16 ist erst recht so eine...
 
na klar.

@ linrunner:
ich bezog mich auf den von dirkk durchgeführten test.
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben