Názory k článku
Linux dostává podporu defragmentace oddílů typu exFAT

" Do linuxového jádra se s ní v rámci kernelového ovladače pro exFAT dostává podpora defragmentace těchto oddílů, s novým nástrojem defrag.exfat."

To zni jako nesmysl, exfatprogs je ciste userspace reseni. S jadrem ta defragmentace nesouvisi. Spatny preklad z anglictiny + nepochopeni kernel vs userspace a jak funguji ruzne filesystem tools jako mkfs, fsck, .... a i defrag

Hmm, i kdyz, na obranu autora, windows umi defragmentovat filesystem za behu, tedy myslenka ze by to mohlo nejak souviset s kernelem neni uplne mimo. Napada me ze tam by defragmentace (v poradi od nejmene pravdepodobneho)
1. mohla mit primou podporu v driveru filesystemu (=ze by defragmentoval sam)
2. blokove zarizeni by umoznovalo nejakou formu transakci nad mnozinou presouvanych bloku + synchronizace cache ve filesystemu - to zni dost slozite
3. nejpravdepodobnejsi mi pripada varianta postupne mazani a vytvareni souboru ve spravnem poradi + nejaka obecna podpora ve filesystemu pri vytvareni noveho souboru aby se dalo rict ze chci soubor urcite velikosti v souvislych blocich a pripadne i kde na disku by cca mohl zacinat.

Ono by stacilo IOCTL na tunelovani low level operaci nad clustery (read/write) a modifikaci FAT tabulek, s tim ze by to bylo "cache coherent", resp. driver bude seznamen s tim, co chce userspace udelat, a pak ty operace provede (ten kernel driver). Se tomu spis rika "instrumentace".

S takovymi primitivy, je pak mozne delat defragmentaci kopirovaci metodou i bez nejake vetsi nutnosti synchronizace, ackoliv bariera by se obcas hodila (ta tam imho v API uz je, to co dela prikaz sync)

16. 10. 2025, 00:44 editováno autorem komentáře

> nejpravdepodobnejsi mi pripada varianta postupne mazani a vytvareni souboru ve spravnem poradi

To zní schůdně, dokud se můžeme spolehnout z ze s tím FS nebude nikdo pracovat. Což jde proti defragmentaci za běhu…

Navrch k tomu, co píšou RDa a v6ak:
Mně by podpora defragmentace v kernelu taky určitě dávala smysl :-) Driver v kernelu zná mapování souborů na clustery a bloky. Netvrdím, že něco takového už existuje, ale dovedl bych si představit API pro user space, kde by se dalo zeptat kernelu "nakolikrát je rozfragmentovaný tenhle soubor?" a případně mu říct "defragmentuj ho". Následně by se v kernelu dalo zařídit, aby tato operace proběhla transparentně pro user space = atomicky, se zachováním transakční integrity. V nejjednodušším případě, pokud by kernel konstatoval, že má soubor nějaká aplikace otevřený, mohl by defragmentaci odmítnout s chybovým kódem "try again". Nebo by si mohl dát tu práci, a relokaci pouze "odstínit od user space". Že je soubor otevřený, to samo o sobě není problém, pokud zrovna neprobíhá čtecí nebo zápisová operace (čeká zablokované volání read/write). Dalo by se počkat na jeho dokončení, provést realokaci na disku, a případné další volání read/write pozdržet, pokud by k tomu byl důvod (což by možná ani nebyl). Read a write kopíruje data do user space. Blokující vliv by asi měl "zápis s bariérou" (třeba fsync) - ačkoli ani tohle nemusí být pravda. Detaily souvisí s uspořádáním blokové vrstvy a její vazbou na správu virtuální paměti (paging). Například operace "namapování souboru do adresního prostoru user-space procesu" by mohlo s pokusem o defragmentaci na pozadí taky zajímavě kolidovat - a i tady si dovedu představit, že by se to dalo provést "letmo" :-) prostě přesměrovat mapování stránek RAM na bloky disku ze staré alokace na novou, a jenom dohlédnout na to, aby se jakýkoli "dirty writeback" dostal do nové alokace...
Nechat tohle na kernelu mi přijde čistší, než tuto low-level činnost očekávat od user-space toolu, který používá něco jako FIBMAP nebo FIEMAP ioctl...

