Test súborových systémov NTFS/FAT

31.5.2022 08:02 | Přečteno: 2781× | linux | poslední úprava: 31.5.2022 08:02

Po vydaní predošlého článku o súborových systémoch mi bolo vytknuté, že som neotestoval súborový systém NTFS. Najprv som si myslel, že ide o trolling, ale zdá sa, že existuje prinajmenšom jeden človek, ktorý NTFS v Linuxe aspoň raz použil.

Testovací setup z minulého článku ešte stále bežal v nezmenenej zostave, pretože som na ňom debugoval spomínanú chybu jadra. Nič teda nebránilo tomu, aby som testu podrobil aj NTFS. A potom som si povedal, že keď už testujem hlúposti, môžem k nim pridať aj VFAT a exFAT, aby sme plechovku červov mali kompletnú.

Existujú v princípe tri implentácie NTFS v Linuxe. Dve z nich sú priamo v jadre (NTFS_FS a NTFS3_FS) a jedna vo FUSE (NTFS-3G). Prvá z nich (NTFS_FS) nedokáže vytvárať nové súbory, len čítať a upravovať už existujúce. Z toho dôvodu bola z testu hneď na začiatku vyradená, pretože neprešla prvým, nutným krokom (rozbalenie testovacích dát).

Než sa pozrieme na výsledky ostatných, musím poukázať na jeden problém. Hovorím v týchto blogoch o testoch súborových systémov, v skutočnosti sa ale testuje ich implementácia, nie súborový systém samotný. Dobre to je vidno na NTFS3_FS vs NTFS-3G - súborový systém je rovnaký, ale implementácie sa líšia, a to teda poriadne.

Zdá sa, že moderné súborové systémy, ktoré víťazili aj v predošlom blogu, ťažia hlavne z toho, že ich implementácie sú mladšie a dokážu teda využívať rôzne nové optimalizované volania linuxového jadra. Ext2, jfs, reiser3fs či zfs vznikli skôr než tieto jadrové API, preto výkonnostne trpia. Šanca, že niekto prekope ich starý fungujúci kód, je skôr minimálna.

Ale teraz už prejdime k výsledkom. Tabuľku s hodnotami nameranými v predošlom teste som doplnil o nové hodnoty. Jednotlivé výsledky sú ofarbené podľa pravidiel z predošlého článku - ak by boli pod mediánom, sú červené, ak nad, zelené. Samotný medián ale zostal nezmenený, vypočítaný len z výsledkov minulého testu, len z linuxových súborových systémov.

Než budem pokračovať, najrpv pár komentárov...

1. NTFS samozrejme má chkdsk, ale len vo Win, nie v linuxovom balíku sys-fs/ntfs3g.
2. VFAT zlyhal v teste bonnie, pretože testovací nástroj bonnie sa pokúšal vytvoriť súbor veľkosti 32GB, ale vfat dovoľuje maximálne 4GB.
3. exFAT zlyhal už na začiatku tým, že mu veľkosť disku (1TB) nestačila na rozbalenie testovacej vzorky. Preto nemá čas testu populate - nedokázal rozbaliť celý archív a je potom jedno, ako dlho to trvalo. Údaj v poli df used som extrapoloval - ak by dokázal rozbaliť celý archív, zabralo by to približne toľko miesta.

Pozrime sa teda, ako by si tieto súborové systémy viedli, keby dostali body podľa váh, ako boli definované v minulom článku.

Aj tu pre výpočet poslúžili ako základ predtým namerané hodnoty, aby bolo možné ich priamo porovnať s výsledkami z predošlého článku. Tak sa mohlo stať, že exFAT v teste find získal viac než maximálny počet bodov - bol v tejto operácii rýchlejší než všetky linuxové súborové systémy. Stalo sa ale aj to, že niektoré testy dopadli ešte horšie než najhorší z tých predošlých. Tým by vyšiel záporný počet bodov, čo som im milosrdne odpustil, pretože aj tak tieto štyri súborové systémy skončili horšie než medián tých ostatných (28,2 bodov).

Moje hodnotenie

