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


Wir untersuchen BtrFS auf einem Array von SSD-Laufwerken und ich wurde gebeten zu überprüfen, ob BtrFS beim Löschen einer Datei tatsächlich TRIM-Operationen durchführt. Bisher konnte ich nicht überprüfen, ob der Befehl TRIM an die Festplatten gesendet wurde.

Ich weiß, dass BtrFS nicht als produktionsbereit betrachtet wird, aber wir mögen die blutigste Kante, daher teste ich es. Der Server ist Ubuntu 11.04 Server 64-Bit-Version (mkfs.btrfs Version 0.19). Ich habe den Linux 3.0.0 Kernel als den installiert BtrFS Änderungsprotokoll gibt an, dass Bulk-TRIM nicht in dem Kernel verfügbar ist, der mit Ubuntu 11.04 (2.6.38) ausgeliefert wird.

Hier ist meine Testmethodik (ursprünglich angenommen von http://andyduffell.com/techblog/?p=852, mit Änderungen an der Arbeit mit BtrFS):

  • Manuelles TRIM die Festplatten vor dem Start: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • Überprüfen Sie, ob das Laufwerk TRIM'd wurde: ./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
  • Erstelle eine Datei: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • Überprüfen Sie, ob sich die Datei auf dem Datenträger befindet: ./sectors.pl | tee sectors-$(date +%s)
  • Löschen Sie die Testdatei: rm /mnt/testfile
  • Beachten Sie, dass die Testdatei von der Festplatte TRIM-basiert ist: ./sectors.pl | tee sectors-$(date +%s) 
  • Überprüfen Sie die TRIM-Blöcke: diff die zwei jüngsten sectors-* Dateien

Zu diesem Zeitpunkt zeigen die Pre-Delete- und Post-Delete-Verifizierungen immer noch die gleichen verwendeten Festplattenblöcke an. Ich sollte stattdessen eine Verringerung der Anzahl der verwendeten Blöcke sehen. Wenn nach dem Löschen der Testdatei eine Stunde gewartet wird (falls es eine Weile dauert, bis der Befehl TRIM ausgegeben wird), werden immer noch dieselben Blöcke angezeigt.

Ich habe auch versucht mit dem zu montieren -o ssd,discard Optionen, aber das scheint überhaupt nicht zu helfen.

Partition, die erstellt wurde von fdisk oben (ich halte die Partition klein, damit die Verifizierung 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

Meine sectors.pl Skript (Ich weiß, das ist ineffizient, aber es macht die Arbeit erledigt):

#!/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 Testmethodik fehlerhaft? Fehle ich hier etwas?

Danke für die Hilfe.


20
2017-09-01 21:52


Ursprung


Ich unterstütze das Testen von blitzschnellen Dingen völlig, aber nur damit Sie wissen, dass btrfs im Moment keine fsck hat, die eigentlich Dinge repariert: btrfs.wiki.kernel.org/index.php/Main_Page - Pass also einfach auf. - Matt Simmons
@Matt - Guter Punkt über das fehlende fsck. Mein Verständnis ist, dass die erste Version eines fsck innerhalb der nächsten Wochen geliefert werden sollte, also sollten wir von der Zeit abgedeckt werden, die wir diese in die Produktion verschieben. Darüber hinaus verfügen wir über mehrere Kopien unserer Daten. Wenn wir also eine Kopie verlieren, verfügen wir über mindestens zwei weitere Kopien. Aber ich stimme zu, dass dies nicht das Dateisystem für Menschen mit unersetzlichen Daten ist. - Shane Meyers
Wahrscheinlich wird sich nichts ändern, aber Sie könnten auch versuchen, eine sync nach dem rmming der Datei. - zebediah49
Ich möchte sagen, dass ich versucht habe, eine sync nach dem Entfernen der Datei und die Ergebnisse waren immer noch die gleichen. Ich werde das überprüfen, wenn ich nach dem Wochenende wieder im Büro bin. - Shane Meyers
Wenn es Ihnen nichts ausmacht, haben Sie in Betracht gezogen zfsonlinux.de ? natives (d. h. in Kernel, nicht fuse) ZFS für Linux. Sie stehen kurz vor einer offiziellen "Veröffentlichung" und haben RCs verfügbar (einschließlich PPA für Ubuntu - leicht genug, um auch für Debian neu zu erstellen) - cas


Antworten:


Nachdem ich viele Tage damit gearbeitet habe, konnte ich zeigen, dass BtrFS TRIM verwendet. Ich konnte TRIM nicht erfolgreich auf dem Server arbeiten lassen, auf dem wir diese SSDs bereitstellen werden. Beim Testen mit demselben Laufwerk, das an einen Laptop angeschlossen ist, sind die Tests jedoch erfolgreich.

Hardware für all diese Tests:

  • Crucial 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 verifizieren, entschied ich mich, diesen Test mit einem alten Laptop zu versuchen (entfernen Sie die RAID-Kartenschicht). Die ersten Versuche dieses Tests mit Ext4 und BtrFS auf dem Laptop scheitern (Daten nicht TRIM'd).

Ich habe dann 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 mit TRIM versehen.

Um sicherzustellen, dass der Befehl TRIM Zeit hatte zu laufen, habe ich eine rm /mnt/testfile && sync && sleep 120 vor der Validierung.

Eine Sache, die Sie beachten sollten, wenn Sie den gleichen Test versuchen: SSDs haben Löschblöcke, auf 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 spezifiziert ist, wird dieser Block aufgrund der verbleibenden gültigen Daten innerhalb des Löschblocks nicht getrimmt.

Um zu demonstrieren, worüber ich rede (Output der sectors.pl Skript oben). Dies ist mit der Testdatei auf der SSD. Perioden sind Sektoren, die nur Nullen enthalten. Pluszeichen haben ein oder mehrere Nicht-Null-Bytes.

Testdatei auf dem Laufwerk:

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

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

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

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

Ein Take-Away-Formular: Einige Ext4-TRIM-Testanweisungen fordern den Benutzer auf, nur zu überprüfen, ob der erste Sektor aus der Datei TRIM-deklariert wurde. Der Tester sollte einen größeren Teil der Testdatei anzeigen, um zu sehen, ob der TRIM erfolgreich war oder nicht.

Um herauszufinden, warum manuell ausgegebene TRIM-Befehle an die SSD über die RAID-Karte gesendet werden, funktionieren die automatischen TRIM-Befehle nicht ...


3
2017-09-20 00:27



Ich dachte, dass alle HW-RAID-Befehle trimmen, schön zu sehen, dass sich die Dinge langsam ändern. Auf der anderen Seite spielt TRIM mit guten modernen Antrieben immer weniger eine Rolle. - Ronald Pottol


Basierend auf dem, was ich gelesen habe, könnte es einen Fehler in Ihrer Methodik geben.

Sie gehen davon aus, dass TRIM dazu führt, dass Ihre SSD die Blöcke löscht, die gelöscht wurden. Dies ist jedoch oft nicht der Fall.

Das ist nur dann, wenn die SSD TRIM implementiert, so dass es die Nullen setzt   verworfene Blöcke. Sie können überprüfen, ob das Gerät mindestens genug weiß   discard_zeroes_data melden:

cat / sys / block / sda / warteschlange / discard_zeroes_data

Auch wenn die SSD null ist, kann es einige Zeit dauern - lange danach   die Verwerfung ist abgeschlossen - damit die SSD die Blöcke tatsächlich auf Null setzt   (Dies gilt für einige minderwertige SSDs).

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

BTW Ich war auf der Suche nach einer zuverlässigen Möglichkeit, TRIM zu verifizieren und habe noch keine gefunden. Ich würde gerne wissen, ob jemand einen Weg findet.


3
2018-06-22 21:46





Hier ist Testmethodik für 10.10 und EXT4. Vielleicht wird es helfen.

https://askubuntu.com/questions/18903/how-to-enable-trim

Oh, und ich denke, du brauchst den Parameter discard auf dem fstab mount. Nicht sicher, ob SSD-Param benötigt wird, da ich denke, dass es SSD automatisch erkennen sollte.


2
2017-09-01 23:07



Ich habe versucht, den Ext4-SSD-Verifizierungsanweisungen zu folgen, aber sie funktionieren nicht aufgrund von Unterschieden in der Funktionsweise von BtrFS im Vergleich zu anderen Dateisystemen. Daher der Workflow, den ich entwickelt habe. Ich habe das benutzt ssd Mount-Option, um sicherzustellen, dass BtrFS seinen SSD-spezifischen Code verwenden konnte, obwohl er automatisch erkannt werden sollte. Ich habe es auch versucht discard (wie oben erwähnt) und es hat nicht geholfen. - Shane Meyers
Naja. Einen Versuch wert :) - Dave Veffer


Für Btrfs brauchst du discard Option zum Aktivieren der TRIM-Unterstützung.

Ein sehr einfacher aber funktionierender Test für funktionelle TRIM ist hier: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2 


0
2017-09-02 05:32



Wie ich bereits erwähnt habe, habe ich meine Tests mit beiden getestet discard Option und die ssd Möglichkeit. Die BtrFS-Dokumente erwähnen das ssd Option viel, also konzentrierte ich meine Tests dort, aber keine der Optionen führte zu dem Ergebnis, das ich erwartet hatte. Die meisten Webseiten, die zeigen, wie man TRIM testet, sind für Ext4 und dergleichen. BtrFS kann nicht mit diesen Methoden getestet werden, da sich das Dateisystem unterscheidet. - Shane Meyers
hdparm --fibmapist FS Agnostiker. Ein Block bei gegebener LBA-Adresse wird entweder auf Null gesetzt oder nicht, egal, ob es extN, btrfs, xfs, jfs ... ist. ssd Option ist irrelevant für die Trimmung, siehe z.B. Diese Diskussion auf der Mailingliste btrfs: mail-archive.com/linux-btrfs@vger.kernel.org/msg10932.html. - Paweł Brodacki
Ich habe es versucht hdparm --fibmap aber es funktioniert nicht mit BtrFS. Wenn Sie sich die README-Datei wiper.sh (verteilt mit hdparm) ansehen, stellen sie explizit fest, dass "FIEMAP / FIBMAP ioctl () - Aufrufe bei Verwendung auf einem btrfs-Dateisystem völlig unsicher sind." Also ist hdparm out, was schade ist, da dies das Testen sehr viel einfacher machen würde. Ich wusste das nicht ssd Option hatte nichts mit TRIM zu tun, da die Dokumente nicht sehr klar in Bezug auf die Nützlichkeit der Option sind. - Shane Meyers
Danke für die zusätzlichen Informationen über ioctls, ich wusste es nicht. Ich denke, der beste Ort, um nach zusätzlichen Informationen zu fragen, könnte Btrfs Mailing-Liste sein. Von dort erhalten Sie Informationen aus erster Hand. - Paweł Brodacki


Einige Dinge, über die Sie nachdenken sollten (um Ihre Frage zu beantworten: "Ich vermisse etwas?"):

  • 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 dein RAID-Controller TRIM?

und schlussendlich,

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

0
2017-09-15 13:27





Praktisch alle SSDs mit einer SATA-Schnittstelle führen ein Log-Struktur-Dateisystem aus, das Ihnen komplett verborgen bleibt. Der SATA-Befehl 'trimmen' teilt dem Gerät mit, dass der Block nicht mehr verwendet wird und das zugrunde liegende Protokollstruktur-Dateisystem ihn blinken lässt / falls / der entsprechende Löschblock (der wesentlich größer sein kann) / nur / Blöcke enthält, die mit trim markiert sind.

Ich habe die Standarddokumente, die hier sind, nicht gelesen: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim, aber ich bin mir nicht sicher, ob es eine Standard-Level-Garantie gibt, dass Sie die Ergebnisse eines Trim-Befehls sehen können. Wenn Sie sehen, dass sich etwas ändert, wie die ersten paar Bytes, die zu Beginn eines Löschblocks auf Null gesetzt werden, glaube ich nicht, dass es eine Garantie gibt, dass dies auf verschiedene Geräte oder vielleicht sogar Firmware-Versionen anwendbar ist.

Wenn Sie darüber nachdenken, wie die Abstraktion implementiert werden könnte, sollte es möglich sein, das Ergebnis des Trimmbefehls für den gerade lesenden / schreibenden Block vollständig unsichtbar zu machen. Außerdem kann es schwierig sein zu sagen, welche Blöcke sich im selben Löschblock befinden, da nur die Flash-Übersetzungsschicht das wissen muss und sie möglicherweise logisch neu angeordnet hat.

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


0
2017-09-14 04:54