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 1 :
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.
1 Ź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ę.
dmsetup table | grep allow_discards