Názory k článku Defragmentace disků v Linuxu

filefrag je dle všeho poměrně běžná součást e2fsprogs.

Jestli je to od e2fsprogs, jak to muze spolehlive merit fragmentaci jinych FS?

Více mě ale zajímá to, jak defrag zjistí počet fragmentů souboru - pokud vím, na úrovni Linux VFS neexistuje žádná rutina, na základě které by se to dalo deterministicky zjistit. Bojím se toho, že defrag pouze určitým způsobem odhaduje počet fragmentů porovnáním velikosti souboru, času O_DIRECT přečtení souboru a rychlosti sekvenčního čtení disku (hdparm -tT --direct, pokud chcete změřit svůj disk). Budu rád, pokud mi toto někdo vyvrátí.

Mno, já si zkusmo zbastlil tohle:

#include <stdio.h>
#include <linux/fs.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>

int main(int argc, char **argv)
{
    int fd=0, block, block_size, block_position, fragment_size=0, last_block_position, fragments=1;
    struct stat st;
    if (argc < 2)
    {
	printf("Enter a file name.\n");
	exit(EXIT_FAILURE);
    }
    printf("File: '%s'\n", argv[1]);
    fd = open(argv[1], O_RDONLY);
    if(fd==-1)
    {
	perror(argv[1]);
	exit(EXIT_FAILURE);
    }
    if (stat(argv[1], &st) == -1) 
    {
	perror("stat");
	exit(EXIT_FAILURE);
    }
    if (ioctl(fd, FIGETBSZ, &block_size) == -1)
    {
	perror("ioctl");
	exit(EXIT_FAILURE);	
    }
    printf("File size: %d (%d blocks, a block has %d bytes)\n", (int)st.st_size, 1+((int)st.st_size/block_size), (int)block_size);

    for (block=0; block<=st.st_size/block_size; block++)
    {
	last_block_position = block_position;
	block_position = block;
	if (ioctl(fd, FIBMAP, &block_position) == -1)
	{
	    perror("ioctl");
	    exit(EXIT_FAILURE);	
	}
	/* printf("%d: %d\n", block, block_position); */
	if (fragment_size > 0 && block_position != last_block_position+1)
	{
	    printf("A fragment (%d blocks) ends at block %d\n", fragment_size, block);
	    fragment_size = 0;
	    fragments++;
	}
	else
	{
	    fragment_size++;	    
	}
    }
    printf("Total: The file has %d fragments with average size of %.1f blocks each.\n", fragments, (1+st.st_size/block_size)/(double)fragments);
    exit(0);    
}

Je to "narychlo zprasené" (jsou tři ráno ;-)), ale zdá se mi, že to funguje. :-) (A nekamenovat za formu, prosím, Cčko neumím. ;-))

Ja se s tim patlal stylem vyklopit na jinej hdd a z5, ikdyz vetsinou z5 nebylo, protoze to vyklopit bylo na vetsi hdd a ten uz sem tam nechal :-) ale dobry, docela by me zajimalo proc a jak pouziva rsync.

Nejde to stáhnout bez registrace do Ubuntuforums. Což se mi nelíbí.

Takže pro ostatní "taky nezaregistrované":
http://codebrowse.launchpad.net/~jdong/pyfragtools/trunk/files

Zdrojáky lze ztáhnout také zde: http://download.tuxfamily.org/syzygy42/pool/edgy/reacocard/pyfragtools_0.1.tar.gz

Nic noveho, v clanku chybi zejmena fakt, ze pokud je fragmentace 10% a mene, nema defragmentace zadny smysl. Navic v adresarich jako je /tmp/ a /var/tmp/portage/ je fragmentace nejvyssi, protoze se tam nejvice manipuluje se soubory, degragmentujete a za nekolik malo dnu muzete znovu. Ma to smysl? Dle meho nazoru nikoliv. Radsi bys mel napsat clanek o fatalnich nedostatcich a extremni zabugovanosti kernelu rady 2.6.23 a formou uvahy dedukovat kdo za to muze a jak k tomuto nepeknemu stavu mohlo dojit.

No kdo asi za to muze - Torvalds. Jaky pan, takovy kram.

