niezależnie sprawdź, czy TRIM rzeczywiście działa na dysku SSD

Mam LUKSpartycję, /dev/sda1którą IuksOpen z --allow-discards:

cryptsetup --allow-discards luksOpen /dev/sda1 root

Następnie montuję ext4system plików z discardopcją:

grep /dev/mapper/root /proc/mounts
/dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0

Następnie przycinam wolne miejsce na zamontowanej partycji:

fstrim -v /

z df, widzę /ma 80% wolnego miejsca. Oznacza to, że na /dev/sda180% dysku są binarne zera.

Jeśli sklonuję obraz za pomocą cat

cat /dev/sda1 > sda1.img

i skompresuj obraz xz, oczekiwałbym, że wszystkie zera na dysku zostaną skompresowane. Ponieważ 20% danych na dysku jest zaszyfrowanych, powinno wyglądać losowo i być nieskompresowalne. Dlatego obraz skompresowany xz powinien mieć wartość około. 20% surowego rozmiaru.

Jednak wynikowy obraz skompresowany xz ma mniej więcej taki sam rozmiar jak surowy oryginał.

Czy moje rozumowanie jest prawidłowe?

Dlaczego moja teoria nie przekłada się na praktykę?

Twoja logika nie jest niepoprawna. Ale jest to ważne tylko wtedy, gdy spełnione są pewne warunki.

Polecenie TRIM , jak określono w zestawie poleceń ATA , może, ale nie musi, zerować sektory, przeciwko którym zostało wydane.
W rzeczywistości standard koncentruje się na tym, jakie dane należy zwrócić po wydaniu TRIM ¹ :

Poniższe zachowania są określone przez ten standard dla sektorów przycinanych przez urządzenie (patrz 7.5.3.3):

a) niedeterministyczny - dane w odpowiedzi na odczyt z przyciętego sektora mogą się zmieniać dla każdego odczytu, dopóki sektor nie zostanie zapisany przez host;
b) Deterministyczny odczyt po przycięciu (DRAT) - dane zwrócone w odpowiedzi na odczyt przyciętego sektora nie zmieniają się, ale mogą różnić się od danych, które zostały wcześniej zwrócone; oraz
c) Read Zeroes After Trim (RZAT) - dane zwrócone w odpowiedzi na odczyt przyciętego sektora wynoszą zero.

[...] Zarówno w przypadku DRAT, jak i niedeterministycznych urządzeń pamięci dane zwróciły się w odpowiedzi na polecenie odczytu do LBA, który został pomyślnie przycięty:

a) mogą być poprzednio zwróconymi danymi dla określonego LBA;
b) może być wzorem generowanym przez urządzenie pamięci; oraz
c) nie są danymi wcześniej zapisanymi przez innego hosta na innej karcie LBA.

Zatem to, po co urządzenie powróci, fstrimzależy od funkcji, które implementuje. O ile nie obsługuje RZAT, założenie, że dane odczytane z przyciętego urządzenia będą miały tylko zera, nie ma zastosowania.

Możesz hdparmto sprawdzić:

sudo hdparm -I /dev/sdX | grep -i trim

Przeprowadziłem kilka testów przy użyciu dwóch dysków SSD sdai sdb. Ten sam producent, różne modele, o różnej zgodności z ATA:

$ sudo hdparm -i /dev/sdb
 ...
 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7
 ...

$ sudo hdparm -i /dev/sda
 ...
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
 ...

Dwa dyski SSD mają różne wsparcie dla TRIM:

$ sudo hdparm -I /dev/sda | grep -i trim
           *    Data Set Management TRIM supported (limit 1 block)

$ sudo hdparm -I /dev/sdb | grep -i trim
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

Mogę potwierdzić, że po wydaniu fstrimdysk obsługujący „Deterministyczny odczyt ZERO po TRIM” (RZAT) wydaje się właściwie zerować daną partycję prawie całkowicie. I odwrotnie, wydaje się, że drugi napęd wyzerował (lub w inny sposób zastąpił go wysoce ściśliwym wzorem) tylko niewielką część uwolnionego miejsca.

¹ _{Źródło online: INCITS 529: Informatyka - Zestaw poleceń ATA / ATAPI - 4 (ACS-4)}

Uwaga na temat testowania:

Jak zauważył w komentarzach frostschutz , odczyt po fstrimmoże zwrócić dane z pamięci podręcznej systemu operacyjnego, a nie z przyciętego urządzenia. Tak dzieje się na przykład w tym konkursie .
(Chciałbym również wskazać tę odpowiedź na to samo pytanie dotyczące alternatywnej metody testowania TRIM).

Pomiędzy fstrimi kolejnym odczytem może być konieczne upuszczenie pamięci podręcznej, np .:

echo 3 | sudo tee /proc/sys/vm/drop_caches

W zależności od rozmiaru partycji, z którą grasz, nie upuszczenie pamięci podręcznej może wystarczyć do niepowodzenia testów.

Uwaga na temat konfiguracji:

Opcja discardmontowania włącza ciągłe TRIM, tzn. Za każdym razem, gdy pliki są usuwane. Nie jest to wymagane przez fstrim. Rzeczywiście, TRIM na żądanie i TRIM ciągły to dwa różne sposoby zarządzania operacjami TRIM. W celu uzyskania dalszych informacji wskazałbym dysk SSD na Wiki Arch Linux, który szczegółowo opisuje tę sprawę.

Czy dysk SSD ma wbudowaną warstwę szyfrowania sprzętowego? Jeśli tak, to bloki TRIMmed mogą być zerami (lub ewentualnie jedynymi) na poziomie sprzętowym, ale ponieważ komputer widzi je przez warstwę szyfrowania, po przejściu wszystkich będą wyglądać jak pseudolosowe bełkoty. -zeroes surowego bloku poprzez proces deszyfrowania.

Taka sprzętowa warstwa szyfrująca miałaby pewne zalety:

• Umożliwiłoby to bardzo szybkie usuwanie danych: wystarczy, że dysk zniszczy oryginalny klucz użyty w warstwie sprzętowego szyfrowania i zastąpi go nowym, a wszystkie dane będą natychmiast niemożliwe do odzyskania dla większości praktycznych celów.
• Ponieważ wszystkie dane trafiające na poziom sprzętowy zostałyby zaszyfrowane, z pewnością wyglądałby pseudolosowo, a zatem byłby w dużej mierze jednorodny. Może to pomóc w uniknięciu gorących / zimnych punktów i znacznie uprościć szacowanie zużycia.

Odrzuć to nie to samo, co zero.

Jeśli chcesz wyzerować za pomocą cryptsetup, możesz zmniejszyć FS, a następnie blok krypt, a następnie dodać niewykorzystane miejsce na woluminie.

Jeśli chcesz wiedzieć, czy trymowanie działało, próba prędkości powinna być wskaźnikiem po intensywnym użytkowaniu.

https://linux.die.net/man/8/fstrim https://en.m.wikipedia.org/wiki/Trim_(computing)

df raportowanie wolnego miejsca nie oznacza wyzerowanego miejsca.

triminformuje urządzenie pamięci, że bloki nie są używane. Nie sądzę, że to je zeruje.