Dysk SSD NVMe nie osiąga prędkości zapisu

XFS jeszcze pogorszy sprawę na zaszyfrowanej pamięci, bo ten FS bardziej obciąża procesor niż EXT.

Przypominam, że deklarowane wartości producenta to odczyt 3500 MB/s, zapis 3200 MB/s.

W Windowsie Samsung Magician, czyli program do obsługi dysków Samsunga, który z wersji na wersję jest co raz bardziej nieprzyjazny i niepotrzebny umożliwił mi update firmware dysku.
Jeśli mnie pamięć nie myli to nie można włączyć przyspieszenia RAPID MODE dla tego dysku albo mi to umknęło dzięki wspomnianemu wcześnie mega idiotycznemu interfejsowi użytkownika tego programu.
------------------------------------------- WYNIKI OSTATECZNIE ---------------------------------------------------------

W Linuksie wyniki bez zmian po upgradzie do ostatniej wersji firmware.
W Windowsie natomiast takie mamy wyniki przed i po upgradzie firmware:

PRZED uaktualnieniem firmware.
Przechwytywanie02

PO aktualizacji firmware:
Przechwytywanie49

Mam jeszcze zrzuty z innych programów ale uważam, że ten jest najpopularniejszy w Windowsie.

Co natomiast z tym pomysłem z systemem XFS na niezaszyfrowanej partycji 1). 2). XFS + lepszy proc?
Czy aż tak odstające wyniki nie są spowodowane tym, że test producentów zwykle odbywają się na dwóch dyskach osobno (np. przesył z jednego do drugiego lub odczyt na jednym, zapis na drugim).
Dowiedziałem się, że tak to robią, tylko nie wiem którym z tych dwóch wariantów,

Więc?
Da coś zamiana systemu plików na niezaszyfrowanym XFS z lepszym procem?

LINUKS: a to na LiveCD PO update firmware próbka 100 MB i 1000MB:

a teraz próbka 1000 MB

a to jest spowolnienie ciekawe czy spowodowane temperaturą czy być może wolnym CPU, który dla mnie wydaje się w sam raz:

Nadal robisz testy na zaszyfrowanej partycji?

Nie od dawana już nie. Gdyby którykolwiek test z nowych był na zaszyfrowanej to bym poinformował.
Windows NTFS żadne szyfrowanie, Linuks EXT4 bez szyfrowania.

DLA MNIE B.WAŻNE PYTANIE więc wybaczcie osobny wpis.

Czy uważacie patrząc na wyniki testów, w Windowsie i w Linuksie, że przyczyną jest zbyt wolny procesor?

Na ile możemy zmniejszyć lub wyeliminować tę hipotezę?

@anon741072 szczególnie do Ciebie kieruje to pytanie

@anon41799040 Czy muszę uruchamiać co jakiś czas komendę/y związaną TRIM? Czy w ogóle to chodzi w pełni automatycznie i TRIMuje dysk bez konieczności mojej ingerencji w ten proces?

Trim należy robić regularnie. Komendę można wywoływać ręcznie, można odpowiednio skonfigurować system, żeby robiło się samo: wpisami w /etc/fstab, za pomocą crona albo timera systemd.

Pokaż zawartość pliku /etc/fstab

eeeee… jak to zrobić? :frowning:

Trim jest włączony w każdej współczesnej dystrybucji i nie musisz się tym przejmować.

Na czym stanął twój problem, bo mi się nie chce całego wątku analizować, a po 2 miesiącach nie pamietam. Odczyt z nvme pod Linuksem jest ok, ale zapis bardzo wolny nawet bez szyfrowania?

Wpisz w konsoli i pokaż wynik

hdparm -Tt --direct /dev/nvme0n1

Dokładnie tak jak mówisz. Zapis fatalny.

Oto wynik Twojej komendy wykonanej jako root na szyfrowanym dysku NVMe:

Timing O_DIRECT cached reads: 4864 MB in 2.00 seconds = 2432.28 MB/sec
Timing O_DIRECT disk reads: 8938 MB in 3.00 seconds = 2979.09 MB/sec

