Odpověď na názor

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...