V prvom rade by som sa pozastavil nad jednou anomáliou. Skoro všetky teraz testované súborové systémy dokázali rýchlejšie prehľadať celú adresárovú štruktúru (test find) než spočítať miesto, ktoré zaberá len jedna jej malá časť (test du). To je veľmi netypické, linuxové súborové systémy to mali presne naopak. Povedal by som, že rozdiel vychádza z odlišnej filozofie. Kým linuxové inody zjavne obsahujú všetky údaje potrebné k presnému spočítaniu obsadeného miesta, tabuľky FAT a MFT (NTFS) nie.

NTFS3_FS (kernel)

Jadrový ovládač NTFS3 výkonom neoslnil. Za pozornosť stojí jeho pomalosť pri prechádzaní adresárovej štruktúru (testy du a find) v porovnaní s ovládačom vo FUSE (NTFS-3G). Ako je možné, že na tom istom disku a pri tom istom spôsobe usporiadania dát (NTFS) je 22x pomalší? Práca s metadátami mu jednoducho nejde.

NTFS-3G (FUSE)

Ovládač NTFS-3G v userspace je oproti tomu jadrovému rýchlejší pri čítaní, ale vyvažuje to nižším výkonom pri zápise. Najviac to vidno pri teste dbench, kde vykázal nevídane slimačie tempo, ešte pomalšie než dovtedy najpomalší jfs. Prechádzať adresárovú štruktúru príkazom find ale dokázal rýchlejšie než doterajší šampión btrfs.

VFAT

Bradatý súborový systém VFAT, ktorého korene siahajú až do roku 1977, si vzhľadom na svoj vek neviedol až tak zle. Áno, prístupové práva sú pre neho vecou neznámou a zistiť reálne obsadené miesto na disku (test du) je vecou zenovej trpezlivosti. Ale testovacie dáta rozbalil pomerne rýchlo. Našťastie v nich nebol žiaden súbor väčší než 4GB, čo by pre VFAT bolo konečnou stanicou.

exFAT

ExFAT rieši niektoré nedostatky VFAT-u (maximálna veľkosť súboru), bohužiaľ ale tiež prináša nedostatky nové. Najhorší z nich je jednoznačne neefektivita ukladania dát. Tá je ešte o desiatky percent horšia než u VFAT-u, ktorý tiež nebol práve štíhly. Výkonostne je z týchto štyroch asi najvývaženejší, ale ruku na srdce - ak niekto siahne po FATke v Linuxe, zjavne požaduje kompatibilitu alebo jednoduchosť, nie výkon.

V ďalšej časti neuvidíte...

So súborovými systémami od Microsoftu som skončil. Toto je prvý a posledný test tohto druhu odomňa. NTFS patrí tam, kde je, do Windowsu. Tam má kvalitnú implementáciu a odvádza dobrú prácu (aspoň nikto sa nesťažuje). V Linuxe existujú lepšie a hlavne slobodnejšie alternatívy.

       

Komentáře

[pushkin]

Ano, Linuxová implementace Microsoftích souborových systémů je opravdu výkonnostně velmi pozadu. Bohužel v řadě aplikací člověku nezbývá, než se s nimi smířit - dualboot stroje se sdíleným datovým diskem, přenosné disky, které musejí být čitelné na Windows i Linuxu atp. Už kvůli tomu se jim má smysl věnovat a díky za ten test.

Jinak pokud někdo víte o nějakém ovladači, který by pod Windows 10/11 rozhýbal libovolný linuxový souborový systém, abych se mohl vyhnout NTFS, jen do mě (Ext2IFS a ext2fsd jsem samozřejmě zkoušel a nepochodil).

[AraxoN]

Mne na zdieľanie Linux/Windows odjakžive prišlo lepšie mať samostatný server/NAS a mapovať si disk cez sambu. Keď to je v nejakej lokalite s dobrým pripojením, tak sa to dá používať aj vzdialene cez VPN.

[PetebLazar]

Pokud půjde o přístup k multimediálním datům, zpracovávaným střídavě z Linuxu/Windows OS ani běžné lokální síťové řešení nemusí být svou průchodností dostatečné. Například ntb s 10GLAN je jak šafránu, zkoušel jsem 5GLAN externí USB adaptér a ten měl své maximum někde okolo 375MB/s.

[Max]

NTFS je nejlepší pro multiplatformní použití.
Další možnost je používat ext4 a ve Windows 10 připojovat přes WSL. Ale to není tak uživatelsky přívětivé.
Zdar Max

