Názory k článku
Vylepšený NTFSPLUS umí TRIM

Super, tesim sa. NTFS3 je pri rotacnych diskoch extremne pomaly a ma rozne bugy.

Já také s projektem držím palce.. a těším se.

NTFS3 kernelový modul nepoužívám, párkrát mě to vypeklo a navíc je to ve většině distribucí minimálně zakázáno přesně z těchhle důvodů.
Klasický FUSE NTFS-3G je relativně spolehlivý, ale je míň efektivní a má vyšší zatížení CPU.
Mám koupený i komerční NTFS od Paragonu, který je rychlý a na rozdíl od NTFS3 podporuje žurnálování. Pořád ho vyvíjí, ale krom samotné ceny, má nevýhodu i v tom, že nové verze jsou v podstatě jen na vyžádání a člověk musí řešit DKMS a okno nějakých podporovaných kernelů (typicky LTS jsou v pohodě).

Takže za mě tu rozhodně prostor je. NTFS je stále poměrně důležitý systém pro interoperabilitu mezi různými systémy.. (častokrát je to nejlepší pragmatická volba pro sdílení disku mezi Win, Linuxem a MacOS).

Já si zas pamatuju ntfs-3g jako věc, přes kterou nešlo zkopírovat větší objem dat. Protože s pokračujícím kopírováním postupně exponenciálně zpomalovala... Takže třeba odzálohovat plný disk po souborech nebylo reálné.

Za mě bych řekl, že už je to roky relativně v pohodě (používám na různých strojích bez Paragonu často, a jen např. z živé CloneZilly jsem takhle odhrnul vyšší desítky TB z nějakých interních disků se zborcenými Windows někam na síť, bez toho aby se to takhle zpomalovalo).
Byť je tam určitě spousty omezení vycházející z toho, že je to přes FUSE vrstvu.
A ano existuje to dlouho a historicky tam byly nejrůznější potíže, některé na straně driveru, některé na straně FUSE.
Také, co se týká výkonu, tak staré verze řešily všechny zápisy přes 4k chunky, což při určitých workloadech brutálně vytěžovalo CPU s těmi všemi cally. Změní to explicitní volba big_writes, co to zvýší až na 128k, která tomu hodně pomůže.
Setkal jsem se s různými verzemi ntfs-3g a libfuse2.xx v distribucích, některé měly ten limit zvýšený rovnou a označovaly volbu za deprecated.. mělo by stačit se podívat na man ntfs-3g.

a proc neni ta volba exFAT?

Treba proto, ze systemovy disk ve widlich musi byt NTFS. A ma to logiku - exFAT nektery veci neumi, pocinaje opravnenimi. Aneb exFAT neni filesystem, co jde racionalne nacpat vsude (podobne jako driv FAT). Uz jen kvuli bezpecnosti, zeano...

To je pravda, ale zase používat pro sdílení dat mezi macOS, Linuxem a Windows zrovna systémový oddíl Windows? Nevím, nic pro mě. :-)

Osobně za interoperabilní mezi Linuxem, macOS a Windows považuji ExFAT. Na všech plná podpora na rozdíl od NTFS.

a proc neni ta volba exFAT?

Osobně za interoperabilní mezi Linuxem, macOS a Windows považuji ExFAT. Na všech plná podpora na rozdíl od NTFS.

Máte pravdu, že pokud chcete na všech třech systémech rovnou pracovat s nějakým filesystémem a přenášet data, tak je exFAT přirozená a nejjednodušší volba.
A současný modul pro exFAT v Linuxu (mimochodem od stejného autora, který píše NTFSPLUS) je velice v pohodě.. (v porovnání s předchozími variantami přes FUSE a první verze modulu od Samsungu).

Čímž se dostávám k tomu, že při výběru filesystému určitě záleží nejen na jeho obecných vlastnostech, ale i na konkrétní implementaci v každém systému. Jak robustní je implementace, co konkrétně podporuje.
Je fakt, že třeba pro některé použití brzdí NTFS v Linuxu ta nejpoužívanější NTFS-3G FUSE varianta, byť je už roky relativně spolehlivá a podporuje zásadní vlastnosti. A jak jsem zmínil, tak osobně mám licence od Paragonu jako pro Mac, tak i Linux. Které samozřejmě nejsou svobodné implementace, ale mají za sebou dlouhý vývoj a chodí v pohodě.
Takže, co je nejlepší, si každý musí vyhodnotit sám podle svého použití.. něco jiného může být, pokud tam má někdo hromadu fotek a videí, něco jiného pokud tam má třeba image od virtuálů.

