Proč potřebujeme NTFS v jádře? Nemůže Microsoft konečně vyhodit tento absolutně zbastlený kus softwaru a třeba používat BTRFS nebo XFS?
Tak já musím disk, flash disk naformátovat na NTFS, protože když to udělám na exFAT, tak Windows doporučuje nesmysly typu, že bych měl dané médium naformátovat, ale přidat tam podporu EXT4, XFS nemohou.
Pokial tento dotaz je mysleny vazne a neni to len pokus o vtip, tak rad odpovim. Nejsem zastanca ntfs, to vubec.
Ntfs ma vybornu podporu pro implementaci extremne rychleho vyhledavani suboru cez cely fs. Vyuziva teho program Everything a pro mna je to na windows must have. (a nechapem proc to nevyuziva sam windows). Ide o MFT, ktere zadny iny oblubeny fs (ext4, btrfs, bcachefs) nema. Ani nic co by posluzilo na bleskurychle natahnuti zezamu vsetkych metadat. Nenasel sem teda ani zadny konkurencny ekvivalent k Everything pod linux ktery by fungoval bez demona alebo indexace vseobecne.
Hmm, super, rychle se v něm hledá. Jo, to i na mém XFS s SSD NVME.
- Má immutability? Ne
- Má kompresi? Ano, ale BTRFS umí mnohem lépe.
- Je odolný proti fragmentaci? Ne, např. EXT4 a XFS ano.
- Je rychlý (Např. čtení/zápis hromady malých souborů) Ne, XFS toto zvládá lépe a vlastně i EXT4.
- Umí snapshoty? Jo, ale je to k ničemu, protože obnova snapshotu je pomalá, zatímco BTRFS toto zvládá lépe.
Eh, takže... co je super na NTFS? NIC?!
Hmm tak tento výčet zní jako, že když vezmeme všechny FS z Linuxu a zkombinujeme je dohromady (což je naprostá utopie) bude mít Linux konečně lepší FS jak Windows, good job ;)
BTW NTFS je historicky opravdu starý (1993) FS a stále je využívaný! Wokna mají i ReFS (2012) který je novější, ale nevím jak hodně se využívá...
MFT je dvojsecna zbran (ma problem s fragmentaciou, malymi subormi, velkym poctom suborov, atd).
Suborove filesystemy ako zfs alebo btrfs optimalizovali po inej osi: metadata vedia dynamicky rast (su alokovane rovnako ako extenty pre subory, ale z ineho poolu), vedia metadata dat na separatne zariadenie ("special vdev" v zfs), alebo mat ich ukladat s definovanou redundanciou / paritou na definovany pocet zariadeni. Potom maju tunables, kam ukladat niektore metadata: ci ich alokovat separatne, alebo ich ukladat priamo v dentry (niektore xattr mozu obsahovat objemne data, ale zase acl je tiez xattr a to chceme mat blizko...). Alebo naopak tunables, ze maju ukladat bloky do urcitej velkosti spolu s metadatami (zfs -- takze v poole s tiered storage vie davat metadata a male bloky na rychlejsi storage a velke bloky na pomalsi).
No a indexovanie je tak ci tak nutnost. Dnes pouzivatela nezaujima len nazov suboru, ale aj jeho obsah, ktory este k tomu treba aj parsovat usermode a idealne sandboxovanym parserom (pdf, docx, atd). Na toto ma windows tiez separatny service.
MFT má prealokovaný prostor MFT Zone, ze kterého alokuje. Metadata se ukládají v MFT, a extended attributes i soubory do jisté velikosti (1kB minus file information, typicky cca 900 bytů) zůstávají přímo v MFT recordu. Mimochodem, pokud dojde k fragmentaci MFT, lze ji defragmentovat pomocí API na živém FS, tak jako skoro cokoliv jiného.
Ukládání metadat na separátní zařízení NTFS by default neumí, ale asi by se to dalo udělat pomocí filter driveru, který by operace směřující na MFT přesměroval. Použil byste to někdy? Já ne, a nejspíš skoro nikdo ne.
Pokud jde o tunables, tak to je velmi dvojsečné. Je fajn pokud něco *můžete* nastavit, ale hrozné pokud to nastavovat *musíte*. Znám řadu odstrašujících příkladů toho *musíte*, většinou v unixových prostředích.
> Použil byste to někdy? Já ne, a nejspíš skoro nikdo ne.
Ano, pouzivam. Na NAS so zfs mam special device z ssd (mirror), samotny datovy vdev je potom rotujuca hrdza.
Podobne Synology ponuka podobnu funkcnost nad btrfs jednym checkboxom v nastaveniach ("Pin all Btrfs metadata to SSD cache"). Trufam si povedat, ze velke percento z tych, co maju v Synology SSD cache maju zaskrtnutu aj tuto volbu.
Mně teda přijde, že to indexaci dělá, sami to píšou (a Wikipedie taky): When Everything first runs, it creates an index of the names of every file and folder on all NTFS and ReFS volumes on the system from file metadata, in the case of NTFS from the NTFS Master File Table.
Na Linuxu mi většinou úplně stačí fd, zkoušel jsi ho?
20. 4. 2026, 05:57 editováno autorem komentáře
JJ jsem nikdo... NTFS používám i v Clonezille na ukládání image, nevím proč o ní lžou, že je založena na linuxové distribuci, když teda tvrdíte, že NTFS je jen pod Windows. No a co, že je rok 2026? To znamená, že přestaneme číst knížky a budeme používat pro čtení jen monitory nebo displeje mobilů, či čtečky ebooků?
Možná byste mohl přesvědčit naše vedení, že je potřeba vyházet stávající linky a předělat je adekvátně roku 2026. Možná by na to stačilo jen pár let a pár vyšších desítek miliónů. Asi máte pravdu. Těch pár 486 už by to vyměnit chtělo. Ty NTFS opravdu neumí.
20. 4. 2026, 13:01 editováno autorem komentáře
Z mě je pěkné třeba to, že NTFS má už víc než čtvrt století defragmentační API. User mode aplikace přes API načte alokační informace, a může přesouvat bloky na FS jak chce, samozřejmě již na úrovni API transakčně. To znamená, že jde provést defrag za běhu. Potom mi přijde pěkná kombinace ACL, žurnálování, transakčního zpracování, komprese, šifrování, sparse files a kvót v jednom FS. Jasně, skvělé to bylo tak před dvaceti lety, kdy se na Linuxu řešilo to že jeden FS umí žurnálovat, další kompresi a třetí má funkční fsck :), ale i dnes je NTFS velmi slušný standard. Když jsem u toho fsck, tak chkdsk umí například multithreadovou kontrolu a opravu FS, což je výrazné zrychlení.