Ist es möglich, dass SSD TRIM (Discard) unter Linux auf ext4 + LVM + -Software-RAID funktioniert?

Wir verwenden RAID1 + 0 mit md unter Linux (derzeit 2.6.37), um ein md-Gerät zu erstellen, verwenden dann LVM, um die Datenträgerverwaltung über dem Gerät bereitzustellen, und verwenden dann ext4 als unser Dateisystem für die LVM-Datenträgergruppen.

Mit SSDs als Laufwerk möchten wir sehen, dass sich die TRIM-Befehle über die Ebenen (ext4 -> LVM -> md -> SSD) zu den Geräten ausbreiten.

Es sieht so aus, als ob in den letzten 2.6.3x-Kerneln eine Menge neuer SSD-bezogener TRIM-Unterstützung hinzugefügt wurde, einschließlich einer größeren Abdeckung von Device-Mapper-Szenarien, aber es scheint immer noch nicht möglich zu sein, dass es ordnungsgemäß herunterkaskadiert.

Ist das schon möglich? Wenn das so ist, wie? Wenn nein, werden Fortschritte erzielt?

Nicht möglich, da Linux Soft RAID dies (noch?) Nicht unterstützt.

UPD. : Dank Wodin für mich wissen zu lassen - nach lkml.org/lkml/2012/3/11/261 dieser funktionellen wurde hinzugefügt vorgeschlagen kürzlich. vorgeschlagen ! = angenommen , aber.

Ab 2.6.37 sollte es vorhanden sein ( Quelle ) . Der Kernel tut dies nicht im Hintergrund, der Block-Discard-Prozess ist derzeit so konzipiert, dass er bei Bedarf ausgeführt werden kann (Cron-Skript!). Dm-Crypt-Unterstützung gibt es noch nicht.

Am 13. Januar 2011 wurde ein Patch mit folgendem Inhalt in dm-raid1.c eingefügt:

dm raid1: support discard

Enable discard support in the DM mirror target.
Also change an existing use of 'bvec' to 'addr' in the union.

Ich bin nicht 100%, aber ich denke, das ist das Merge-Fenster für 2.6.38.

EXT4 hat vor einiger Zeit Unterstützung hinzugefügt, ebenso wie LVM. RAID ist der einzige Schlüssel, der keine Unterstützung bietet. Ab dem 13.01.2011 wurde anscheinend Unterstützung hinzugefügt. Suchen Sie danach in 2.6.38 oder vielleicht 2.6.39.

Die Zeit ist vergangen und TRIM-Unterstützung ist definitiv im 3.7-Kernel enthalten . Das Commit für RAID10 lautet :

Damit unterstützt md raid 10 TRIM. Wenn eine Platte discard_zero_data unterstützt und eine andere nicht, oder discard_zero_data und eine andere nicht, können Daten von solchen Platten inkonsistent sein. Dies sollte jedoch keine Rolle spielen, verworfene Daten sind nutzlos. Dies fügt jedoch beim Neuaufbau eine zusätzliche Kopie hinzu.

Mdtrim benötigt möglicherweise mehr Arbeit:

Cyberax-mdtrim-0a40e8d# ./mdtrim.py -m /dev/md4 -s /home
Scratch directory is /home, trimmer file size is 0 GB 790 MB
Found slave sdc2 on /dev/sdc with MD offset 0 and partition offset 249856
Creating trimmer file
252,2: device not found in /dev
Traceback (most recent call last):
  File "./mdtrim.py", line 120, in <module>
    if lines[2].find("assuming %d byte sectors" % sector_size) == -1:
IndexError: list index out of range

Sie können mein MDTRIM-Skript ( https://github.com/Cyberax/mdtrim/ ) verwenden, um leeren Speicherplatz auf ext4 / 3 Level-1-RAIDs zu TRIMMEN. Wir starten es regelmäßig von cron und es funktioniert großartig für uns.

Das Hinzufügen von Unterstützung für andere RAID-Level ist möglich, aber ich habe keine Zeit (oder brauche) dafür.

Wie hier vorgeschlagen können Sie verwenden

lsblk -D

um zu überprüfen, ob Ihre Blockgeräte die Discard-Befehle durchlaufen.

Beachten Sie auch, dass der Abschnitt devices in lvm.conf eine Option issue_discards enthält. Sehen

man 5 lvm.conf

Für mehr Information.