No nevim, muj Linux je asi trochu jiny, podle measurefs.reiser4 mam fragmentaci 0.5%

Tak ten pydefrag si asi opravdu s reiser4 neporadi (nebo jsem sjetej:-) ) - 3 predposledni radky:

Frags/MB Before: 9494992.74
Frags/MB After: 9494992.74
Improvement: -0.0 %

Snim ci bdim?

Ale po defragu se tech 0,5% trochu vylepsilo - ted to pise jenom 0,05%. To je zlepseni o 90% :-) Vysledny efekt (alespon psychologicky) bohuzel veskrze zadny...

Mali ste aspon porovnat casi pred/po defragmentacii:

cas nabehu a vypnutia systemu, cas kompilacie kernelu, a podobne. Lebo ak to prinesie zrychlenie o 0.0001% tak to nema zmysel

Nemá portage hromadu malých souborů? V Archi docela pomůže dát adresářový strom pacmaních dat do loopbacku nad souborem s ext3 a 1k bloky nebo s ReiserFS.

Mozno vyskusat sqlite backend? (http://gentoo-wiki.com/TIP_speed_up_portage_with_sqlite)

Klídek, jde o defragmentaci souborů, ne disku který je z 99% zaplněn :) Takže bez nějakého nízkoúrovňového nástroje se dá obejít, tohle není FAT.

Pomocí běžných příkazů fs zjistíte fragmentaci a pomocí rsync to s největší pravděpodobností (nemáte plný disk) defragmentujete (protože jakýsi výchozí stav je u ne FAT systémů "nefragmentováno", že).

Dalsi Alenka v risi divu. V clanku je to napsane docela dobre, ve chvili, kdy neni filesystem preplnen, k nejake vetsi fragmentaci nedochazi (pokud prichazite z windos, muze vas to samozrejme prekvapit - po 6 letech behu Linuxu na zhruba 90% zaplnenem disku jsem mel fragmentaci 7%, po cca mesici zakoupeneho notebooku s WXP (TM) na 30% zaplnenem disku fragmentaci asi 42%).

K druhe casti - pokud uz si tedy dal vubec nekdo tu temer zbytecnou praci s psanim defragmentatoru, je za prve uplne jedno, jestli je v pythonu, C, jave nebo assembleru, za druhe, ac se to nemusi zdat, muzou ty vysledky z dlouhodobeho hlediska byt vyrazne lepsi, nez presun kompletniho obsahu filesystemu na zacatek disku ;) (o nutne podmince ve WXP - uzivateli, ted se pokud mozno 10 hodin nedotykej klavesice a mozna ani to nebude stacit (tu logiku algoritmu bych nekdy mimochodem rad pochopil) - ani nemluve).

Takze, priste min narazek na kvalitu clanku a vice premyslet!

Jak tu fragmentaci počítáte? Každý nástroj jí totiž bohužel počítá jinak.

Ve Windows se používá System Restore, kde se ukládají změny v systému (instalace, odinstalace apod). Tyhle věci jsou komprimované na úrovni FS, a jej jich hromada. Při kompresi na úrovni FS se soubor silně fragmentuje (tuším, že se komprimují bloky 16 clusterů, takže komprimovaný soubor je pak na disku děravý jak řešeto). V praxi to samozřejmě ničemu nevadí, protože se komprimují soubory, které se používají minimálně (třeba ty data System Restore), ale FS je pak více fragmentovaný.

jisteze je to problem. fragmentace jako takova je nevyhodna a zpomaluje praci pri I/O a daty. to je proste fakt.

to co popisujete je dle meho nazoru proste vadny navrh aplikace. a resenim je pouzivat neco jineho nez nejake system restore ktere popisujete.

a abych parafrazoval: snad to nejkdy budete moci udelat (ve smyslu: svobodne se rozhodnout ze tu a tu konkretni cast windows nebudete pouzivat, protoze vam nevyhovuje)

