Fedora 18 - Brak Obsługi Funkcji Trim Na Dysku Systemowym Ssd

[koneton]

Cześć! Piszę tutaj, bo na pewno ktoś z Was miał już okazję uruchamiać obsługę funkcji TRIM na Fedorze. Mam na komputerze stacjonarnym dysk SSD KINGSTON SV300S37A120G, który obsługuje funkcję TRIM. Polecenie

hdparm -I /dev/sdb | grep "TRIM supported"

zwraca mi oczekiwane

Data Set Management TRIM supported (limit 1 block)

Zainstalowałem na nim Fedorę 18 (wersja 32 bit z PAE). Zgodnie z instrukcjami jakie znalazłem w sieci, zmodyfikowałem wpis fstab następująco:

UUID=0126d794-94a9-40ec-90f6-d5f1fa3654a7 /                       ext4    discard,noatime,nodiratime,errors=remount-ro        1 1
UUID=181ea4b6-6130-4708-b17b-ed24e8551631 /boot                   ext4    discard,noatime,nodiratime,errors=remount-ro        1 2
UUID=ae025038-ac45-4b21-8109-ee3a3ace2fa8 /home                   ext4    discard,noatime,nodiratime,errors=remount-ro        1 2 

Wydaje mi się, że to już powinno wystarczyć, więc po restarcie maszyny przeprowadziłem następujący test:

dd if=/dev/urandom of=tempfile bs=1M count=3
hdparm --fibmap tempfile
hdparm --read-sector [ADDRESS] /dev/sdb
rm tempfile && sync && sleep 120
hdparm --read-sector [ADDRESS] /dev/sdb

Niestety, ponowny odczyt sektora nie zwrócił oczekiwanych zer, a takie same wartości jak poprzednio. Dla uzupełnienia, podaję jeszcze szczegóły zainstalowanego jądra systemu

3.8.9-200.fc18.i686.PAE 

Byłbym wdzięczny, za jakieś rady lub informacje, co robię źle lub czego jeszcze nie zrobiłem, by poprawnie uruchomić funkcję TRIM na SSD.

[Gość]

Never mind. Na Archu jednak mi działa, coś zepsułem pierwszym razem.

Edytowane Maj 8, 2013 przez Gość

[Gość _PaT]

Ciekawy temat.

 

Właśnie zauważyłem, że też mam ten problem, ale wyłącznie na dyskach szyfrowanych. Mój kernel to 3.8.5-201.fc18.x86_64.

 

Wrzuć:

lsblk -D

 

Sprawdź konfigurację LVM:

grep issue_disc /etc/lvm/lvm.conf

 

 

Oraz czy masz w crypttabie allow-discards.

 

Również sprawdź tego buga.

[koneton]

Jeżeli chodzi o pierwszą komendę to mam:

lsblk -D
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0        0B       0B         0
├─sda1        0        0B       0B         0
├─sda2        0        0B       0B         0
├─sda5        0        0B       0B         0
└─sda6        0        0B       0B         0
sdb           0      512B       2G         0
├─sdb1        0      512B       2G         0
├─sdb2        0      512B       2G         0
└─sdb3        0      512B       2G         0
sr0           0        0B       0B         0

Co do reszty, to nie mam lvm tylko zwykłe partycje bez szyfrowania.

 

[Gość _PaT]

A gdy ręcznie wrzucisz fstrim to się sektor zeruje?

[koneton]

Nie, nadal jest tak samo.

[Gość _PaT]

Pozostaje zgłosznie buga. Ciekawi mnie, czy na x86_64 miałbyś ten sam problem.

[koneton]

Trochę poczytałem i okazało się, że ustawienia jakie zrobiłem były dobre. Błędny był test jaki zastosowałem. Założyłem, że funkcja TRIM zeruje usunięte dane, a tak wcale być nie musi. Doczytałem (http://en.wikipedia.org/wiki/TRIM#ATA), że są przynajmniej 3 sposoby implementacji tej funkcji. Jedna z nich polega na zerowaniu (lub wstawianiu samych jedynek) w miejsce usuniętych danych, druga polega na zwracaniu losowych wartości, a trzecia nie czyści oryginalnych danych i zwraca je takie same, jak przed usunięciem. Test jaki wykonałem, zakładał, że dane będą zerowane, a w przypadku mojego dysku tak się nie dzieje.

 

Niezerowe wartości polecenia lsblk -D dla dysku sdb oznaczają, że obsługuje on funkcję TRIM. To wszystko, nie trzeba robić nic więcej. Jeżeli chcemy sprawdzić, czy nasz dysk zeruje dane po usunięciu, to możemy podejrzeć wartość discard_zeroes_data, poprzez wykonanie polecenia:

cat /sys/block/sdb/queue/discard_zeroes_data
0
 

Jak widać, u mnie zwróciło 0, co potwierdza, że polecenie TRIM nie zeruje dysku (flaga jest nieustawiona). Dzięki za zainteresowanie tematem.

[Gość _PaT]

Zaiste, fascynująca lektura i nie mniej zatrważające wnioski. Dzięki!