FADU FS-SSD to rozwijana architektura SSD, w której dysk ma sam obsługiwać operacje na plikach. Zamiast zamieniać każde żądanie na operacje blokowe w systemie hosta, rozwiązanie przenosi wyszukiwanie ścieżek i mapowanie plików do pamięci flash do wnętrza dysku. FADU opisuje tę obsługę jako operacje NFSv3 przesyłane standardowymi komendami NVMe.
Jak FS-SSD obsługuje pliki w dysku
W FS-SSD klient może wskazać plik po nazwie, a dysk zajmuje się jego lokalizacją i mapowaniem na pamięć flash. FADU umieszcza 21 operacji NFSv3 w standardowych komendach NVMe, bez wprowadzania nowego protokołu transportowego. Architektura ma działać przez PCIe oraz NVMe-oF, czyli NVMe przez sieć z użyciem RDMA lub TCP.
Warstwa plików wywodzi się z F2FS i została zaprojektowana razem z warstwą translacji flash (FTL), która mapuje adresy logiczne na pamięć NAND. Taki podział łączy w dysku część pracy związanej z mapowaniem plików i zarządzaniem pamięcią. FADU podaje, że metadane zajmują około 0,1% pojemności NAND, czyli około 1 GB na 1 TB, a około 95% tej pamięci DRAM może służyć jako podręczna pamięć węzłów często używanych na ścieżce dostępu.
Bezpośredni dostęp omija inną część hosta niż klient jądra
Deklaracja dostępu „bez hosta” dotyczy określonych bezpośrednich ścieżek z GPU, DPU lub karty sieciowej. Akcelerator albo urządzenie sieciowe może wysyłać komendy NVMe do dysku bez przechodzenia przez hostowy system plików. Klient montowany w jądrze systemu nadal korzysta z oprogramowania hosta i jego obciążenia.
Ta różnica ma znaczenie przy ocenie wyników: test klienta SPDK i test klienta jądra mierzą inne ścieżki dostępu. FS-SSD nie usuwa więc pracy hosta w każdym trybie.
Co mierzą wstępne wyniki FADU
W białej księdze z 12 października 2026 r. FADU podała około 460 tys. operacji na sekundę w zdalnym teście Filebench z użyciem kontrolera FC6161 Gen6 w hoście PCIe 5.0. Wynik utrzymywał się w pobliżu tej wartości, gdy przydział rdzeni serwera spadał z 16 do jednego. W porównaniu FADU tradycyjny Linux NFS-over-RDMA osiągał około 150 tys. operacji na sekundę przy 16 rdzeniach i około 40 tys. przy jednym.
Test obejmował obciążenie serwera plików z 10 tys. plików w wielopoziomowym drzewie katalogów, średnio 20 wpisami w katalogu i średnim rozmiarem pliku 128 KB. To wynik wstępny zgłoszony przez FADU, a nie niezależny pomiar. Host testowy korzystał z PCIe 5.0, więc rezultat nie pochodzi z testu na hoście PCIe 6.0.
W osobnym teście losowego I/O FADU porównała konfiguracje dla bloków 4 KB. Poniższe wartości to zgłoszone przez firmę przepustowości w MB/s:
| Konfiguracja | Losowy odczyt 4 KB (MB/s) | Losowy zapis 4 KB (MB/s) |
| F2FS na firmware blokowym | 7 850 | 3 980 |
| Ext4 na firmware blokowym | 9 120 | 4 560 |
| FS-SSD, klient jądra | 8 070 | 4 320 |
| FS-SSD, klient SPDK | 13 000 | 7 030 |
| SPDK na surowym bloku | 13 990 | 13 240 |
W tych wstępnych wynikach klient SPDK FS-SSD osiągnął około 1,43 raza większą przepustowość losowego odczytu niż Ext4 oraz około 1,54 raza większą przepustowość losowego zapisu. To obliczenia na podstawie wartości FADU. Klient jądra FS-SSD uzyskał niższą przepustowość niż Ext4 w obu tych pomiarach: 8 070 wobec 9 120 MB/s przy odczycie i 4 320 wobec 4 560 MB/s przy zapisie.
Wartość 13 240 MB/s dla losowego zapisu SPDK na surowym bloku przekracza podaną przez FADU przepustowość programowania NAND, wynoszącą około 12 GB/s. Ten wynik może nie odzwierciedlać wydajności ustalonej przy długotrwałym obciążeniu.
FADU podała też o 63% mniejsze wzmocnienie zapisu niż w przypadku hostowego F2FS przy mieszanym obciążeniu sekwencyjnym i losowym. Ten wynik prototypu uzyskano w emulatorze SSD NVMeVirt, a nie na fizycznym dysku.
Zapis z wielu hostów wymaga koordynacji
Opisana implementacja FS-SSD nie ma blokad między hostami. Gdy dwa hosty zapisują to samo miejsce, późniejszy zapis wygrywa, a klient GPU lub SPDK musi koordynować dostęp w aplikacji. Przy większej skali koordynację może prowadzić serwer metadanych pNFS. To istotne dla obciążeń współdzielących pliki: sam dostęp wielu klientów do dysku nie rozstrzyga konfliktów zapisu.
FADU opisuje uwierzytelnianie oparte na poświadczeniach wydawanych przez zewnętrzny serwer; obsługa Kerberos jest planowana. W opisie obecnej wersji wymieniono brak ACL-i i innych funkcji systemu plików. Dla kontrolera FC6161 wskazano samoszyfrowanie zgodne ze standardem TCG Opal.
Cele FADU i szacunki dla JBoF
Tom’s Hardware podał 21 października 2026 r., że FADU planuje wyniki testów na hoście Gen6 do końca pierwszego kwartału 2027 r., próbki dla partnerów w trzecim kwartale 2027 r. oraz projekt referencyjny JBoF bez hosta do końca 2027 r. JBoF to obudowa wielu dysków podłączonych bezpośrednio, bez tradycyjnego serwera w ścieżce danych. Są to cele harmonogramu FADU.
Dla proponowanej architektury JBoF FADU szacuje około 42% niższe zużycie energii i około 57% niższy koszt na serwer z 16 dyskami. Model firmy zakłada także około 1,7 raza większą gęstość w szafie oraz około 60% niższy całkowity koszt posiadania w perspektywie pięciu lat. To prognozy modelowe, nie zmierzone wyniki działania gotowego systemu.