Když soubor uložíte nekomprimovaný, a poté jej zkomprimujete, zabere méně místa, než zabíral původně. NTFS provádí kompresi po 16 clusterech. Když je zkomprimujete na 4 clustery, na disku zůstane díra 12 clusterů volného místa. Protože stejně nekomprimujete soubory, u kterých záleží na výkonu, je to celkem jedno. Ovšem ve výpisu fragmentovaných souborů budete mít například komprimované soubory ze System Restore, které jsou rozsekané na stovky fragmentů. Vliv na výkon to má nulový, ale při počítání procenta fragmentace (což je číslo, které stejně každý počítá jinak) se to dost projeví.

Ohledně defragu ve Windows by bylo dobré zmínit, že jde o opravdový defrag (ne prosté zkopírování souboru), provádí se na namountovaném FS, je pro aplikace po celou dobu transparentní, a systém pro něj nabízí API. Ve Vistě navíc defrag běží s nízkou prioritou I/O operací, takže uživatele nijak neruší. No, třeba se unixy časem také naučí ;)

Unixy se naucily defragmentovat automaticky behem prace se souborovym systemem. Takze defrag nepotrebuji. K fragmentaci dochazi maximlna pri zaplnenem disku, kdy jsou schopnosti automaticke defragmentace omezene. Po uvolneni disku se toto opet samovolne napravi, pokud se s temi soubory hybe, coz je pravdepodobne u preplneho disku u tech jeho poslednich souboru. Pokud se nahodou s nejakym nehybe, pomuze prave tento nastroj, ktere takove trvale soubory rozhybe a diky automaticke defragmentaci se tim defragmentuji. A to prosim na namoutovanem FS, pro aplikace je celou dobu transparentni, system k tomu nabizi api (pro zjisteni fragmentovanych souboru), prioritu si uzivatel muze nastavit jakou chce a defragmentaci muze provest jen na vybranych souborech, treba jen v jednom adresari. Pochybuji, ze se tohle windows nekdy nauci.

A ako je tam osetreny moment, kedy sa povodny fragmentovany system nahradi nefragmentovanou kopiou? To sa mi nezda z pohladu systemu velmi transparentne, zvlast ak je ten subor zrovna pouzivany nejakou aplikaciou...

Upřímně doufám, že Windows nebudou nikdy defragmentovat soubory stylem "zkusíme soubor překopírovat někam jinam, třeba se fragmentace zlepší". A protože mají už hodnou dobu API pro defragmentaci, je tu velká šance, že se tak opravdu nestane.

Pokud chcete defragmentovat jednotlivé soubory, viz utilita contig od sysinternals. Ve Vistě to řešit nemusíte, protože defrag běží jako plánovaná úloha každých pár dní. A běží s nízkou prioritou I/O operací, takže uživatele nijak neomezuje. Třeba se to unixy také jednou naučí ;)

moooc vtipne: "...jde o opravdový defrag (ne prosté zkopírování souboru)..."

jisteze to musi delat jinak! ten windowsackay FS je tak spatny ze tam vznika fragmentace uz i pouhym kopirovanim, takze by jim to kopirovani je zhorsovalo stav.

naopak vyspele FS se maji tendence dostavat pohybem souboru zpet do rovnovazneho stavu... sorry ale to je setsakra velky rozdil!

windows proste nemaji momentalne z tohoto pohledu zadny fs kterym by dokazali zaujmout. a nevypada to ze by dokazali vyvynout, ukradnout nebo jak to ted delaji ... neco co by mohli nabidnout jako opravdovy FS. Ledaze by si malomeci koupili k pristim vanocum ZFS...:-)

A proto je optimálním algoritmem defragmentace zkopírovat soubor na jiné místo na disku, a doufat, že bude méně fragmentovaný. A tento postup pak opakovat do doby, než bude fragmentovaný dost málo. Ošklivé Windows mají nějaké blbé API, které umožňuje přímo hýbat s bloky na disku, fuj ;)
http://msdn2.microsoft.com/en-us/library/aa363911(VS.85).aspx