[vlk]

Vobec nesledujem ako je to teraz, ale za onej davnej doby (prve implementacie podpory NTFS v Linuxe) existoval nejaky drajver co vyuzival kniznicu ntfs.dll z Widnows cez nejake odlahcene wine... viem ze som sa s tym kedysi davno hral a vykon NTFS v Linuxe cez ten drajver bol potom velmi slusny. v jadre bola len read-only implementacia. od vtedy som ntfs uz nepotreboval, takze som to prestal riesit/sledovat.

[Semo]

Jj, a je tu o tom zmienka https://www.abclinuxu.cz/faq/souborove-systemy/ntfs-pod-linuxem#captive

Ale podla popisu to nejakym strhujucim vykonom nevynikalo.

[pushkin]

Také jsem na to teď koukal. Vypadá to, že vývoj usnul někdy v roce 2006.

[paralen]

NTFS ovladac od paragonu je obrovske sklamanie. Nepochopim ako sa v takej kvalite mohol dostat do jadra. Vykon na rotacnom disku je zalostny az nepouzitelny. Hned som sa vratil k NTFS-3G.

[PetebLazar]

Externí média (paměťové karty/SSD) využívané v DF/kamerách jsou typicky formátovány jako ExFAT.

[R]

montoval si ntfs-3g s parametrom -o big_writes? Bez neho je vykon pri zapise tragicky. Nechapem, preco to nie je zapnute automaticky.

[AraxoN]

Všetky testy, aj v predošlom blogu, boli s default parametrami. Aj pri mkfs, aj pri mountovaní.

[_]

ma takove testovani smysl?

[AraxoN]

Väčšina ľudí ten ktorý súborový systém tiež bude používať v defaultnom nastavení. Nevidím na tomto prístupe nič zlého.

[FF]

Tak to sa mylis, obzvlast az ide o ntfs tak to skoro nikto nema v deafulte, lebo vykon pri zapise je bez cachingu zalostny Btw Paragon v macOS frci ako namydleny blesk a napr. na externy disk zapise rychlejsie nez windows! Linux verzia je podla vsetkeho osekana open source verzia bez W cachingu, ale co by chcel clovek zadarmo ze?

[AraxoN]

To je možné, ale keby som mal každý jeden súborový systém študovať a ladiť, tak s týmito testami by som nebol hotový ani dodnes. Východzie nastavenia by mali byť volené tak, aby nimi človek nič nepokazil. Keď východzie nastavanie majú tragický výkon, tak to je proste zle a je to chyba toho ovládača.

[_]

Bullshit. Když si koupíš zavírací nůž, budeš také testopvat jeho řezivost v defaultním, tj. zavřeném stavu?

[AraxoN]

Defaultný stav súborového systému je nepripojený. To je analógia toho Tvojho zavretého noža. Ja som ho predtým otvoril (pripojil). Spravil som všetky potrebné kroky.

Tvoj príklad je nôž, ktorý dobre reže, len keď ho otvoríš v noci počas splnu za odriekavania zaklínadiel. Vtedy to môže byť výborný nôž, ale na stanovačku si radšej vezmem iný.

[_]

mel jsi to pripojit a korektne nastavit, novy nuz musis otevrit a nabrousit

[plostenka]

Jsi zbytecne mekky. Mel stahnout nejnovejsi patche, zkompilovat driver s experimentalnima vykonnostnima optimalizacema...

[Pocuvaj nas]

Default je tam len preto ze je to najviac otestovane a vraj nemoze dojst ku korupcii systemu pocas zapisu. Caching samozrejme nejake to rizikonesie napr. pri strate napajania. Ale z principu veci nikto ntfs nebude mat v linuxe na serveri. Vzdy su to bud externe disky alebo particia v notebooku cize mas baterku. Tak uz prestan vymyslat vyhovorky a jebni tam poriadne nastavenia ked vidis ze do teba vsetci rypu. A uvidis ten fukot.

[Pendrekama do nich❗]

supr fígl :D

[z_sk]

Koľko súborov je uložených a aká je maximálna hĺbka stromu?

Koľko inodov sa minulo pre FS?

[AraxoN]

2,6-milióna súborov v 1024 adresároch

