Überprüfen Sie die TRIM-Unterstützung mit BtrFS auf der SSD

Wir prüfen die Verwendung von BtrFS auf einem Array von SSD-Festplatten und wurden gebeten zu überprüfen, ob BtrFS beim Löschen einer Datei tatsächlich TRIM-Vorgänge ausführt. Bisher konnte ich nicht überprüfen, ob der TRIM-Befehl an die Datenträger gesendet wurde.

Ich weiß, dass BtrFS nicht als produktionsbereit gilt, aber wir mögen die neuesten Entwicklungen, deshalb teste ich es. Der Server ist die 64-Bit-Version des Ubuntu 11.04-Servers (mkfs.btrfs Version 0.19). Ich habe den Linux 3.0.0-Kernel installiert, da das BtrFS-Changelog angibt, dass Bulk-TRIM im mit Ubuntu 11.04 (2.6.38) gelieferten Kernel nicht verfügbar ist.

Hier ist meine Testmethode (ursprünglich von http://andyduffell.com/techblog/?p=852 übernommen , mit Änderungen für die Arbeit mit BtrFS):

• TRIMMEN Sie die Festplatten manuell, bevor Sie beginnen: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
• Vergewissern Sie sich, dass das Laufwerk auf TRIM eingestellt ist: ./sectors.pl |grep + | tee sectors-$(date +%s)
• Partitionieren Sie das Laufwerk: fdisk /dev/sda
• Machen Sie das Dateisystem: mkfs.btrfs /dev/sda1
• Montieren: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
• Erstellen Sie eine Datei: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
• Stellen Sie sicher, dass sich die Datei auf dem Datenträger befindet: ./sectors.pl | tee sectors-$(date +%s)
• Löschen Sie die Testdatei: rm /mnt/testfile
• Stellen Sie sicher, dass die Testdatei von der Festplatte abgeschnitten wurde: ./sectors.pl | tee sectors-$(date +%s)
• Überprüfen Sie die TRIM-Blöcke: diffdie beiden neuesten sectors-*Dateien

Zu diesem Zeitpunkt zeigen die Überprüfungen vor und nach dem Löschen immer noch dieselben verwendeten Plattenblöcke an. Ich sollte stattdessen eine Reduzierung der Anzahl der verwendeten Blöcke sehen. Warten Sie eine Stunde (falls es eine Weile dauert, bis der TRIM-Befehl ausgegeben wird), nachdem die Testdatei gelöscht wurde, werden immer noch dieselben Blöcke verwendet.

Ich habe auch versucht, mit den -o ssd,discardOptionen zu montieren, aber das scheint überhaupt nicht zu helfen.

Partition, die von fdiskoben erstellt wurde (ich halte die Partition klein, damit die Überprüfung schneller gehen kann):

root@ubuntu:~# fdisk -l -u /dev/sda

Disk /dev/sda: 512.1 GB, 512110190592 bytes
255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 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: 0x6bb7542b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63      546209      273073+  83  Linux

Mein sectors.plSkript (ich weiß, dass dies ineffizient ist, aber es erledigt die Arbeit):

#!/usr/bin/perl -w

use strict;

my $device = '/dev/sda';
my $start = 0;
my $limit = 655360;

foreach ($start..$limit) {
    printf "\n%6d ", $_ if !($_ % 50);
    my @sector = `/sbin/hdparm --read-sector $_ $device`;
    my $status = '.';
    foreach my $line (@sector) {
            chomp $line;
            next if $line eq '';
            next if $line =~ /$device/;
            next if $line =~ /^reading sector/;
            if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) {
                    $status = '+';
            }
    }
    print $status;
}
print "\n";

Ist meine Testmethode fehlerhaft? Vermisse ich hier etwas?

Danke für die Hilfe.

Nachdem ich viele Tage daran gearbeitet hatte, konnte ich zeigen, dass BtrFS TRIM verwendet. Ich konnte TRIM nicht erfolgreich auf dem Server ausführen, auf dem diese SSDs bereitgestellt werden sollen. Wenn Sie jedoch mit demselben Laufwerk testen, das an einen Laptop angeschlossen ist, sind die Tests erfolgreich.

Für all diese Tests verwendete Hardware:

• Entscheidend m4 SSD 512 GB
• HP DL160se G6
• LSI LSISAS9200-8e HBA
• generisches SAS-Gehäuse
• Dell XPS m1210 Laptop