No, urcite by to vsehno nejak slo ale pripada mi to strasne prekombinovane, ci min veci je v kernelu tim lip. Tuhle tunu sloziteho a v praxi malo pouzvaneho kodu bych nerad videl strasit v kernelu, kdyz to muze byt v userspace.

Kazdopadne pak jsem zjistil ze existuje e4defrag ktery na ext4 umi za behu defragmentovat extenty = vola EXT4_IOC_MOVE_EXT ioctl() takze presun jednoho extentu z fragmentovaneho do defragmentovaneho je opravdu v kernelu. A zmeny jsou asi soucasti fs journalu takze je to konzistentni pokud treba prijde tvrdy reboot uprostred defragmentace.

16. 10. 2025, 14:44 editováno autorem komentáře

Více-méně takhle to funguje ve Windows. Pomocí IOCTL FSCTL_GET_VOLU­ME_BITMAP zjistíte které clustery (bloky) jsou alokované a které volné. FSCTL_GET_RET­RIEVAL_POINTERS řekne ve kterých blocích je soubor alokovaný. Adresáře a další objekty se považují za soubory. Informaci o alokaci souboru (RETRIEVAL_PO­INTERS_BUFFER) pak projdete, a pomocí FSCTL_MOVE_FILE přesunete jeden či více clusterů na nové místo. Vše z user space, transparentně a transakčně. Ty první dva FSCTL samozřejmě vracejí informaci k danému okamžiku, a v nejhorším se vám může soubor třeba prodloužit nebo přesunout pod rukama. To sice může vést k suboptimální defragmentaci, ale nikoliv k havárce.
https://learn.microsoft.com/en-us/windows/win32/fileio/defragmenting-files

Historicky tuším na NT 3.51 nějaká třetí strana přišla s defragem, který sahal přímo na struktury FS. MS se to moc nelíbilo, protože takový nástorj může snadno poškodit FS, takže v NT 4.0 přišel s defrag API. V NT 5.0 (Windows 2000) k tomu přidal i vestavěnou defrag utilitu. To defrag API původně neumělo přesouvat například na NTFS MFT, ale ta omezení postupně jedna za druhým padala.

Vyjma toho Windows mají možnost provést přímo defrag, případně analýzu stavu fragmentace. Dělá se to přes Storage Volume Provider, třída Win32_Volume, metody Defrag() a DefragAnalysis().
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/vdswmi/defrag-method-in-class-win32-volume

Ještě nad rámec bych dodal, že i oprava FS má API, konkrétně IOCTL FSCTL_INITIATE_RE­PAIR
https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_initiate_repair

Upřímně na tom oceňuji koncept i dokumentaci. A upozorňuji, že tohle tu bylo cca před čtvrt stoletím.

Proč by proboha někdo pouštěl defragmetaci na exFAT?!?

WiKi:
exFAT (Extended File Allocation Table, někdy označovaný jako FAT64) je proprietární souborový systém firmy Microsoft určený pro výměnná paměťová média (např. USB flash disk).

Defragmentace je proces přeskupení dat na pevném disku (HDD).

Defragmentace na flash paměti jen způsobuje únavu NAND buněk s omezenou životností.
Přínos nemá žádný.

Pokud potřebujete přenášet velké soubory na rotačním disku, nemáte moc multiplatformních alternativ. Přesněji řečeno v podstatě žádnou. Ano, asi to už dost dlouho není zrovna typický use-case, ale možná to někdo potřeboval.

Polák a ty jeho kraviny.
Facepalm.

Velké soubory budete kopírovat po jednom a vždy celé.
Takže vám nebude vznikat fragmentace.
Na fragmentaci trpí systémový disk Win protože neustále zapisuje spoustu souborů současně.
Potom jsem řešil fragmentaci .PST protože to je jeden velký soubor který neustále roste.
Swapfile.sys to samé.

Jestli tedy nejste tak blbý a nekopirujete dva soubory současně.

18. 10. 2025, 07:42 editováno autorem komentáře

Máte sice do značné míry pravdu, ale některé věci je dobré uvést na pravou míru.