U mě konkrétně třeba vyhrálo NTFS na exFAT protože:
- sparse files (potřebuji sdílet a přenášet image disku pro virtuály atp.)
- přišlo mi sice přirozeně složitější, ale zas robustnější (žurnálování metadat, kopie důležitých struktur v záložní MFT). Svého času jsem řešil a zachraňoval data z dost různě nakopnutých FAT/exFAT disků. Byť to samozřejmě, pokud pominu nějaké hardwarové problémy, často souviselo s tím, že to někdo odpojil disk nebo vypnul zařízení dřív, než se to celé synchronizovalo. Příp. to třeba souviselo s nějakou starou implementací (exFAT FUSE pro Linux), absencí bariér atp. V tomhle ohledu kolikrát u NTFS zabral čistě replay žurnálu.
- při velkých adresářových strukturách tam můžou být mnohem rychlejší metadatové operace, protože to má narozdíl B+Tree od exFAT. (takže např. souborová synchronizace nějakých repozitářů podle metadat, offline zálohy s Resticem atp.)
- pokud se to používá v nějaké multiboot stanici třeba jako interní sdílený datový disk, tak jak už Danny zmínil, některé programy a služby ve Windows potřebují nativní snapshoty (VSS), ACL, symlinky.

29. 11. 2025, 00:07 editováno autorem komentáře

Díky za obsáhlý názor. Sparse files určitě smysl dávají, to je na ExFat nemožné. Žurnálování je určitě věc kterou zvážit, osobně na interoperabilní disk zase nekladu tak vysoké nároky (operace bývají pod dozorem), ale každý může potřebovat přenášet jiné typy dat.

Tedy nic proti, každý má jiný způsob využití a pokud si platíte profi variantu NTFS, která je výkonnější, tak chápu, že dáváte tomuto FS přednost.

Situace kolem NTFS driveru v linuxu se zase posunula. NTFS3 měl být velká naděje a ten poslední, ale pak se asi ukázalo, že to spíš umřelo. Namjae Jeon je asi dobrá volba pro linux kernel, protože už se předvedl u EXFAT a pro potřeby NTFS má za sebou asi zaměstnavatele a use case. Z pohledu linuxu je to trochu taková delikátní situace, proč máme každých pár let nový driver pro stejnou věc? NTFS3 měl být maintainován ze strany firmy, Paragon, to obvykle bývá záruka na dost let, že někdo bude řešit bugy a brát patches atd. Tohle byl asi nakonec problém, který motivoval k radikálnějšímu kroku, a to přinést nový driver, a hlavně aktivního maintainera.

Doufám, že se to vyřeší a pro koncového uživatele nebude rozdíl navenek, ale v kernelu se pojede podle obvyklých standardů a požadavků na dlouhodobou správu. U filesystémů není žádný arbitr, který by rozhodl co ano a co ne, závisí to spíš na zpětné vazbě a nutnosti to komentovat v mailu, že to někomu opravdu pomůže. Zatím to pro ntfsplus vypadá dobře, je to spíš věc procesu a jak to zaonačit s už existujícím NTFS3, ale to jsou detaily. Za mě je to otázka interoperability linuxu a windows a NTFS se nedá jednoduše ignorovat, takže dobrý driver je ve výsledku plus.

Snad se pletu, ale obráceně podpora filesystémů funguje ještě hůř. Chtěl jsem ve Win10 připojit něco s EXT3 a byla to pěkná "bažina". Přitom v XPčkách s tím nebyl takový problém a stačil na to třeba plugin v Total Commanderu.

V podstatě se mi nepodařilo najít FS, který by spolehlivě a efektivně pracoval v Lin i Win.

Máte s připojováním souborových systémů (ext2/3/4, btrfs, xfs, zfs, ...) do Win lepší zkušenost?

