Test dysków SSD na Linux - Jak sprawdzić realną szybkość i zdrowie?

Dobry test dysków SSD zaczynam od zdrowia nośnika, a dopiero później patrzę na transfery. Sam wynik „ile MB/s” niewiele mówi, jeśli dysk ma błędy, przegrzewa się albo pokazuje oznaki szybkiego zużycia. W tym tekście pokazuję, jak w Linuksie sprawdzić kondycję SSD, jak odróżnić test sprzętu od testu partycji i jak czytać wyniki tak, żeby nie wyciągnąć fałszywych wniosków.

Co naprawdę sprawdzam w SSD przed oceną jego stanu

Ja zwykle patrzę na cztery rzeczy: błędy odczytu lub zapisu, temperaturę, zużycie i historię testów. W SSD nie ma klasycznego „stukania głowicy”, więc objawy problemów bywają bardziej podstępne niż w HDD, a pierwszy sygnał ostrzegawczy często pojawia się w logach, nie w codziennej pracy.

SMART to zestaw atrybutów diagnostycznych zapisanych przez kontroler dysku. W praktyce chodzi o to, by zobaczyć, czy nośnik ma zapisane błędy, czy jego rezerwa zdrowych bloków nie topnieje i czy temperatura nie wchodzi w zakres, w którym kontroler zaczyna ograniczać wydajność. Dla nośników NVMe dochodzą jeszcze logi specyficzne dla tego standardu, które pokazują stan urządzenia nieco inaczej niż SATA.

• błędy i logi zdarzeń - szukam wpisów o realnych problemach z odczytem, zapisem lub integralnością danych;
• temperatura - sprawdzam nie tylko szczyt, ale też to, czy dysk stabilizuje się po dłuższym obciążeniu;
• zużycie - patrzę na wskaźniki typu „percent used”, liczbę zapisanych danych i rezerwę zapasowych bloków;
• historia self-testów - ważne są nie tylko wyniki, ale też to, czy problemy wracają w tym samym obszarze adresowym.

Jeśli nośnik przechodzi testy, ale jednocześnie jego temperatura rośnie do poziomu, który wywołuje throttling, traktuję to jako problem eksploatacyjny, a nie kosmetyczny. Z takiego punktu najprościej przejść do narzędzi, które pokażą stan i wydajność bez zgadywania.

Narzędzia, które dają sensowny obraz stanu i wydajności

W Linuksie najczęściej używam trzech warstw sprawdzania: narzędzia do kondycji dysku, narzędzia do logów NVMe i benchmarku I/O. GUI też istnieje, ale przy poważniejszym teście wolę terminal, bo daje większą kontrolę nad parametrami i łatwiej powtórzyć identyczny scenariusz.

Na Debianie i Ubuntu instaluję zwykle smartmontools, nvme-cli oraz fio. Na Fedora i Arch nazwy pakietów są praktycznie takie same, więc różni się głównie menedżer pakietów, nie sam zestaw narzędzi.

• sudo apt install smartmontools nvme-cli fio
• sudo dnf install smartmontools nvme-cli fio
• sudo pacman -S smartmontools nvme-cli fio

Gdy mam już narzędzia, przechodzę do ważniejszego rozróżnienia: nie każdy „test dysku” sprawdza to samo, a właśnie tu najłatwiej o pomyłkę.

Dysk, partycja i system plików to nie to samo

Jeśli mierzysz SSD, musisz wiedzieć, czy sprawdzasz nośnik jako sprzęt, partycję czy system plików. To trzy różne poziomy i każdy odpowiada na inne pytanie. Urządzenie fizyczne powie mi, czy sam dysk działa poprawnie. Partycja pokaże, jak rozmieszczone są dane. System plików odpowie za spójność zapisanych bloków, katalogów i metadanych.

lsblk -o NAME,SIZE,MODEL,FSTYPE,ROTA,MOUNTPOINTS

• urządzenie fizyczne - sprawdzam SMART i logi na poziomie dysku, np. /dev/sda albo /dev/nvme0;
• partycja - to logiczny fragment dysku, np. /dev/nvme0n1p2;
• system plików - to warstwa, którą kontrolują narzędzia typu fsck, e2fsck albo xfs_repair;
• punkt montowania - miejsce, w którym system „widzi” partycję, np. /home albo /mnt/ssd.