Windows mají fakt mizerný FS. NTFS pravda žurnálový FS, který má nyní i ACID transakce (napříč soubory), má Access Control Listy, transparentní kompresi, Sparse files ("děravé" soubory), žurnál změn (zásadně urychluje backup), transparentní šifrování, Alternate data streams, quoty, Volume Shadow Copy, Single Instance Storage, RAID 1/5 a další. Ano, je to všechno v jednom FS, a je to na každém počítači s Windows řady NT. Ale na Linuxu máme lepší FS. Jeden umí quoty, další access control listy, pak jeden který umí oboje, dva co umí transparentní šifrování... ;)

disk nedefragmentuju. Mam poruchu osobnosti, jsem hotovej. Nic se s tim delat neda je to nelecitelne, kdyz chodim na konzultace s psychiatrem, tak je to jeste horsi. Tak mne zbyva uz jen porad zrat ti antidepresiva jak magor a poslouchat ze jsem idiot. Celej zivot budu jen cumet do kompu a delat kernel. A pritom bych tak rad byl normalni a mel styk se zenou. Ale to nejde, kdyz nekoho sezenu tak utece pote co ji reknu o ty my poruse. A kdyz to nereknu tak by na to stejne casem prisla a utekla taky.

Je to bezvychodna situace.

nechápu tě. můj brácha je na tom o poznání hůře(před vánoci diagnostikována schizofrenie), měl život podobný tvému a nechodí po diskusích a nikde to neroztrubuje. a je spousta podobných lidí, sám si osobně myslím, že mám taky poruchu osobnosti. taková je doba, bude to ještě horší, lidí s psychickými problémy bude jen přibývat. nemá cenu to sem dokola psát, buď se s tím smíříš a přijmeš to jako životní řeholi, nebo to vezmeš jako výzvu a sám se to pokusíš s odborníky uvést do co nejlepšího stavu. přemýšlej o tom.

Ja jsem s tim smirenej, ale vadi mi to. Rad bych byl normalni. Ty doktori ty to delaj jeste horsi. Driv jsem si o tom taky neco precetl a vsude psali ze se to lecit neda, tak uz k nim ani nechodim a nic o tom nectu. Nema to cenu, niceho by se nedosahlo a jen bych se citil mizerne.

Kdyz mas taky poruchu osobnosti, tak co? Tobe to nevadi a nechtel by jsi byt normalni? Ja bych chtel, ale neda se s tim nic delat.

já jsem s tím taky smířený, ale podporou je mně manželka, bez které bych se uchlastal tak do tří let. a k doktorovi radši nepůjdu, protože by mě řekl, že sem psychopatický perverzák a já nevím co ještě a zavřeli by mě do vypolstrované místnosti.

zabij se BLEK-u, zabij se uz konecne

To psal falešný BLEK.

Co víš, třeba má taky poruchu osobnosti a třeba mu to pomůže...

Ačkoliv jsou už z návrhu moderní souborové systémy vůči defragmentaci velmi odolné

- ano, proti defragmentaci jsou kolikrát velmi odolné, s tou fragmentací to tak strašné není :-}

Priklad. 300G partition pouzivam na zaznam TV vysilani (VDR). Funguje to fajnove, ale je tu problem s fragmentaci. Obsazeni se pohybuje 70-95% a ja jsem na filesystem tak zlej, ze si nahravam zpravy a jine opakujici se porady. Kazdy den se tak nahraje mnoho souboru o velikosti stovekMB a ty se az za nekolik dni mazou. Po 9-ti mesicich pouzivani v podstate musim vsechny data vyhodit ven a vratit zpatky, s diskem se skoro neda pracovat. Zkousel jsem EXT3, XFS, Reiserfs3.6 a je to stejne naprd.

