Najmocniejszym dowodem w tym wątku źródłowym nie jest zrzut ekranu z transferem 600 MB/s w aplikacji Files, lecz późniejszy test bezpośredniego dostępu do pamięci masowej. Użytkownik, u którego kopiowanie w interfejsie WebUI ZimaOS utrzymywało się na poziomie około 600–650 MB/s, zmierzył około 2,3 GB/s przy bezpośrednim zapisie za pomocą dd oraz około 2,2 GB/s przy zapisie za pomocą fio. Wyklucza to ogólnosystemowe wyjaśnienie, zgodnie z którym „NVMe jest ograniczone do SATA III” na tym komputerze.
Bardziej uzasadniony wniosek jest taki, że niska wartość dotyczyła wewnętrznego procesu kopiowania w aplikacji Files albo wynikała z charakterystyki obciążenia podczas kopiowania, takiej jak metadane, CoW w systemie plików Btrfs, buforowanie lub ograniczenia pojedynczego wątku — a nie z samej fizycznej ścieżki NVMe.
Źródło odtworzyło ograniczenie przy użyciu kilku ścieżek kopiowania
Dave zgłosił podobne zachowanie przy kopiowaniu z pojedynczego NVMe na NVMe, z NVMe na RAID0, z RAID0 na pojedyncze NVMe oraz w połączeniach 10GbE. Inny użytkownik wspomniał później, że kopiowanie z systemu Windows do ZimaOS przez SMB mogło osiągać pełną prędkość 10GbE, podczas gdy wewnętrzne kopiowanie w aplikacji Files nadal utrzymywało się na poziomie około 650 MB/s.
Bezpośredni zapis za pomocą dd osiągnął około 2,3 GB/s
W źródle użyto polecenia dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress i uzyskano wynik bliski 2,3 GB/s — znacznie wyższy od praktycznej przepustowości SATA III.
fio również osiągnęło około 2,2 GB/s
Uruchomienie fio opisane w źródle wykazało zapis na poziomie około 2163 MiB/s / 2268 MB/s. Mimo że wybrany synchroniczny mechanizm skutecznie ograniczał głębokość kolejki do jednego, wynik nadal dowodził, że stos pamięci masowej mógł osiągać przepustowość kilkukrotnie wyższą niż podczas kopiowania w aplikacji Files.
Do wyniku odczytu dd ze źródła należy podchodzić ostrożnie
W źródle zmierzono również około 3,0 GB/s podczas odczytu świeżo zapisanego pliku testowego do /dev/null. Ponieważ ten odczyt nie używał jawnie bezpośredniego wejścia-wyjścia ani opróżniania pamięci podręcznej stron, na wynik mogło wpłynąć buforowanie.
Niskie ogólne użycie CPU nie wyklucza ograniczenia pojedynczego wątku
Proces kopiowania w przestrzeni użytkownika może całkowicie obciążać jeden rdzeń, podczas gdy całkowite użycie CPU pozostaje umiarkowane w systemie z wieloma rdzeniami. Podczas wolnego kopiowania w aplikacji Files monitoruj użycie CPU przez poszczególne wątki oraz wykorzystanie dysku.
Porównaj ten sam duży plik w interfejsie CLI i aplikacji Files
Użyj tego samego źródła, miejsca docelowego i dużego pliku testowego podczas kopiowania w aplikacji Files oraz z poziomu CLI, a następnie porównaj wyniki z jednorazowym testem bezpośredniego wejścia-wyjścia. Pozwoli to oddzielić narzut kopiowania interfejsu lub backendu od rzeczywistych możliwości urządzenia.
Liczba plików i metadane Btrfs mogą zmienić rzeczywistą prędkość kopiowania
Tysiące małych plików wymagają wielokrotnych operacji na metadanych, a mechanizm copy-on-write systemu Btrfs może zmienić koszt kopiowania wewnętrznego.
Nie określaj tego jako uniwersalnego, obecnego ograniczenia ZimaOS
Źródło dostarcza mocnych dowodów na historyczne ograniczenie wewnętrznego kopiowania w aplikacji Files na wielu systemach. Nie dowodzi jednak, że obecny ZimaOS 1.7.1 nadal ma dokładnie taki sam limit przy każdej konfiguracji sprzętu i systemu plików.
Kopiowanie wewnętrzne może jednocześnie odczytywać i zapisywać te same dane
Jeśli źródło i miejsce docelowe znajdują się na tym samym fizycznym dysku NVMe lub w tej samej puli RAID, dysk musi jednocześnie obsługiwać odczyty i zapisy. Widocznej przepustowości kopiowania nie można więc porównywać z jednokierunkowym testem sekwencyjnego zapisu.
Przed porównaniem wyników zapisz fizyczne urządzenia źródłowe i docelowe. „Kopiowanie wewnętrzne” opisuje ścieżkę programową, a niekoniecznie dwa niezależne dyski SSD.
Przed porównaniem wartości marketingowych sprawdź szerokość i generację łącza PCIe
Wydajność zaawansowanego dysku NVMe może być ograniczona przez łącze PCIe x1/x2, starszą generację, współdzielenie linii przez chipset lub sposób podłączenia gniazda na danej platformie, inny niż sugeruje fizyczny rozmiar złącza. Surowy test osiągający ponad 2 GB/s już wyklucza limit 600 MB/s, ale wynik może nadal być niższy od maksymalnej wydajności dysku podawanej dla komputerów stacjonarnych z uzasadnionych przyczyn związanych z topologią.
Długotrwałe kopiowanie może uruchomić ograniczenia termiczne dysku SSD lub pamięci podręcznej SLC
Krótkie testy i długie kopiowanie plików obciążają dyski SSD w różny sposób. Dysk może początkowo działać bardzo szybko, a następnie zwolnić po zapełnieniu pamięci podręcznej pseudo-SLC lub wzroście temperatury. Przed przypisaniem każdego spadku wydajności aplikacji Files monitoruj temperaturę NVMe i utrzymującą się przepustowość przez odpowiednio długi czas.
Pamięć podręczna stron może sprawić, że niektóre testy będą wyglądać na szybsze niż samo urządzenie
Bezpośredni wynik zapisu ze źródła jest mocnym dowodem, ponieważ użyto w nim bezpośredniego wejścia-wyjścia. Na testy odczytu wykonywane natychmiast po zapisie może wpływać pamięć podręczna, chyba że test jawnie ją omija.
Aby uzyskać powtarzalne porównania, użyj konfiguracji testu, która określa, czy włączone jest bezpośrednie wejście-wyjście, i zadbaj o odpowiednio duży plik testowy, aby ograniczyć zniekształcenia wynikające z buforowania.
Przetestuj ponownie obecny proces kopiowania w aplikacji Files, zanim uznasz 600 MB/s za stały limit produktu
Wątek obejmuje wersje ZimaOS starsze od obecnego wydania. Jeśli aplikacja Files nadal wydaje się dziś ograniczona, odtwórz test z tym samym dużym plikiem, tym samym źródłem i miejscem docelowym oraz aktualnym porównaniem z CLI i bezpośrednim wejściem-wyjściem. Dostarczy to użytecznych dowodów zamiast bezterminowo powielać dawny limit liczbowy.
Często zadawane pytania dotyczące prędkości NVMe
Czy źródło udowodniło, że ZimaOS ogranicza NVMe do prędkości SATA?
Nie. Bezpośrednie zapisy za pomocą dd i fio przekroczyły 2 GB/s na tym samym systemie.
Co, według źródła, było najbardziej prawdopodobną przyczyną?
Wewnętrzny proces kopiowania WebUI/Menedżera plików lub narzut związany z obciążeniem, a nie sam dysk NVMe.
Czy wynik odczytu dd świeżo zapisanego pliku należy traktować jako czystą prędkość dysku?
Niekoniecznie. Bez bezpośredniego wejścia-wyjścia podczas odczytu i kontroli pamięci podręcznej na wynik może wpływać pamięć podręczna stron.
