Vlákno názorů k článku
Linux dostává podporu defragmentace oddílů typu exFAT
od fanoush - " Do linuxového jádra se s ní v...
-
" 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
-
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_VOLUME_BITMAP zjistíte které clustery (bloky) jsou alokované a které volné. FSCTL_GET_RETRIEVAL_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_POINTERS_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-filesHistoricky 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-volumeJeště nad rámec bych dodal, že i oprava FS má API, konkrétně IOCTL FSCTL_INITIATE_REPAIR
https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_initiate_repairUpřímně na tom oceňuji koncept i dokumentaci. A upozorňuji, že tohle tu bylo cca před čtvrt stoletím.