A pak ze linux nepotrebuje defragmentovat :-(

Tuhle defragmentaci jsem nezkousel, dam vedet vysledek az si na to udelam cas.

A pouštěl jsi u toho XFS pravidelně defragmentaci (http://www.zdenda.com/xfs-defragmentace)? Nejlépe ji průběžně pouštět ještě než disk dosáhne vyšší zaplněnosti.

No, problém je, že normální využití disku je zapráskat ho skoro celej a v případě defragmentace nějaké místo uvolnit (WinNT potřebuje 15%). S velkýma souborama je fakt problém... navíc na 400GB disku byste nezaplňováním nad 80% ztratili 80GB! Takže haha... Mě osobně dost mrzí, že na linux FS moc nejsou defragmentátory... a transparentní komprese.

Ale tahle utilitka by mohla pomoct... je dobře, že to pracuje nad úrovní FS, aspoň to nemůže nic moc zbodat. Zase ale nedefragmentuje adresáře a neumí přeskupit soubory jinak než náhodně - například knihovny openoffice budou na disku včudě možně...

P.S.: Nejde přispívat Konquerorem. To je nějakej hloupej pokus o bojkot KDE?

"navíc na 400GB disku byste nezaplňováním nad 80% ztratili 80GB!"

Presnejšia formulácia by bola "pri 400 GB disku vymeníte 40-80 GB za rýchlosť". V skutočnosti netreba až toľko, závisí aké veľké súbory sa budú pridávať a meniť. Napr.:

Film (iné väčšie sekvenčne čítané dáta) s cca .5 - 2 GB je nakopírovaný raz a aj keď je fragmentovaný na 5-20 častí, tak to moc žily netrhá, pretože čas strávený seekovaním disku je zanedbateľný oproti čítaniu (predpokladáme že sa číta po dosť veľkých blokoch).

Zato ak máme napr. 2 GB malých, často sa meniacich súborov (ku ktorým je pristupované osobitne v menších dávkach), je pre ne lepšie mať osobitnú partíciu, kde bude .5 - 1GB voľných, miesto aby boli premiešané s >=1 GB súbormi. Tak sa a) neobetuje 40 GB kvôli fragmentácii b) jednotlivé súbory budú korelovanejšie (malé blízko spolu, každý veľký viacmenej pokope).

Teoreticky by sa dalo "štatisticky naučiť" alokátor, čo kam hádzať pre ktorý proces, ale skončilo by to najskôr tak komplikované ako SELinux.

> Nejde přispívat Konquerorem. To je nějakej hloupej pokus o bojkot KDE?

Na tlacitko odeslat se musi "dvojkliknout". Proc to nefunguje nevim. Root.cz by s tim mel neco udelat.

Dvojkliknout? Coze?
*klik*

> P.S.: Nejde přispívat Konquerorem. To je nějakej hloupej pokus o bojkot KDE?

Ano, je. Ale stačí pro roota zakázat JavaScript.

