Sprawdź obsługę TRIM za pomocą BtrFS na SSD

Rozważamy użycie BtrFS na macierzy dysków SSD i zostałem poproszony o sprawdzenie, czy BtrFS faktycznie wykonuje operacje TRIM po usunięciu pliku. Do tej pory nie byłem w stanie zweryfikować, czy polecenie TRIM zostało wysłane na dyski.

Wiem, że BtrFS nie jest uważany za gotowy do produkcji, ale lubimy najnowocześniejsze rozwiązania, dlatego go testuję. Serwer to wersja 64-bitowa Ubuntu 11.04 (mkfs.btrfs wersja 0.19). Zainstalowałem jądro Linux 3.0.0, ponieważ dziennik zmian BtrFS stwierdza, że ​​luzem TRIM nie jest dostępny w jądrze dostarczanym z Ubuntu 11.04 (2.6.38).

Oto moja metodologia testowania (początkowo przyjęta z http://andyduffell.com/techblog/?p=852 , z modyfikacjami do pracy z BtrFS):

• Ręcznie PRZYCINUJ dyski przed rozpoczęciem: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
• Sprawdź, czy dysk był TRIM'd: ./sectors.pl |grep + | tee sectors-$(date +%s)
• Podziel dysk na partycje: fdisk /dev/sda
• Ustaw system plików: mkfs.btrfs /dev/sda1
• Uchwyt: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
• Utwórz plik: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
• Sprawdź, czy plik znajduje się na dysku: ./sectors.pl | tee sectors-$(date +%s)
• Usuń plik testowy: rm /mnt/testfile
• Sprawdź, czy plik testowy ma TRIM z dysku: ./sectors.pl | tee sectors-$(date +%s)
• Sprawdź bloki TRIM'd: diffdwa najnowsze sectors-*pliki

W tym momencie weryfikacje przed usunięciem i po usunięciu nadal pokazują te same używane bloki dysku. Zamiast tego powinienem zauważyć zmniejszenie liczby używanych bloków. Oczekiwanie godziny (na wypadek, gdy polecenie TRIM zostanie wydane) po usunięciu pliku testowego nadal pokazuje te same używane bloki.

Próbowałem również montażu z -o ssd,discardopcjami, ale to wcale nie pomaga.

Partycja utworzona z fdiskgóry (utrzymuję małą partycję, aby weryfikacja mogła przebiegać szybciej):

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

Mój sectors.plskrypt (wiem, że jest to nieefektywne, ale wykonuje zadanie):

#!/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";

Czy moja metodologia testowania jest wadliwa? Czy coś mi umyka?

Dzięki za pomoc.

Po wielu dniach pracy nad tym byłem w stanie wykazać, że BtrFS używa TRIM. Nie mogłem pomyślnie uruchomić TRIM na serwerze, na którym będziemy wdrażać te dyski SSD. Jednak podczas testowania przy użyciu tego samego dysku podłączonego do laptopa testy są udane.

Sprzęt używany do wszystkich tych testów:

• Crucial m4 SSD 512 GB
• HP DL160se G6
• LSI LSISAS9200-8e HBA
• ogólna obudowa SAS
• Laptop Dell XPS m1210

Po wielu nieudanych próbach weryfikacji BtrFS na serwerze postanowiłem spróbować tego samego testu na starym laptopie (usuń warstwę karty RAID). Początkowe próby tego testu przy użyciu Ext4 i BtrFS na laptopie kończą się niepowodzeniem (dane nie są TRIM).

Następnie zaktualizowałem oprogramowanie napędu SSD z wersji 0001 (dostarczonej po wyjęciu z pudełka) do wersji 0009. Testy powtórzono z Ext4 i BtrFS, a oba systemy plików pomyślnie TRIM usunęły dane.

Aby mieć pewność, że komenda TRIM ma czas na uruchomienie, zrobiłem rm /mnt/testfile && sync && sleep 120przed sprawdzeniem poprawności.

Należy zwrócić uwagę, jeśli próbujesz wykonać ten sam test: dyski SSD mają bloki usuwania, na których działają (nie znam wielkości bloków usuwania Crucial m4). Gdy system plików wyśle ​​polecenie TRIM do napędu, napęd usunie tylko pełny blok; jeśli dla części bloku podano polecenie TRIM, blok ten nie będzie TRIM z powodu pozostałych ważnych danych w bloku kasowania.

Aby zademonstrować, o czym mówię (wynik sectors.plpowyższego skryptu). Jest to plik testowy na dysku SSD. Okresy to sektory zawierające tylko zera. Plusy mają jeden lub więcej niezerowych bajtów.

Plik testowy na dysku:

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

Plik testowy usunięty z dysku (po a sync && sleep 120):

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

Wygląda na to, że pierwszy i ostatni sektor pliku znajdują się w innym bloku kasowania niż reszta pliku. Dlatego niektóre sektory pozostały nietknięte.

Na wynos z tego: niektóre instrukcje testowania TRIM Ext4 proszą użytkownika, aby tylko sprawdził, czy pierwszy sektor został TRIM usunięty z pliku. Tester powinien wyświetlić większą część pliku testowego, aby naprawdę sprawdzić, czy TRIM się powiodło, czy nie.

Teraz, aby dowiedzieć się, dlaczego ręcznie wydawane polecenia TRIM wysyłane na dysk SSD za pośrednictwem karty RAID działają, ale automatyczne polecenia TRIM nie ...

W oparciu o to, co przeczytałem, może istnieć wada w twojej metodologii.

Zakładasz, że TRIM spowoduje, że Twój dysk SSD wyzeruje bloki, które zostały usunięte. Jednak często tak nie jest.

Dzieje się tak tylko wtedy, gdy SSD implementuje TRIM tak, że zeruje odrzucone bloki. Możesz sprawdzić, czy urządzenie przynajmniej wie wystarczająco dużo, aby zgłosić discard_zeroes_data:

cat / sys / block / sda / queue / discard_zeroes_data

Ponadto, nawet jeśli dysk SSD ma wartość zero, może zająć trochę czasu - znacznie po zakończeniu odrzucania - aby dysk SSD faktycznie wyzerował bloki (dotyczy to dysków SSD o niższej jakości).

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

BTW Szukałem niezawodnego sposobu weryfikacji TRIM i jeszcze go nie znalazłem. Chciałbym wiedzieć, jeśli ktoś znajdzie sposób.

Oto metodologia testowania dla 10.10 i EXT4. Może to pomoże.

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

Aha i myślę, że potrzebujesz parametru discard na montażu fstab. Nie jestem pewien, czy potrzebny jest parametr SSD, ponieważ uważam, że powinien automatycznie wykryć SSD.

W przypadku btrfs potrzebujesz discardopcji włączenia obsługi TRIM.

Bardzo prosty, ale działający test funkcjonalnego TRIM znajduje się tutaj: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

Kilka rzeczy do przemyślenia (aby pomóc odpowiedzieć na pytanie „czy coś mi brakuje?”):

• czym dokładnie jest / dev / sda? pojedynczy dysk SSD? czy macierz RAID (sprzętowa?) macierzy SSD?

• jeśli to drugie, to jaki rodzaj kontrolera RAID?

• i czy twój kontroler RAID obsługuje TRIM?

i w końcu,

• czy twoja metoda testowania daje ci oczekiwane wyniki, jeśli sformatujesz / dev / sda1 za pomocą czegoś innego niż btrfs?

Praktycznie na wszystkich dyskach SSD z interfejsem SATA działa system plików o strukturze dziennika, który jest całkowicie przed tobą ukryty. Komenda SATA „trim” informuje urządzenie, że blok nie jest już używany i że system plików struktury logów może sflashować go / if / odpowiedni blok kasowania (który może być znacznie większy) / tylko / zawiera bloki oznaczone trimem.

Nie przeczytałem standardowych dokumentów, które są tutaj: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , ale nie jestem pewien, czy istnieje jakakolwiek standardowa gwarancja na poziomie, którą możesz zobacz wyniki polecenia przycinania. Jeśli widzisz coś zmieniającego się, na przykład pierwsze kilka bajtów jest zerowane na początku bloku kasowania, nie sądzę, że istnieje jakakolwiek gwarancja, która ma zastosowanie do różnych urządzeń, a może nawet wersji oprogramowania układowego.

Jeśli pomyślisz o sposobie implementacji abstrakcji, powinna istnieć możliwość uczynienia wyniku polecenia przycinania całkowicie niewidocznym dla tego, który odczytuje / zapisuje bloki. Ponadto może być trudno stwierdzić, które bloki znajdują się w tym samym bloku kasowania, ponieważ tylko warstwa translacji flash musi o tym wiedzieć i mogła zmienić ich logiczną kolejność.

Być może istnieje polecenie SATA (być może polecenie OEM?) Do pobierania metadanych związanych z warstwą translacji flash dysków SSD?