Disclaimer: dále se bavíme o HDD, nikoliv SSD. Fragmentace souborů není problém, pokud není příliš vysoká. Pokud není FS plný na více než 80%, tak například NTFS v typickém scénáři na fragmentaci moc netrpí, protože se prostě soubory dají alokovat dostatečně souvisle. To se týká i page file a .pst files. Průšvih nastává při výrazně vyšším zaplnění disku, kdy prostě už není k dispozici příliš souvislých a dostatečně dlouhých řetězců alokačních bloků. To potom soubor může skončit jako řezanka třeba na stovce míst, což fakt není dobré. Navíc novější verze Windows (tuším od Visty?) ale provádějí jednou týdně defrag HDD na pozadí (což je umožněno kvalitní podporou I/O priorit), a tím pádem bývá fragmentace typicky zanedbatelná.

Ano, když má jeden soubor 10 fragmentů, tak to není problém. Zátěž se zvětší, ale přečíst 10 souborů není žádná práce ani pro HDD.
Ano NTFS trpí na fragmentaci mnohem méně než FAT. Ale bude to IMHO lepší logikou při ukládání. Pravidelnou údržbu lze nastavit i pro FAT32 ve WinXP. Jenže to moc nepomůže.
V praxi jsem narazil na soubory které měli 10 000 fragmentů. HDD se tvářil jako by měl přečíst 10k souborů a to je sakra náročný úkol pro HDD (80GB 4200rpm 2,5" ATA100 8MB buffer), i když četl jen jeden soubor. Defrag.exe si s tím neuměl poradit. Buď byl soubor zamknuty pro čtení (swap) a nebo moc velký (PST).
Musela se udělat offline defragmentace.
Nebo soubor ručně nakopírovat jinam, smazat, udělat defrag a pokusit se ho vrátit na disk v celku do prázdného místa. Jenže během dne přišlo 10 mailů a PST mělo zase klidně 11 fragmentů.
Ještě jsem zkoušel O&O Defrag, uměl mnohem víc než M$defrag.exe, ale platit za to že M$ něco prodělal se mi nechtělo. To bych rychle zkrachoval :-)

A proto tvrdím že defragmentace dnes nemá smysl. Úlohy které v principu vytvářejí fragmenty (swap, PST,...) se přesunuli na SSD.
Fotky a filmy na fragmenty netrpí tolik. Stačí při zápisu na disk nešahat a vše se uloží v kuse.
Disky které na to používáme (ano taky mám) mají stovky GB, SATA, NCQ, 5200rpm, 16MB buffer....
Také je dost možná rozdíl mezi exFAT a FAT32 v logice ukládání. FAT32 byl dost tragický. exFAT používám jen na flashdisky. Takže zážitek z praxe nemám. Na HDD mám NTFS.
V pohodě to přečte každé blbuntu.
Někdy si ho automaticky otevře pro zápis. Což považuji za chybu. Ale většině to zřejmě vyhovuje.

To, že vy používáte disky a souborové systémy nějakým způsobem, neznamená, že to tak musejí dělat všichni.

Kopírovat více souborů současně dává smysl třeba tehdy, když kopírujete souběžně z více zdrojů a rychlost limitují ty zdroje. Zkrátí se tím celková doba kopírování. Defragmentaci pak můžete řešit někdy později, až vás nebude tlačit čas.

Jenom bych dodal, že kopírování více souborů najednou může vést k velmi vysoké fragmentaci, ale také nemusí. Na NTFS se nové soubory (po překročení velikosti která se vejde do volného místa v bloku adresáře) typicky nealokují na hranici volného místa, takže při nárůstu velikosti více souborů najednou nevzniká absolutní řezanka. Navíc API CopyFileEx používá velké buffery a z toho plynoucí velké I/O requesty. Maximální teoretická velikost I/O requestu je 4GB, na NTFS přicházejí requesty maximální velikosti okolo 1-4MB, a na disk typicky 1MB. Kombinace těchto faktorů dokáže fragmentaci výrazně omezit ve srovnání s hypotetickou primitivní implementací vedoucí na "řezanku z bloků".

Například já tu mám několik starších disků na USB (v krabičce na mýdlo), které jsou formátované jako exFAT. Odkládám na ně dočasný archiv, například fotky během dovolené (jedna kopie na kartě, jedna v notebooku, jedna na disku; v letadle je karta v kapse, notebook v palubním zavazadle a disk v kufru). Některé z těch disků byly, žel, obdařeny SMR zápisem - a tam je výhodné mít ty soubory nefragmentované.
Nicméně zrovna defragmentace SMR HDD by byla poněkud nešikovná. ;-D