XFS jsem opustil pote, co jsem diky vypadku proudu prisel o data :-(
U souboru, ktery byl pouze otevren pro zapis ale zadny zapis nebezel. Misto dat same 000000000

PS: nemusite me vysvetlovat proc, vim to proc se to stalo.

Odloženou alokací (data se nezapíší, dokud nedojde cache, soubor se nezavře nebo se nesyncne), viz Wikipedia

V dokumentacii k XFS je zmienovany filestream allocator, ktory je presne na pouzitie pri ukladani (viacero streamov) zaroven (ale netusim ci je ale implementovany aj v xfs pre linux, podla googlu sa tvari ze jo).

IMHO pri >=90% fragmentácii (takmer) absolútne nezáleží od použitého FS (až na nejaké obstarožné výnimky). Alokátor sa snaží uložiť bloky rovnakého súboru (súbory v rovnakých adresároch a iných kritérií, závisí od alokátora) blízko seba. Blízko seba môže znamenať aj s fragmentáciou (paradoxne tak súbor fragmentovaný na viacej častí môže byť rýchlejší na čítanie než súbor rozdelený na menej častí, pri ktorých disk musí seekovať ďalej, čo nastáva práve pri veľmi zaplnenej partícii).

Druhá vec: s výnimkou "tlačenia" súboru max. rýchlosťou (napr. kopírovanie, čo nie je moc časté), medzi dvoma prístupmi k súboru od jedného procesu/vlákna stihne disk zaseekovať niekoľkokrát kvôli requestom od ostatných procesov, tam už nejaká fragmentácia extrémny rozdiel nehrá (ak neni 4gigový súbor rozsypaný jak čaj po celom disku).

Nakoniec, pri čítaní mnoho menších súborov (<=20k) je skoro absolútne jedno jak moc sú fragmentované (pr. portage), tam skôr spraví rozdiel
-jak moc blízko sú (prefetch sektorov/blokov do cache)
-či sa po readdir() najprv zotriedia podľa mena (typicky tak nebudú zotriedené podľa inodov/umiestnenia na disku, tiež závisí jak sa vytvárali)

Nejde ani tak moc o fragmentáciu ako skôr o to, že by alokátor potreboval nejaké hinty, jak sa k súborom bude v budúcnosti pristupovať, aby ich nejak "inteligentne" zoradil. Reiser4 a XFS (myslím že aj reiserfs) odkladajú preto alokáciu do posledného možného okamžiku. Ext3 má zase špeciálny atribút na adresáre, ktorým sa mu dá povedať, že má súbory v ňom naopak rozptýliť než držať dokopy (typicky pre home, ale dá sa to nastaviť explicitne aj pre iné adresáre) - zmysel toho je v tom, aby bolo dosť miesta v blízkosti jednotlivých podadresárov (home adresáre rozličných užívateľov nie sú typicky korelované).

Trochu podobnú vec ext3-ovskému rozptylu robí XFS filestreams alokátor pre súbory ak sa očakávajú veľké súbory (nahrávané streamy), snaží sa každý hodiť do osobitnej alokačnej skupiny; nastavuje sa to podobne cez chattr. Ten alokátor sa zase ale nehodí na "bežné použitie FS", hlavne kvôli predlžovaniu (xfs má ďalšie dva alokátory a naviac sa snaží rozhodiť nové adresáre do iných alokačných skupín, z podobného dôvodu "aby mal dosť miesta okolo").

Záver: rozličné metódy jak dostať z FS maximum existujú, ale ich použitie neni úplne triviálne (alokátor ani I/O scheduler nemajú krištáľovú guľu ;-)) Nakoniec najviac spraví cache - radšej dokúpiť väčší disk aby nebol plnší než dajme tomu 80% (menšia pravdepodobnosť fragmentácie, alokátor lepšie vyberá bloky), RAM (viac cache), rozsypané a často sa meniace veci hodiť do tmpfs.

Dekuji za clanek, mam dotaz: Jak defragmentovat v Linuxu FAT32 disk? Ve Windows je defragmentacni nastroj, exisuje neco takoveho i v Linuxu? Nemyslim ten pythonovsky z dnesniho clanku, ten prece neni plnohodnoutnym defragmentacnim nastrojem.

Jak si predstavujete plnohodnotny?

Mozna klic s hlavou a plotynkou - to, ze klic ma hlavu je znamo, plotnu uz k nemu svareckou dodelas :-)

Taky mate ten pocit, ze defaultni windowsi defragmenter pouziva stejnou metodu jako ten pydefrag? Existuji ale i mnohem dokonalejsi reseni - napriklad jen nekopcit soubory semotamo po disku, ale inteligentne prehazovat jednotlive sektory, pak je defragmentace mnohem rychlejsi a taky muze zdefragmentovat i soubor vetsi nez nejdelsi spojite volne misto (to je asi nejvetsi problem pydefragu a podobnych)

Ale ani ne rychle ani ne ucine. Skutecne vykonny defragmenter se bohuzel musi dokoupit. Dalsi duvod, proc jsem na Linuxu.

Takovy defrag by ale slo asi jen s obtizemi pouzit na primountovanem oddilu.

Podle me nejlepsi defrag je koupit si jeste jeden disk a vsechno na nej zkopirovat a pak to prekopirovat zpatky. Pravda, neni to nejlevnejsi, ale stoprocentni a od jiste valikosti defragmentace i nejrychlejsi. Navic to ma vedlejsi efekt - zalohu.

Ja ten kod nevidel, ale uz jsem defragmentoval, jak pomoci Windows defragu tak pomoci O&O. Rychlost toho windowsackeho byla jeste mensi nez u pydefragu (oboje na tom samem 20GB disku). U O&O byla rychlost tak o pulku vyssi. Krom toho windefrag nedodelal ten disk cely, zbylo jeste cca 2000 fragmentu v jednom souboru (DVD 4,5GB). Volne misto bylo asi 5 GB.

Do plnohodnotného se musí zadat licenční číslo a musí zobrazovat graf složený z barevných čtverečků. :-D