v roote 4 adresáre, v každom z nich 256 podadresárov, v nich tie súbory, väčšinou od 2000 do 4000 v jednom podadresári

spolu 758,5GB dát

počet inodov netuším, už je to zmazané

[metazese stamezi]

Ještě prosím přidej do textu informaci o zásadní nevýhodě tohoto testovacího postupu:

Nemalá část testovaných souborových systémů byla testovaná v režimu téměř úplného zaplnění oddílu. V takových případech se souborový systém chová podstatně jinak a výsledky testu tedy zdaleka nereflektují běžný provoz, nýbrž patovou situaci, kdy dochází místo.

Každopádně díky - je to velmi poučné srovnání!

[AraxoN]

S tým nesúhlasím. Jediným problémom by mohla byť fragmentácia, ale súbory sa tam rozbalili z archívu naraz v jednej dávke, bez mazania, sekvenčne. Potom sa nejaká časť zmazala (test rm) a až potom išli syntetické benchmarky. Tie mali k dispozícii skoro polovicu disku, mnohonásobne viac, než potrebovali.

[ergovan hero]

758,5GB dat v serializovane podobe se muze v praxi (dle FS) nafouknout 1.2x-1.6x (zejm. pokud tam byly i male soubory). Tedy 910GB-1213GB. FS zpravidla od poslednich ~10% volneho mista prepinaji do rezimu "patove situace". Tzn. s nejvyssi pravdepodobnosti cast toho archivu co jsi rozbaloval byla rozbalena uz dle pravidel patove situace, tj. neprilis efektivne co se struktury tyce a take pomaleji (vyzaduje vice seekovani a cteni - i na SSD).

Proto to exFAT nerozbalil. To je zakladni indikator, ze ani ostatni FS nemely dost mista a urcite mnohe jely (alespon chvili) v rezimu patove situace nedostatku mista.

Kolik GB mista bylo uvolneno tim smazanim pred spustenim nekterych testu?

I na mem notebooku to je strasne znat - jakmile se prehoupnu pres tuto hranici (ext4, cca 91% z 240GB zaplneno), cely system jde do kytek. Stane se z&nbps;nej totalni slimak, i kdyz predtim lital jedna radost. Na serveru to bude jeste markantnejsi.

[ten samy]

vyzaduje vice seekovani a cteni - i na SSD

->

vyzaduje vice seekovani, cteni a zapisu - i na SSD

[AraxoN]

To je ten stĺpec "df used", koľko to zabralo z celého fs po rozbalení. Väčšina to zvládla do 770GB, takže sa "nafúkla" len o percento či dva, nie 20% až 60%, ako píšeš.

Pri teste "rm" sa mazal jeden z tých štyroch adresárov na najvyššej úrovni, približne štvrtina dát. Po jeho zmazaní tam ostalo zhruba 570GB dát, čiže disk bol v tej chvíli zaplnený cca na 61%.

Disk slúži na ukladanie dát, k čomu je súborový systém prostriedkom. Na všetky súborové systémy v tomto teste boli kladené rovnaké nároky, bežali na rovnakom hardvéri, žiadnemu som nenadržiaval. Ak niektorý potrebuje byť prázdny, aby mal aký-taký výkon, tak som rád, že to tento test odhalil, pretože to považujem za nežiadúcu vlastnosť. Nie všetky súborové systémy týmto trpia, viď ext4 či btrfs.

[ecce homo]

Super, diky za upresneni. Plne souhlasim, ze to tento test mel odhalit a ze to je nezadouci chovani.

Pridas tyto vsechny informace o "chovani v patove situaci" do blog postu? Jsou velmi dulezite.

[Mazanec zvědavec lívanec]

Pokud mas par minut, muzes zkusit otestovat tuto alfa verzi:

https://github.com/dubeyko/ssdfs-driver

Je to novinka, takze na produkcni nasazeni ani nahodou. Ale bylo by zajimave videt nejmodernejsi fs (co se navrhu tyce) v tech testech po boku ostatnich (a to i presto, ze to nebudes provozovat na NVMe ale na beznych SSD/HDD).

SSDFS je aspirant na zacleneni do jadra, takze ma cenu ho sledovat jiz nyni.

Co si o tom mysli ostatni?