Przy dyskach SSD unikam agresywnych testów zapisowych typu „na ślepo”, jeśli nie mam kopii danych albo wolnego nośnika. badblocks potrafi być użyteczny w konkretnych scenariuszach, ale jako domyślny test SSD często robi więcej szkody niż pożytku, bo generuje niepotrzebny zapis. To właśnie w tym miejscu dobrze widać różnicę między oceną partycji a uczciwym sprawdzeniem nośnika.

Jak przeprowadzić bezpieczny test krok po kroku

Zawsze zaczynam od identyfikacji dysku i odczytu logów, dopiero potem uruchamiam testy obciążeniowe. W praktyce taki porządek oszczędza czas, bo jeśli SMART już pokazuje ostrzeżenie, nie ma sensu długo katować nośnika samym benchmarkiem.

1. Sprawdź, jaki to dysk i gdzie jest zamontowany

   lsblk -o NAME,SIZE,MODEL,FSTYPE,ROTA,MOUNTPOINTS

2. Odczytaj stan zdrowia

   smartctl -a /dev/sda
   smartctl -a /dev/nvme0
   nvme smart-log /dev/nvme0

   Na wielu systemach smartctl dobrze obsługuje także NVMe, ale nvme smart-log zwykle pokazuje ten stan czytelniej. Jeśli chcę pełniejszy obraz, porównuję oba wyniki.

3. Uruchom krótki self-test

   smartctl -t short /dev/sda
   smartctl -t short /dev/nvme0

   Krótkie testy zwykle trwają mniej niż 10 minut. Jeśli dysk jest obciążony, test może się wydłużyć, a sama wydajność systemu chwilowo spadnie.

4. Sprawdź log wyników

   smartctl -l selftest /dev/sda
   smartctl -l selftest /dev/nvme0

5. Wykonaj benchmark na dedykowanym pliku testowym

   fio --name=seqread --filename=/mnt/ssd/fio.test --size=8G --rw=read --bs=1M --direct=1 --ioengine=libaio --iodepth=16 --numjobs=1
   fio --name=rand4k --filename=/mnt/ssd/fio.test --size=8G --rw=randread --bs=4k --direct=1 --ioengine=libaio --iodepth=32 --numjobs=1

   direct=1 omija cache systemowy, więc wynik lepiej oddaje pracę samego nośnika. Plik testowy rzędu 8 GB pomaga też zobaczyć, jak dysk zachowuje się po wyczerpaniu krótkotrwałego bufora SLC, czyli warstwy, która przez chwilę przyspiesza zapis.

6. Jeśli trzeba, uruchom długi test

   smartctl -t long /dev/sda
   smartctl -t long /dev/nvme0

   Długie testy potrafią trwać od kilkudziesięciu minut do kilku godzin. Ja traktuję je jako narzędzie do podejrzanych dysków, a nie jako rutynowy pierwszy krok.

W praktyce najlepiej działa prosty schemat: szybki odczyt zdrowia, krótki self-test, potem benchmark i dopiero na końcu ewentualny test długi. Gdy mam wynik, przechodzę do jego interpretacji, bo sama liczba jeszcze niczego nie przesądza.

Jak czytać SMART, temperaturę i wyniki benchmarku

Wynik testu ma sens dopiero wtedy, gdy zestawisz kilka sygnałów naraz. Sama wysoka prędkość nic nie znaczy, jeśli dysk po 30 sekundach zaczyna throttling, a sam zapis kończy się na granicy temperatury. Z drugiej strony umiarkowany transfer nie jest problemem, jeśli nośnik jest zdrowy, stabilny i nie ma błędów.

Na SATA część atrybutów bywa vendor-specific, czyli zależna od producenta. Na NVMe mam zwykle czytelniejsze wskaźniki eksploatacyjne, ale i tak nie sprowadzam oceny do jednego numeru. Ja patrzę na trend z 2-3 pomiarów wykonanych w podobnych warunkach, bo dopiero wtedy widać, czy dysk faktycznie się pogarsza.

Warto też pamiętać o wolnym miejscu. Zostawienie 10-20% pojemności bez zapełniania pomaga SSD w zarządzaniu blokami, cache i wyrównywaniu zużycia. Gdy partycja jest niemal pełna, benchmark i codzienna praca często wyglądają gorzej, ale nie zawsze oznacza to awarię.