Czy masz może wersję tej komendy na zapis bo ja tu widzę tylko READS?

EDIT: zanim wysuniesz konkluzje podaj proszę jak sprawdzić ten zapis, bo należy się do tego wyniku WAŻNE objaśnienie

Wpisz

mount /dev/nvme0n1 /mnt
dd if=/dev/zero of=/mnt/testowyplik bs=1G count=10 oflag=dsync

W tej chwili jestem obecny na tym systemie - czy aby na pewno mogę wykonać tę dwa polecenia jedno po drugim jako root?

Jeśli system jest zainstalowany na tym dysku to montowanie go możesz pominąć. Komendę która ci podałem możesz przeanalizować sam (a nawet jest to wskazane bo piszę z telefonu i mogłem zrobić literówkę). Wpisz man dd - możesz to wpisać nawet w przeglądarce internetowej jeśli lepiej będzie ci się czytać.

Dd bez pytania wykonuje co się jej poleci, nawet nadpisuje całe dyski, wiec ostrożność zalecana :wink:
Sprawdź czy możesz wykonać bez root bo nie pamietam.

Ps.
Zawsze warto sprawdzać co się przepisuje z internetu :wink:

Sprawdziłem dd – help. Twoja druga komenda wygląda na prawidłową.
Obie liniki kodu musiałem wykonać jako root.
Rzeczywiście po pierwszej komendzie wyskoczył komunikat w terminalu, że jest już zamontowane.
Natomiast rezultat drugiej Twojej komendy jest następujący:

10+0 przeczytanych rekordów
10+0 zapisanych rekordów
10737418240 bytes (11 GB, 10 GiB) copied, 10,5529 s, 1,0 GB/s

Na wiki archa widzę informację, że dyski Samsunga powodowały jakieś błędy zapisu w starszych kernelach… Chyba to ślepa uliczka, ale spróbuj dodać parametr kernela

nvme_core.default_ps_max_latency_us=5500

Podczas uruchamiania, na etapie wyboru systemu (grub), wciśnij klawisz [e], odszukaj lini wyglądającej mniej więcej tak (w twoim wypadku może się trochę różnić, ale zaczyna się od słowa linux) i na końcu dopisz ten parametr

linux /boot/vmlinuz-linux root=UUID=978e3e81-8048-4ae1-8a06-aa727458e8ff quiet splash nvme_core.default_ps_max_latency_us=5500

ps.
A ja tutaj wzywam na ratunek guru @marcin82, bo sprawa mnie przerasta, ale rozwiązanie mnie ciekawi, gdyż sam się przymierzam od dłuższego czasu do zakupu takiego dysku.

Dziękuję za pomoc, jak zwykle niezawodny jesteś @anon741072
Instrukcję wykonam najszybciej jak będę mógł. Obecnie pracuję nad czymś innym i nie mogę w tej chwili resetować kompa.

Teraz jest to mój jedyny system operacyjny zatem nie mam możliwości wyboru innego, a klawisz “[e]” jest dla mnie zagadką :frowning: gdzie się znajduje?

Na klawiaturze :wink: Po prostu po jego wciśnięciu grub przełączy się w tryb edycji danego wpisu. Jest to edycja jednorazowa, po kolejnym zresetowaniu komputera konfiguracja wróci do normalnej.

Kolego, ale na klawiaturze nie ma klawisza “[e]” jest natomiast klawisz “e” .
Może o ten Tobie chodziło, a napisałeś tak aby wygodnie skopiować i aby raki noobek jak ja skumał bazę.

Tak, może cię to wprowadziło w błąd :smiley: Miało to być wizualne przedstawienie klawisza klawiatury :smiley:

Nic nie szkodzi. Jesteśmy na tyle potężnymi mózgami że obliczyliśmy lokalizację tego znaku hehe :wink:

Pamiętaj jednak, że to 17.2 Mint. Kernel 5 cośtam.

Wiem właśnie, dlatego napisałem, że to raczej ślepa uliczka. Poczekajmy na Marcina, może on coś konkretnego znajdzie.