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

[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.

[MakeIranBombedAgain❗]

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?