Po takim odczycie wyników łatwo przejść do pytania, czy problem leży w samym dysku, czy w sposobie jego podłączenia.

SATA, NVMe i USB nie zachowują się tak samo

To jeden z najczęstszych powodów błędnej diagnozy. SSD podłączony bezpośrednio do płyty głównej zachowuje się inaczej niż nośnik schowany w obudowie USB albo za kontrolerem RAID. W efekcie można dostać wynik, który bardziej opisuje mostek, obudowę lub sterownik niż sam dysk.

Przy NVMe często kluczowe są też temperatury w obudowie laptopa lub wąskiego desktopa. Jeśli nośnik po kilku minutach intensywnego zapisu wyraźnie zwalnia, nie zakładam od razu uszkodzenia kontrolera. Najpierw sprawdzam chłodzenie, przepływ powietrza i to, czy radiator faktycznie ma kontakt z kością.

Właśnie dlatego przy testach SSD nie lubię skrótów myślowych. Lepiej zrobić jeden spokojny, powtarzalny zestaw pomiarów niż ścigać się z przypadkowym wykresem.

Błędy, które najczęściej fałszują wynik

Widziałem już wiele „słabych SSD”, które były po prostu źle testowane. Najwięcej problemów powodują trzy rzeczy: porównywanie różnych narzędzi, testowanie w złych warunkach i interpretowanie pojedynczego wyniku tak, jakby był prawdą objawioną.

• porównywanie różnych programów - wyniki z jednego benchmarku nie są wprost porównywalne z innym, bo zmienia się wzorzec I/O;
• testowanie dysku systemowego podczas ciężkiej pracy - działające w tle aktualizacje, indeksowanie i cache potrafią kompletnie zmienić wynik;
• brak direct I/O - bez tego część odczytu może pochodzić z cache, a nie z samego nośnika;
• ocena po jednym przebiegu - pierwszy zapis bywa szybki dzięki SLC cache, ale dopiero dłuższy test pokazuje stabilność;
• ignorowanie temperatury - szybki spadek transferu często wynika z przegrzewania, a nie ze zużycia komórek;
• zbyt pełna partycja - gdy zostaje mało wolnego miejsca, SSD ma mniej przestrzeni na wyrównywanie zużycia i utrzymanie wydajności.

Ja sam staram się zostawiać przynajmniej 10-20% wolnej przestrzeni, jeśli mam wpływ na układ partycji. To nie jest magiczna liczba dla każdego modelu, ale w praktyce daje dyskowi oddech i ułatwia uczciwy benchmark. Jeśli dodatkowo porównujesz dwa nośniki, trzymaj ten sam kabel, ten sam slot, tę samą wersję kernela i ten sam zestaw parametrów testu.

Po odfiltrowaniu tych błędów zostaje najważniejsze pytanie: co zrobić, jeśli dysk wygląda dobrze, ale chcesz mieć spokojną głowę na dłużej.

Co robię po teście, zanim uznam nośnik za pewny

Jeśli nośnik przechodzi sprawdzenie bez błędów, nie zamykam tematu całkowicie. Zostawiam monitoring, a przy dyskach, które pracują intensywnie, planuję kolejny odczyt SMART za kilka tygodni. W przypadku laptopów i kompaktowych PC dodatkowo sprawdzam, czy obudowa nie podnosi temperatury SSD bardziej, niż powinna.

• Ustawiam okresowy odczyt SMART albo automatyczne alerty przez smartd.
• Po aktualizacji firmware lub zmianie obudowy ponawiam krótki test, bo warunki pracy mogły się zmienić.
• Jeśli pojawiają się pierwsze ostrzeżenia, nie czekam na pełną awarię, tylko robię kopię i obserwuję trend.
• Przy dyskach z wysoką temperaturą sprawdzam radiator, pad termiczny i przepływ powietrza, zanim uznam nośnik za wadliwy.

Jeśli chcesz wykonać test dysków SSD na własnym komputerze, trzymaj się tej kolejności: najpierw kondycja, potem partycje i dopiero na końcu benchmark. To daje wynik, który naprawdę coś mówi o nośniku, a nie tylko o chwilowej konfiguracji systemu. W praktyce najbardziej opłaca się nie szybki rekord transferu, lecz stabilny dysk, który po prostu robi swoje i nie zaskakuje w złym momencie.