Nach vielen fehlgeschlagenen Versuchen, BtrFS auf dem Server zu überprüfen, habe ich beschlossen, denselben Test mit einem alten Laptop durchzuführen (entfernen Sie die RAID-Kartenschicht). Die ersten Versuche dieses Tests mit Ext4 und BtrFS auf dem Laptop schlagen fehl (Daten nicht TRIM'd).

Anschließend habe ich die Firmware des SSD-Laufwerks von Version 0001 (im Auslieferungszustand) auf Version 0009 aktualisiert. Die Tests wurden mit Ext4 und BtrFS wiederholt, und beide Dateisysteme haben die Daten erfolgreich TRIMMEN lassen.

Um sicherzustellen, dass der TRIM-Befehl ausgeführt werden konnte, habe ich rm /mnt/testfile && sync && sleep 120vor der Validierung eine ausgeführt.

Eine Sache, die Sie beachten sollten, wenn Sie denselben Test versuchen: SSDs haben Löschblöcke, mit denen sie arbeiten (ich kenne die Größe der Crucial m4-Löschblöcke nicht). Wenn das Dateisystem den Befehl TRIM an das Laufwerk sendet, löscht das Laufwerk nur einen vollständigen Block. Wenn der TRIM-Befehl für einen Teil eines Blocks angegeben wird, wird dieser Block aufgrund der verbleibenden gültigen Daten im Löschblock nicht TRIM-fähig.

Also um zu demonstrieren, wovon ich spreche (Ausgabe des sectors.plobigen Skripts). Dies ist mit der Testdatei auf der SSD. Perioden sind Sektoren, die nur Nullen enthalten. Pluszeichen haben ein oder mehrere Bytes ungleich Null.

Testdatei auf Laufwerk:

24600 .......................................+++++++++++
24650 ++++++++++++++++++++++++++++++++++++++++++++++++++
24700 ++++++++++++++++++++++++++++++++++++++++++++++++++
    -- cut --
34750 ++++++++++++++++++++++++++++++++++++++++++++++++++
34800 ++++++++++++++++++++++++++++++++++++++++++++++++++
34850 +++++++++++++++++++++++++++++.....................

Testdatei vom Laufwerk gelöscht (nach a sync && sleep 120):

24600 .......................................+..........
24650 ..................................................
24700 ..................................................
    -- cut --
34750 ..................................................
34800 ..................................................
34850 ......................+++++++.....................

Es scheint, dass sich der erste und der letzte Sektor der Datei innerhalb eines anderen Löschblocks als der Rest der Datei befinden. Daher blieben einige Sektoren unberührt.

Dies ist ein Hinweis: Einige Ext4 TRIM-Testanweisungen fordern den Benutzer auf, nur zu überprüfen, ob der erste Sektor aus der Datei TRIM-bearbeitet wurde. Der Tester sollte einen größeren Teil der Testdatei anzeigen, um wirklich zu sehen, ob das TRIM erfolgreich war oder nicht.

Um herauszufinden, warum manuell über die RAID-Karte an die SSD gesendete TRIM-Befehle funktionieren, aber automatische TRIM-Befehle nicht ...

Nach dem, was ich gelesen habe, liegt möglicherweise ein Fehler in Ihrer Methodik vor.

Sie gehen davon aus, dass TRIM dazu führt, dass Ihre SSD die gelöschten Blöcke auf Null setzt. Dies ist jedoch häufig nicht der Fall.

Dies ist nur der Fall, wenn die SSD TRIM implementiert, sodass die verworfenen Blöcke auf Null gesetzt werden. Sie können überprüfen, ob das Gerät mindestens über ausreichende Kenntnisse verfügt, um discard_zeroes_data zu melden:

cat / sys / block / sda / queue / discard_zeroes_data

Auch wenn die SSD auf Null gesetzt ist, kann es einige Zeit dauern, bis die SSD die Blöcke tatsächlich auf Null gesetzt hat (dies gilt für einige SSDs mit geringerer Qualität).

http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html

Übrigens habe ich nach einem zuverlässigen Weg gesucht, um TRIM zu verifizieren, und noch keinen gefunden. Ich würde gerne wissen, ob jemand einen Weg findet.

Hier finden Sie eine Testmethode für 10.10 und EXT4. Vielleicht hilft es.

/ubuntu/18903/how-to-enable-trim

Oh, und ich denke, Sie brauchen den discard-Parameter auf dem fstab-Mount. Ich bin mir nicht sicher, ob SSD-Parameter benötigt werden, da ich denke, dass SSD automatisch erkannt werden sollte.

Für btrfs benötigen Sie die discardOption, um die TRIM-Unterstützung zu aktivieren.

Ein sehr einfacher, aber funktionsfähiger Test für TRIM ist hier: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

Einige Dinge, über die Sie nachdenken sollten (um Ihre Frage "Vermisse ich etwas?" Zu beantworten):

• Was genau ist / dev / sda? eine einzelne SSD? oder ein (Hardware?) RAID-Array von SSDs?

• Wenn letzteres dann welche Art von RAID-Controller?

• und unterstützt Ihr RAID-Controller TRIM?

und schlussendlich,

• Gibt Ihre Testmethode die Ergebnisse aus, die Sie erwarten, wenn Sie / dev / sda1 mit etwas anderem als btrfs formatieren?

Praktisch alle SSDs mit einer SATA-Schnittstelle führen eine Art Protokollstruktur-Dateisystem aus, das für Sie völlig unsichtbar ist. Der SATA-Befehl 'trim' teilt dem Gerät mit, dass der Block nicht mehr verwendet wird und dass das zugrunde liegende Protokollstruktur-Dateisystem ihn flashen kann / falls / der entsprechende Löschblock (der möglicherweise wesentlich größer ist) / nur / Blöcke enthält, die mit trim markiert sind.

Ich habe die Standarddokumente hier nicht gelesen: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , bin mir aber nicht sicher, ob es eine Standardgarantie gibt, die Sie in der Lage wären Die Ergebnisse eines Trimmbefehls anzeigen. Wenn sich etwas ändert, z. B. wenn die ersten paar Bytes zu Beginn eines Löschblocks auf Null gesetzt werden, gibt es meines Erachtens keine Garantie dafür, dass dies für verschiedene Geräte oder möglicherweise sogar für die Firmware-Version gilt.

Wenn Sie darüber nachdenken, wie die Abstraktion implementiert werden könnte, sollte es möglich sein, das Ergebnis des Befehls trim für denjenigen, der nur Blöcke liest / schreibt, vollständig unsichtbar zu machen. Darüber hinaus kann es schwierig sein, festzustellen, welche Blöcke sich im selben Löschblock befinden, da dies nur der Flash-Übersetzungsebene bekannt sein muss und diese möglicherweise logisch neu angeordnet hat.

Vielleicht gibt es einen SATA-Befehl (OEM-Befehl vielleicht?) Zum Abrufen von Metadaten im Zusammenhang mit der Flash-Übersetzungsschicht der SSDs?