ext2 do Windows jsem kdysi měl, ale to není moc cesta - jen ten seznam FS je rozsáhlý, k tomu přidejte LVM...
A naopak, z Linuxu si se Storage Spaces taky moc neužijete. Dynamické disky Windows nějak jdou z Linuxu, ale ty jsou na ústupu kvůli EFI.
Jediné, co spolehlivě na dual-boot stroji funguje, je sdílená partition s rozumným FS, nejlépe exFAT, tomu každý rozumí velmi dobře. NTFS následuje, ale pro zápis v macOS potřebujete placenou podporu.
Takže u externích disků skončíte nejspíš taky u exFAT.

Ještě jsem zapomněl na WSL - tím by měl být přístup na ext4 přímo nativní.
Všechno má své ale - WSL třeba nelze použít současně s cestovními profily. A taky to není úplně pro BFU.

Mna tu vzdy fascinuju problemy ktore ludia este dnes maju. Myslel som ze niektore sa proste vytratili v case.
Ak to chcete lokalne tak nejaka forma FAT ak chcete naozaj nieco robit a je to dolezite tak externe NASko s automatickym zalohovanim. Tam je uplne jedno aky FS mate.

Právě že nestačí "nejaka forma FAT "
FAT32 má problém s velikostí souborů.
exFAT problém s kompatibilitou se starými Win

vFAT, uvFAT, FAT32+ a další mají slabou podporu a narazíte třeba na problémy s dlouhými názvy souborů a kódováním nábodeníček.

Sambou řeším základní propojení. Ale pro některé use case by se hodilo mít použitelný FS pro Win(xp..11) i Lin. A ten jsem nenašel.

Když se hodí přes palubu staré Win tak exFAT je asi nejlepší varianta. Ale já ty staré Win hodit přes palubu nechci a v současném setu ani nemůžu.

Spravne chapem ze starymi win myslis XP? Ak ano nativne exFAT nevedia ale MS pre XP/2K3 vydal driver, hladaj KB955704...

Už jsem tu na něj několikrát postoval odkaz:
https://archive.org/download/winxp-exfat-driver

Ale byly s ním v XP problémy.

Tak záleží, co přesně od toho chcete..

A předesílám, že připojování ZFS bych rovnou vzdal, pokud se nebavíme o nějakém specifickém, kontrolovaném recovery (Klennet atp.). Když už bych nutně potřeboval přístup, tak bych si spustil v Hyper-V celou Linuxovou distribuci (nebo FreeBSD) se stejnou minor verzí ZFS modulu (např. 2.3). Pak přesměroval do VM všechny disky, kde ten daný FS je, opatrně naimportoval pool, připojil a vysdílel ven přes Sambu.

V rychlosti:
- ten plugin do TC funguje pořád, ale je jen RO a má spousty omezení.
- od stejné firmy je i Reader, který to připojí FS jako písmenko, ale třeba XFS už je za peníze.
- Paragon má funkční komerční driver pro ext4, s tím funguje v pohodě včetně třeba základního LVM (míněno bez složitějších dm targetů). Btrfs, XFS pak jen pro čtení. Kdybych chtěl něco pro běžnou práci, řešil bych to nejspíš takhle.
- open source ext2fsd mi nikdy pořádně nefungoval, bylo tam spousty potíží. Bral bych to jen jako totální nouzovku (na čistý fs v R/O režimu bez žurnálu). Od původního projektu existuje fork, který spousty věcí vylepšil, dokonce je to i podepsané, ale dlouho jsem to netestoval.

Co funguje relativně v pohodě a doporučil bych pro občasný přístup k souborům, je WSL2.
https://learn.microsoft.com/en-us/windows/wsl/wsl2-mount-disk

Ve WSL2 je kernel (6.6 aktuálně) přímo se standardními moduly (ext4, xfs, btrfs.. atp.), není problém připojit LVM atd. Podporuje to všechny fíčury těch FS jako normální Linux.. není nutné mít strach z toho, co autor nějakého Windows ovladače pro FS implementoval a co už ne.

Jediné zásadnější omezení je, že se tam musí poslat celý disk, tzn. pokud má člověk třeba multiboot s Windows na jednom disku, nejde to.
Připojení pak např. přes:
wsl.exe --mount \\.\PHYSICALDRIVE2 --bare
(parametr --bare zařídí, že se to automaticky nemountuje)
následně pak už běžící wsl instanci připojit přes mount do složky s libovolnými parametry (např. subvol pro Btrfs atp.).
Pro opakované použití se to dá samozřejmě celé naskriptovat.

