John Groves famfs pirmoreiz parādīja Linux kodola izstrādātājiem 2024. gadā. Šī gada 20. jūlijā LWN par to publicēja rakstu ar virsrakstu “Merging famfs?”. Jautājuma zīme tur joprojām ir vietā. Failu sistēma, kas ļauj vairākiem serveriem lasīt vienu un to pašu datu kopu no kopīgas CXL atmiņas, kodolā nav iekļauta.
Kods pa to laiku vairs nav mazs eksperiments. Kodola daļa ir aptuveni 1000 rindu, lietotāja telpas daļa aptuveni 5000. Groves strādā pie atmiņas ražotāja, kas šo tehnoloģiju pārdod. famfs jau tagad nonāk pie klientiem kā ārpuskodola modulis.
Ko famfs dara
CXL ļauj vairākiem serveriem piekļūt vienam un tam pašam fiziskās atmiņas apgabalam. Problēma ir tā, ka programmas neprot runāt ar DAX ierīcēm tieši. Tās prot mmap(). famfs pārvērš kopīgo atmiņu par failiem, ko var atvērt un iemapot, tāpēc Apache Arrow vai Ray var strādāt ar simtiem gigabaitu lielām datu kopām bez kopēšanas uz katru mezglu atsevišķi.
Bez tā katrs mezgls ielādē savu datu kopijas eksemplāru. Analītikas klasterī ar desmit serveriem un 200 GB datu kopu tas nozīmē divus terabaitus atmiņas tur, kur pietiktu ar 200 GB. Ar CXL kopni datu kopa atrodas vienuviet, katrs serveris to iemapo tikai lasīšanai. Tieši tāpēc famfs ir veidota galvenokārt lasīšanai: rakstīšanas koordinēšana starp resursdatoriem ir tā daļa, kas prasa vislielāko sarežģītību.
Tā nav parasta failu sistēma. Faili tiek iedalīti iepriekš, nevis izaug rakstīšanas laikā. Granularitāte ir 2 MB ar lielo lapu izlīdzināšanu. Dzēšanas nav vispār. Metadati glabājas tikai pievienojamā žurnālā. Inode tabulas nav. Kā LWN to formulēja jau 2024. gadā, tā ir failu sistēma, bet patiesībā tā ir atmiņa, nevis krātuve.
Trīs pārstrādes pēc kodola komandas lūguma
Pirmajā versijā famfs bija atsevišķa failu sistēma kodolā. LSFMM+BPF sanāksmē izstrādātāji ieteica to pārlikt uz FUSE. Groves sākumā pretojās, tomēr 2025. gadā atgriezās ar FUSE implementāciju. Tā pievieno divas operācijas. GET_FMAP atgriež faila atmiņas karti brīdī, kad fails tiek atvērts, tāpēc kodols pēc tam lapu kļūdas atrisina pats, neejot atpakaļ uz lietotāja telpu. GET_DAXDEV pastāsta, uz kurām CXL ierīcēm atmiņa atrodas. Tieši GET_FMAP ļauj famfs strādāt atmiņas ātrumā, nevis FUSE ātrumā.
Šā gada marta beigās Groves publicēja desmito versiju un uzskatīja to par gatavu iekļaušanai. Tad iebilda trīs cilvēki.
Joanne Koong no FUSE izstrādes puses ierosināja famfs specifisko loģiku pārlikt uz BPF programmu. Arguments: saskarne kļūtu paplašināma, to varētu atjaunināt ārpus kodola laidienu grafika. Miklos Szeredi, kas uztur FUSE, tam piekrita un norādīja, ka labprāt izvairītos no famfs specifiskas FUSE saskarnes, ja vien iespējams. Christoph Hellwig iebilda pret pašreizējās versijas iekļaušanu vispār. Pamatojums: vienlaikus apspriestās pieejas rāda, ka vienota saskarne vēl nav izdomāta līdz galam.
Groves pret kārtējo pārrakstīšanu iebilda asi. Pašreizējā versija atbilst tam, ko kodola izstrādātāji paši bija lūguši iepriekš. Kods jau strādā pie lietotājiem.
Groves izteica cerību, ka nepaies vēl viens gads, līdz famfs kaut kādā formā nonāks kodolā.
Tā LWN apraksta sesijas noslēgumu 2026. gada LSFMM+BPF failu sistēmu sadaļā.
Kāpēc kodola komanda vilcinās
famfs gadījums sakrīt ar plašāku sarunu. Tajā pašā sanāksmē Amir Goldstein apsprieda savu dokumentācijas priekšlikumu par to, pēc kādiem kritērijiem jaunas failu sistēmas vispār uzņem kodolā. Katra jauna failu sistēma nozīmē uzturēšanas slogu uz gadu desmitiem. famfs turklāt prasa izmaiņas FUSE saskarnē, ko lieto visi pārējie FUSE lietotāji.
Fundamentālu iebildumu pret FUSE pieeju 2025. gadā nebija. Strīds ir par to, kur konkrētā loģika dzīvo: FUSE protokolā vai BPF programmā, ko var mainīt bez kodola laidiena.
Konkurents jau mēra ātrumu
Kamēr famfs gaida, parādījās otra pieeja. DAXFS, ko izstrādā Multikernel Technologies kopā ar Kalifornijas Universitātes Santakrusas pētniekiem, risina to pašu uzdevumu bez viena centrālā koordinatora. 2. aprīlī publicētajā arXiv rakstā autori Cong Wang, Yiwei Yang un Yusheng Zheng apraksta failu sistēmu, kurā vairāki resursdatori raksta vienlaikus, izmantojot atomāro compare-and-swap operāciju.
Skaitļi no viņu testiem uz DRAM balstītas DAX ierīces: nejaušā rakstīšana ar četriem pavedieniem un 4 KB blokiem dod 4830 MiB/s pret tmpfs 1803 MiB/s. Nejaušā lasīšana ar 64 KB blokiem dod 15 052 MiB/s pret 12 800 MiB/s. Vairāku resursdatoru tests gan notika QEMU emulētā CXL 3.0 vidē, nevis uz reālas aparatūras. Testa stends bija divu ligzdu Intel Xeon ar 48 kodoliem un 512 GB DDR5.
Atšķirība no famfs ir principiāla. famfs ir plāns kartēšanas slānis virs iepriekš iedalītiem failiem ar vienu galveno mezglu, klienti pēc noklusējuma tikai lasa. DAXFS sevi pozicionē kā vispārējas nozīmes koplietojamu atmiņas failu sistēmu ar kopīgu lapu kešatmiņu starp resursdatoriem un bezbloķēšanas rakstīšanu.
Ko tas nozīmē praksē
Ja plāno CXL atmiņas kopni, kurā vairāki serveri strādā ar vienu datu kopu, gatava risinājuma kodolā šobrīd nav. famfs jāliek kā ārpuskodola modulis. Tā saskarne vēl var mainīties, jo tieši par to arī notiek strīds.
Desmitā famfs versija publicēta marta beigās. Kopš tā laika kodola pusē tā nav pakustējusies.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.