Vlákno názorů k článku
Vylepšený NTFSPLUS umí TRIM od hulvat - Super, tesim sa. NTFS3 je pri rotacnych diskoch...

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.