Na data z WSL instance se pak dá přistupovat z Windows přes speciální UNC cesty (je tam 9P/plan9 driver).
např. \\wsl.localhos­t\FedoraLinux-42\mnt\tmp

Poslední dvě poznámky. Normálně to používá unixová práva, takže ve WSL musí být uživatel se správným UID/GID, nebo je potřeba otevřít práva pro všechny (sudo chmod normálně funguje).
Logicky, to chce pak také nějak regulérně ukončit a odpojit FS.

Díky za dlouhý popis, s užitečnými postupy.

Měl jsem to ale napsat přesněji, že: "hledám souborový systém, který nebude mít nějaká zásadní omezení a bude fungovat dobře pod Win(XP..11) i pod Linuxem."

Když jsem takový hledal, tak mě ani nenapadlo, že by s tím měl být problém.

No asi není, exFAT.
Pro Windows XP to řeší KB955704.

Díky za info. S exFAT jsem měl obtíže na WinXP, kterých provozuji ještě několik desítek ve virtuálu nad Linuxem, v sandboxovaném prostředí, především za účelem spouštění několika stovek her a výukových programů, které nefungují dobře v jiné formě virtualizace/e­mulace.

Kompatibilnější je FAT32, ale tam je problém s limitem 4GB na soubor, takže třeba s image DVD je problém. O to nezmiňuji jiné nevýhody.

WSL mi v tomhle případě přijde, pro některé use case jako kanón na vrabce. Třeba pro občasné připojení externího disku... A taky to nepokrývá škálu WinXP (lépe i Win98) až Win 11.

Jestli to je opravdu takhle napříč různými verzemi systémů, tak ta data opravdu spíš sdílet po síti.

exfat pro windows xp byl jako nejaky update, google rika KB955704

Drivery exFATu jsou dohledatelné např. na https://archive.org/download/winxp-exfat-driver
ale funkčnost nebyla bez problémů.

Ano, běžné sdílení řeším SAMBou, což taky mé své problémy a v tomhle konkrétním případě jsem řešil, jaký FS použít na externí disk, abych ho mohl dobře použít pro R/W u všech Win i v Linuxu.

To není něco co bych řešil připojováním po síti, ani WSLkem.

Prostě jsem chtěl aspoň jeden jediný FS, který by standardně fungoval mezi Win(XP až 11) a Lin a takový jsem, s velkým překvapením, nenašel. Asi jsem chtěl moc :)

Ano, běžné sdílení řeším SAMBou, což taky mé své problémy a v tomhle konkrétním případě jsem řešil, jaký FS použít na externí disk, abych ho mohl dobře použít pro R/W u všech Win i v Linuxu.

V tomhle konkrétním případě (or XP) bych opravdu použil NTFS. MBR rozdělení, NTFS oddíl do 2 TiB, zarovnaný od 1 MiB (pro sichr, kvůli AF diskům, novější Windows to dělají automaticky).
To je rozhodně nejkompatibilnější volba. Na Linuxu pak přes NTFS-3G (v případě potřeby se výše zmíněným parametrem big_writes).

Díky. Nakonec jsem to tím NTFS i řešil, ale tipy na 1 MiB zarovnání a big_writes můžou pomoci.
Možná MPT a formátování řešit v těch XPčkách a tím by si s tím měly novější Win a Linux rozumět.

Kdyby z Linuxu tak by to bylo nejspíš takhle (?)

sudo parted -a optimal /dev/sdX --script \
  mklabel msdos \
  unit MiB \
  mkpart primary ntfs 1 2097152

mkfs.ntfs-3g -Q -L DATA /dev/sdX1

mount -t ntfs-3g -o big_writes,uid=1000,gid=1000 /dev/sdX1 /mnt/ntfsdisk

Já šel cestou sdílený disk je NTFS, s tím, že v dualbootu je systémový Windows NTFS, systémový Linux EXT4/BTRFS (a Mac neprovozuji), a datový disk je NTFS - s tím, že tam jsou (symlinky) vytahané adresáře z home (+ z C:\Users\) uživatelů: Dokumenty, Obrázky, Videa, Hudba, Plocha.

30. 11. 2025, 12:42 editováno autorem komentáře

Při téhle kombinaci jsem narazil na nejmenší množinu omezení.
Vitruálky samozřejmě mají svůj oblíbený filesystém - provozovat virtuálku v dualbootu jsem potřeboval jen při ladění konfigurace pro reálné železo.