Ale ten rsync nema na fyzicke umisteni na plotne disku zadny vliv, to ma na starosti FS.

Tak instalací rsync jsem error hlášku neodstranil, pro ty, kteří mají stejný problém, zde je list několika dalších závislostí, které jsem vyčetl z kódu:

lsof
filefrag
/usr/bin/find
rm

Defragmentace jedineho adresare je totiz blbost. Kdyz uz defrag, tak jedine celeho disku. Nevyhodu tohohle algoritmu spatruji jedine v tom, ze je potreba pohnout s celym souborem, ktery muze byt i znacne veliky.

Mám na serverech monitorování přes Nagios a SNMP a disky čistím při zaplnění přes 50% mi Nagios hlásí warning a při zaplnění 80% critical, a pokud tento článek tvrdí, že fragmentace se děje nad 80% vidím opravdu korektní řešení zajistit, aby obsazenost disku nikdy nepřekročila tuto hranici.

Doporučoval bych spíše zajistit kvalitní dohled nad servery a předcházet problémům než je řešit když nastanou.

Zacnu otazkou: ma smysl defragmentovat ramdisk? Nebo flashku? Pokud ano, jaky?
Doby kdy kazda I/O operace znamenala hybani s nejakou hmotnou veci a pri praci s s diskem se vedelo, se kterym valcem, hlavou a sektorem se pracuje, tam mela defragmentace smysl.
Dnes, kdyz uz nekteri pomalu ani nevedi, jak vypadala disketa a kdy pomalu kazdy disk ma interni cache, elevatorovou optimalizaci a hlavne naprosto nejasnou fyzickou geometrii, o diskovych polich s RAIDem ani nemluve, nema defragmentace vubec zadny smysl.

Tak si schvelne vezmi nejaky vetsi diskovy prostor (rekneme 1TB v RAID10), ktery je vysdileny pro beznou potrebu koncovych uzivatelu (napr. home-adresare nebo neco podobneho) a zkus ho zazalohovat na pasku pred a po defragmentaci. Rozdil si muzes zmerit ...

Ale musis uznat, ze u uloziste s nahodnym pristupem defragmentace nema smysl.

Ale ne u flashek - ty totiz, jak kazdy jiste vi, nemaji zadne latence, ani seekovaci ani rotacni, krome toho se nectou stopu po stope, ale sektor po sektoru, takze readahead neni prakticky vyuzitelny. Takovy fragmentovany disk je stejne rychly jako ten nefragmentovany. Pak je tu jeste ten problem s opotrebovavanim, ktery je ale v dnesni dobe zanedbatelny.

Už jsem si pro sebe popřel to, že na Linuxu neexistuje žádná fragmentace - existuje (i když třeba méně než na windoze). Ale slyšel jsem někde, že jak jednou nějaký FS zdefragmentujete, tak už to musíte dělat pořád, jinak fragmentace naroste ještě víc... Není mi úplně jasné, jestli je tedy výhodné použít defragmentaci třeba jednou za rok?...

To je kravina.

No já už taky dřív něco takovýho četl. Psalo se tam, že defrafmentace systémových souborů je v pořádku, ale defragmentace dat, že udělá na disku větší bordel tak po týdnu od provedení, systém si má prej určovat sém co kam nahraje a ne nějakej program, tak nějak to tam bylo napsaný, přesněji to byla dlouhá diskuze

Originalni bittorrent v pythonu od Brama Cohena uklada stazena data za sebe (tj. bez seeku) a v pripade, ze stahl cast, ktera patri na misto pred aktualni pozici zapisu, pak tyto dve (prave stazenou posledni, tu ktera ji zabira misto na jeji pozici) prohodi. Tim se opravdu dobre vyhne fragmentaci.

Jinou moznosti jsou nejmenovani bittorrent klienti, kteri pouzivaji posixovou funkci:
#define _XOPEN_SOURCE 600
#include <stdlib.h>
int posix_fallocate(int fd, off_t offset, off_t len);

Chytrejsi OS/FS jim vyhradi misto.

Odkaz na podoný článek defragmentace počítače