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

Zaráží mě fakt, že autor ani nenaznačuje způsob, kterým testovaný program degragmentuje soubory, dokonce ani způsob, kterým analyzuje fragmentaci.

Zatím všechny mě známé programy, které "defragmentovaly" svazky nezávilse a filesystému to dělaly tak, že každý soubor zkopírovaly a následně změnily link současného souboru na zkopírovaný (což je ostudně hloupá metoda, na kterou nemusíte mít žádný program - stačí jeden bash one-liner). Defrag k této práci asi používá rsync, což je zajímavé.. ;) (na to, že rsync je program na synchronizaci složek)

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

Tolik můj kousek do pranice - neříkám, že defrag nedělá nic, ale já bych k schopnostem takovéhoto programu přistupoval mnohem více skepticky než autor.

Koukam do kodu a vola to:

fragresult=subprocess.Popen(["filefrag",file],stdout=subprocess.PIPE).communicate()[0]

takze na zjisteni fragmentace to pozuiva nejaky program filefrag, ktery nemam, ale google ho celkem zna, takze asi v nekterych distribucich bude bezne.

Samotna defragmentace probiha zkopirovanim rsyncem, takze zadna zazracna metoda se nekona.

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

Musím přiznat že máš pravdu a jde to - koukal jsem na zdroják filefrag-u z e2fsprogs a dělá to úplně stejně (tj přes FIGETBSZ a FIBMAP ioctl-y). Pouze mi přijde filefrag trochu nepřesný, a to tím, že nebere v potaz jaká je vzdálenost mezi jednotlivými fragmenty - fragmentované soubory na mém reiserfs oddílu vypadají takto:

nb-esprimo /usr/portage/distfiles # filefrag -v tetex-src-3.0_p1.tar.gz.new
Checking tetex-src-3.0_p1.tar.gz.new
Filesystem type is: 52654973
Filesystem cylinder groups is approximately 80
Blocksize of file tetex-src-3.0_p1.tar.gz.new is 4096
File size of tetex-src-3.0_p1.tar.gz.new is 13357541 (3262 blocks)
First block: 79879
Last block: 84138
Discontinuity: Block 221 is at 80101 (was 80099)      -- vzdálenost mezi fragmenty je jen 1 blok
Discontinuity: Block 993 is at 81867 (was 80872)      -- vzdálenost ~1000 bloků (4MB)
Discontinuity: Block 1010 is at 81885 (was 81883)     -- vzdálenost 1 blok
Discontinuity: Block 2013 is at 82889 (was 82887)     -- 1 blok
Discontinuity: Block 3033 is at 83910 (was 83908)     -- 1 blok
tetex-src-3.0_p1.tar.gz.new: 6 extents found

Filefrag tedy reportuje 6 fragmentů, ale prakticky jsou pouze 2 (2 čtení s díru 1 blok spojí kernel do jednoho čtení, a když to neudělá kernel, tak to spadne do disk readaheadu). Jediné, co nevím, je jestli reiserfs dělá tyto díry schválně a jsou prázdné, či jestli to jsou data jiných souborů (jednoblokových souborů mám hodně - portage), či metadata.

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

Dík za motivaci, taky jsem všude slyšel, že Linux nepotřebuje fragmentovat nebo co... a já už mám na jednom disku 17% fragmentaci. :-) Hned, jak bude čas, tak to využiju.

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?

Bdíš - pouze filefrag (kterým skriptík defrag měří fragmentaci) dost dobře neumí měřit fragmentaci na filesystémech, které nejdou podobné ext2/3. Na mém reiserfs taky reportuje docela dost (80%) false-positives. (na reiser4 je to koukám ale horší.. ;) )

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.

Ano, ma. Po umisteni portage do loopbacku (inspiraci mi byl prave navod pro arch kdesi na abclinuxu) se prace s nim vcelku zrychli.

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

Vim o tomto reseni, ale USE flag 'sqlite' mam zakazany, nepotrebuji jej. Jenom proto, abych si urychlil portage, kdyz existuje i jine reseni, se mi jej povolovat nechce.

Na to ale netreba vobec pouzivat sqlite USE flag (tj. na sqlite nemusi nic zavisiet, keby aj, stacilo by to pridat do /etc/portage/package.use len jednemu packagu). Staci emergnut pysqlite (co natiahne sqlite) a vysvetlit to portagu v /etc/portage/modules:

portdbapi.auxdbmodule = cache.sqlite.database

BTW najrychlejsie riesenie by bolo tmpfs, ale to by bolo treba komp davat do suspend-to-disk alebo suspend-to-ram (miesto shutdown, pripadne z tmpfs pred shutdownom portage tree skopirovat, co zaroven sposobi nizsiu defragmentaciu vzhladom k alokacii tych suborov na disku, lebo sa to kopiruje naraz).

Plus tmpfs sa da zaroven efektne pouzit aj pri emergovani (kompilacia je potom rychlejsia, ak mate dost RAM, treba mountnut tmpfs do /var/tmp).

Ale ja si nechci mergovat sqlite. Proto jej mam zakazany - aby mi nic sqlite netahalo mezi zavislosti. Znam package.use, znam i postup pro zprovozneni jako backend z te wiki (to uz jsem myslim zminoval), ale nechci jej pouzivat.

V clanku je zmineno, ze byl defragmentovan pouze adresar /src. Jeho defragmentace napr. rychlost bootovani vubec neovlivni...

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)

Můžu se zeptat, proč by se při kompresi na úrovni FS mělo fragmentovat více než normálně? Nějak pro to nenacházím důvod.

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

Aha. Pokud tím myslíte kompresi už existujícího nekomprimovaného souboru, tak už chápu. Dík.

No neviem, neprijde mi ako najlepší nápad nechávať diery v komprimovaných súboroch. Keďze FS compression routine musí na každých 16 clusterov spraviť read&write, tak je už skoro jedno, či sa presunú, alebo nie, pretože zapísať ich treba. Teoreticky by tam mohlo byť spomalenie kvôli seeku pri komprimácii extrémne veľkých súborov >=.5GB, ale tam už nejaká diera nejak nezaváži ak by boli "kompaktované" dajme tomu po 1 MB (tj. nevyžadovať úplnu "bezdierovosť", ale zhlukovať po skupinách).

Tam ani tak nejde o tie SysRestore súbory, k tým sa moc nepristupuje, skôr o tie, čo sa natlačia do dier medzi ne (netvrdil by som že "vliv na výkon nulový").

Tam by som sa nebál, že sa tam nacpú veľké súbory (to žiadny aspoň polointeligentný alokátor nespraví), ale môže tam narvať kopu malých. Proces čítajúci ich potom bude nútiť disk seekovať (v závislosti od počtu dier a počtu malých súborov).

Napr. alokátor usúdi, že file1 sa tam zmestí, dá ho tam, do ďalšej diery dá file2, pretože je blízko file1, takže sa moc seekovať nebude, ale takýmto spôsobom ak sa tam narve tak 100-500 fajlov (lebo každý je blízko predchádzajúcemu), tak to už seekovať bude dosť pri náhodnom prístupe k nim (napr. inštalátor ich tam narve a aplikácia k ním nejakým úplne iným spôsobom bude pristupovať, čo je bežný use case).

Fragmentovaný free space je podobne blbý ako fragmentované fajly (tam závisí, či sa viac číta, alebo viac maže/vytvára).

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

V UNIXU je dokonce mozne dokonce i smazat soubor, ktery prave nejaka aplikace pouziva. K jeho uvolneni dojde po tom, co ho ta aplikace prestane potrebovat, kdepak, kam se na to hrabou windows :-).

Nemáš pravdu. Ještě v XPčkách to nefunguje dobře - pokud otevřeš (nebo třeba i vytvoříš) soubor, následně ho zavřeš a pak se ho pokusíš smazat tak to s docela vysokou pravděpodobností selže. Smazání se neprovede, protože widle mají ten soubor ještě otevřený. A to i pokud tuhle posloupnost provádíš v rámci jednoho threadu.

Po zavření se provádí volání různých háčků (antiviry atd), což v případě vytíženého CPU vede k tomu, že následující smazání souboru selže protože jej má někdo otevřený. Widle to neumí pořešit - otevřený soubor nesmažeš.

Řešil jsem toto v kódu už několikrát - ale jen na windows portu, v unixu nikdy.

Ano, tomu se prave rika ty security dekriptory a access righty. To, ze to nechapes je sice smutne, ale vzdycky muzes pouzit UTFG, aby si zjistil co to znamena. To, ze nemuzes nastavit, aby ti jiny proces nemohl smaznout file (co asi podle tve reakce v linuxu nejde) bych povazoval za velmi zasadni nedostatek file systemu .... toliko asi k te vyspelosti linuxovych filesystemu ....

pokud otevřeš (nebo třeba i vytvoříš) soubor, následně ho zavřeš a pak se ho pokusíš smazat tak to s docela vysokou pravděpodobností selže

Ano, tomu se prave rika ty security dekriptory a access righty.

Co má tohle společného se security descriptory a přístupovými právy?

To, ze nemuzes nastavit, aby ti jiny proces nemohl smaznout file (co asi podle tve reakce v linuxu nejde) bych povazoval za velmi zasadni nedostatek file systemu...

No tak kdo co může smazat se řeší pomocí přístupových práv, případně nějakých mandatory access control, ne?

vyda za tisice slov....
http://msdn2.microsoft.com/en-us/library/aa363858.aspx

Pokud tim nemyslis "DELETE_ON_CLOSE", tak jsem asi natvrdlej. A DELETE_ON_CLOSE je naprd napriklad v pripade, ze soubor je vytvaren v nejake knihovne, k niz nemas zdrojaky.

Co jsem prehledl?

Myslim ze si prehliadol FILE_SHARE_DELETE :) Ono to vsetko ma svoj vyznam a osobne mi pride vhodnejsie obcas vopruzovat userov, ako nemoznost exkluzivne locknut file :) Taky flock() je v linuxe len poradny a pokial niektory proces nedodrzi lockovaciu konvenciu (napriklad zaskodnicky), pruser s nekonzistenciou dat je na svete...

To, ze nemuzes nastavit, aby ti jiny proces nemohl smaznout file (co asi podle tve reakce v linuxu nejde) bych povazoval za velmi zasadni nedostatek file systemu

Úplně to zakázat sice nejde (root může všechno), ale souborový systém si umí poradit i s tím, že mi někdo ten soubor pod rukama ukradne nebo smaže. V UNIXu jsou otevřené inody, ne VFS cesty. Když někdo zruší VFS cestu (smazáním nebo přesunutím souboru), inode buď existuje dál s jinou VFS cestou, nebo bude existovat ještě tak dlouho, dokud ho nezavřou všechny programy, přestože VFS cesta už neexistuje.

Ne. Vidim, ze se jedna o uzitecnou vlastnost, kterou pri sprave systemu casto pouzivam.

Pokud lze Unixu neco v tomto smeru vytkout, pak je to API na mazani souboru. Soubor nemohu smazat pres ofile (pres handle), ale jen pres cestu. Vzdy je tam jiste okenko mezi tim, co si overim "/cesta/soubor je to, co chci smazat" a co provedu "smaz /cesta/soubor". Pokud bych mohl pouzit ofile (handle), mel bych jistotu o identite toho, co mazu.

To je důsledek implementace UNIXových souborových systémů. V UNIXu soubory nemají jméno :-) Jméno souboru je jen položka v adresáři s odkazem na příslušný inode, zpět žádný odkaz nevede. Ve chvíli, kdy soubor otevřete, se prostě zapomene na nějaké cesty a pracuje se jen s inodem.

To snad není specifika UNIXů, ale Linuxu. Na málo kterém systému lze za běžných okolností otevřít soubor /dir/file, smazat ten soubor, vytvořit jiný /dir/file, opět ho otevřít, a mít efektivně otevřené dva soubory s jedním jménem a různými obsahy.

Už se mi s NTFS několikrát stalo, že po odstřelu programu, který během odstřelu zapisoval velké množství dat do souboru (řádově stovky MB), ten soubor nešel smazat ani po několika restartech systému.

Mám za to, že tohle nebude problém FS, ale toho, že někdo drží handle. Doporučuji Sysinternals Process Explorer (nebo utilitu oh z Resource Kitu), a zkontrolovat, jestli soubor opravdu nikdo nedrží. V úvahu též připadá poškozený FS, viz chkdsk /?

No jo, ale v Linuxu ten soubor proste vymazes a ve chvili, kdy uz ho nikdo nebude potrebovat, soubor proste zmizi. Ve Windowsu musis cekat a zkouset. BTW ten sysinternals je placeny, co?

Tooly od sysinternals su free.

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čí ;)

A uz v tej viste konecne ten defrag funguje? V NT4.0 oficialne nebol potrebny. Vo Win2K sa zrazu objavil a nefungoval. Rovnako nefunguje ani v XP. Prejde si cely disk, par suborov defragmentuje a potom skonci s tym, ze nic viac spravit nevie. Niekedy sa po par prechodoch umudri, niekedy nie. Zaujimave, ze o&o defrag funguje - trial verzia je sice zadarmo, ale potom treba platit...

Tady bych trochu nesouhlasil.

Vykon disku pro i/o operace a jeho defragmentace jsou (mebo alespon muzou byt) dve rozdilne veci:


Defragmentace podle mne znamena, ze data souboru jsou za sebou fyzicky umistena byte po bytu, bez nutnosti preskakovat jakekoliv nesouvisejici "mezi-clustery".

Vykon zase znaci, ze casto ctene soubory jsou fyzicky presunuty takovym zpusobem, aby nedochazelo ke zbytecnym prodlevam pri jejich cteni. V nekterych pripadech to muze odpovidat vyse zminene defragmentaci, v jinych se zase data paralelne "rozprostrou" mezi vsechny plotny disku tak, aby nedochazelo ke zbytecnemu komihani hlavicek disku.


Jestli se v necem mylim, rad si prectu jine vysvetleni.

Doufas ze windows nikdy nebudou umet defragmentovat prubezne pri praci, jako to umi linux, procpak? Me to prijde velmi vyhodne.

Musim te zklamat, unixy rovnez umi planovane spoustet ulohy na pozadi s nastavitelnou prioritou, rekl bych dokonce, ze dele nez vubew windows existuji :-).

Tim bych si nebyl jisty. V dobe prvnich Linuxu to mohly byt tak Windows 98 a Windows NT. Windows 98 ma jakysi klikaci task scheduler. Na nastaveni priority si nejak nemohu vzpomenout, i kdyz jsem ho nikdy moc nepouzival. Windows NT ma at prikaz, ktery je tak blby, ze radsi nekdo napsal ntcron. Na command line utilitu pro spusteni procesu s jinou, nez defaultni prioritou, si nejak nemohu vzpomenout. Zadne prekvapeni v systemu, kde neni ani whois. Nevylucuji, ze neco bylo v Ressource Kitu, ale na nic si nevzpominam. Ovsem vzhledem k tomu, jak "dobre" byl RK zdokumentovan, kdyz jedinou dokumentaci byly nazvy utilit a nekdy i help, ktery umely vypsat po aplikaci nektereho z rady switchu (-? /? -h -help /h /help), je mozne, ze jsem neco prihledl. Takze leda sehnat nejakou utilitku z Internetu, ale tyhle veci se sefovi tezko vysvetluji. Koneckoncu se mu nedivim, kdo mu zaruci, ze v tom nejsou chyby nebo nejake svinstvo.

Windows 98, a tuším i NT 4 po nějakém SP, mají scheduler s GUI. V NT byl příkaz AT, který byl zcela v pohodě. Příkaz pro spuštění procesu s jinou prioritou se jmenuje start. Resource Kit Tools jsou zdokumentované velmi dobře v přiložených souborech, a samozřejmě v Resource Kitu jako takovém.

Kdo vám zaručí, že v něčem,co si stáhnete pro Linux (včetně vlastního distra) není nějaké svinstvo? Asi nikdo, že?

Prominte, ale k RK, ktery jsem mel k Win NT ja, nebyla dokumentace prakticky zadna. Par .doc fajlu na CD (asi tak 3), pak u nekterych utilitek help. U nekterych jen nesrozumitelny vypis options (treba subinacl, o kterem bylo prd i v Technetu, navic to prd bylo zastarale, pro predpotopni verzi). Mozna, ze se nekde susily knihy, ale ty jsou mi na prd, kdyz neznam jejich topologickou polohu, ktera muze byt ve filialce na druhem konci mesta.

Sheduler s GUI byl v NT Ressource Kitu. Byl uplne hrozny, neco, co by napsali pionyri v hodinach vyuky programovani na IQ151. A rikejte si, co chcete, na Win NT a vyse jedine ntcron. Navic, byly i doby, kdy se Microsoftu zahadne ztracely polozky at scheduleru z registry. Pravda, je to jiz dlouho.

Svinstvo muze byt vsude, nicmene oficialni fajl v distru nebo ze site Microsoftu je pravdepodobne cisty, i kdyz v obou pripadech se chybicka vloudila. Microsoft mel viry, nejaka lokalizovana verze nejakeho distra mela rootkit. Ovsem kdyz pujdete na Tucows nebo warez sajty, riskujete mnohem vic.

SubInACL jsem nepoužíval. Většina utilit vypisuje sama o sobě slušnou nápovědu, další mají dokumentaci v instalačním adresáři. A ano, v knize byly utility popisované. Na CD byla elektronická verze knih.

V NT4 po instalaci nějakého SP nebo verze MSIE byl k dispozici plánovač podobný tomu ve Windows 98 nebo Windows 2000. Ruku do ohně za to ale dávat nebudu. Položky AT se mi z registry neztrácely. Tedy ztrácely, poté co se job provedl ;)

Oficální file v distru možná bude OK. Když ovšem něco stáhnete, tak je to bez digitálního podpisu sázkou do loterie. Proto MS své soubory podepisuje.

Možná proto, že FS ani na Linuxu při práci nic nedefragmentuje :). Snížení celkové fragmentace může být vedlejším efektem vytváření a mazání souborů na disku, což je u dnešních FS více-méně nezávislé na konkrétním FS (podobně jako fakt, že novější FS začínají masivně fragmentovat až při vysokém stupni zaplnění disku).

Ano, unixy umí pouštět plánované úlohy. Ovšem málo který unix umí řídit prioritu I/O operací. A Linux (mimochodem ještě pořád nemá ani prioritizaci IRQ?) mezi takové systémy nepatří. Abych to vysvětlil i pro eee: priorita procesu nezajišťuje, že nezabere velké procento přenosového pásma disku. Proces s nízkou prioritou dostane čas procesoru, jen pokud ho nikdo jiný zrovna nepotřebuje (odborníci odpustí zjednodušení). Bohužel pokud proces s nízkou prioritou například prochází adresáře a čte soubory, vygeneruje s klidem přes svou nízkou prioritu daleko více I/O operací, než ostatní procesy dohromady. Ostatní procesy potom čekají na disk, a celý systém je tuhý. Proto má Vista řízení priority I/O operací, a možnost zaručeného průtoku dat.

Jen škoda, že není v běžně dostupných souborových manažerech pro windows toto API použito a proto když člověk kopíruje velký objem dat, u kterého by mu nevadila nižší priorita, aby mohl na popředí pracovat, tak je situace obdobná jako v systémech bez I/O priority. Bohužel mít API není vše, je potřeba, aby to API taky někdo používal a fungovalo to.

AIX a mainframe OS umi ridit prioritu IO operaci, BSD, Solaris, Linux ne. Snazil jsem se lobovat na Solaris i Linux support ML aby se na tom zacalo delat a nemohl jsem to tam tem vyvojarum poradne vysvetlit proc je to vubec potreba. Nechapali to.

"One of the coolest things about CFQ is that it features I/O priorities (since 2.6.13). That means you can set the I/O priority of a process so you can avoid that a process that does too much I/O (daily updatedb) starves the rest of the system, or give extra priority to a process that shouldn't be starved by other processes, by using the ionice tool included in schedutils (since version 1.5.0)."

Co přesně potřebujete, že Vám tohle nestačí?

Toto ale ocividne ani windows nedokaze, resp aj ked dokaze, nevie to spravne pouzit. Uz ti niekedy zblbla java? Mne mnohokrat a to disk potom slapal tak, ze som notas musel rucne restartovat.

A Linux (mimochodem ještě pořád nemá ani prioritizaci IRQ?) mezi takové systémy nepatří.

Já mám v dokumentaci "Linux supports io scheduling priorities and classes since 2.6.13 with the CFQ io scheduler", a co mohu vypozorovat, skutečně mi to funguje. :-)

Ano, to nepochybně. Kdyby tak diskový hardware rezervaci přenosového pásma smysluplně dovoloval, to by bylo pěkné. ;-)

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

MP3 a filmy, to je fakt produktivne pouzivanie...

PROC je NTFS lepsi? To, ze je, jsem tu cetl jiz nekolikrat. Ale to proc mi tu furt chybi. Jinak ACL umi EXT3 take. Potiz je jen v tom, ze to neumi vsechny utilitky a tak se treba zalohuji ACL zvlast, protoze je tar neumi. Tedy, pokud se to zatim nezmenilo.

Jinak s temi ACL se na Windows NT da nadelat takovy bordel, ze uz pak nikdo nevi, co, jak, kdy a proc a jiz to jen tak ze setrvacnosti existuje. Nastroj, ktery by se to vypsalo do nejakeho csv a prohrablo programem, neexistuje. Existuji utilitky z Ressource Kitu, ktere obvykle neumi nastavit separator ve vypisu a tak jsou na hovno. Diky nazvum s mezerami se programove tezko odlisuje, kde co konci a kde zacina neco jine. A pokud do te NT site hrabne nekdo s enhanced ACL editorem nebo jak se to, je to uz uplny bordel. Kazde z access right, jak je kazdy zna, se rozpadne na dve a mozna vice detailnejsich prav, pricemz zjistit, co cemu odpovida, lze jen systemem pokus-omyl. Primitivni pristupova prava na NIXech stylu ugo maji sve vyhody v pripadech, kdy s nimi lze vystacit. Vznik takoveho chlivku je totiz fyzicky nemozny.

BTW, na NTFS mi chybi symlinky. Hardlinky sice ntfs umi, ale ty moc nepouzivam. Navic Microsoft, jako obvyhle, chytre nedodava utilitku, ktera by s nimi umela. Takze zase zbyva jen sysinternals.

BTW, zda se, ze pervitin svinim nehazis, ale zeres ho sam. Tak nevim, jak pusobi pervitin. Rika se, ze heroin=agresivita, kokain=arogance. Ze by pervitin=anonymita?

NTFS má řadu features, které konkurenční FS nemají. Umí ACID transakce (například zapiš do souboru A, zapiš do souboru B, proveď update databáze C, poté proveď jeden commit nebo rollback). Má ACL, quoty, transparentní kompresi, transparentní šifrování, ukládá názvy souborů vždy v Unicode, umí snapshoty, má podporu rozšířovacích modulů (například bezešvá integrace HSM), umí hard linky, je POSIX compliant. Windows nabízejí také backup API, které vám umožní provést zálohu čehokoliv bez ohledu na permissions (pokud máte permissions k tomu API), s tím že šifrované soubory se dumpují šifrované. To je velmi silná sada features.

Access Control List se dá z command line editovat pomocí cals/icals. V praxi se to ale dělá téměř výhradně z GUI. Samozřejmě vACL lze vyrobit bordel, ale zase nabízí velikou flexibilitu. Naštěstí admini vědí, jak s ACL dělat. V unixech musíte vytvářet stovky skupin, místo každé kombinace práv jednu skupinu, což je daleko horší přístup. Pokud máte na unixech ACL (což dodnes není samozřejmé), bordel lze vyrobit stejný, jako ve Windows. Rozdíl je v tom, že ve Windows ho lze v grafickém editoru ACL rychle a pěkně uklidit.

Hardlinky se pravují utilitou fsutil. Obecně se doporučuje je nepoužívat, protože mohou vést k cyklu ve stromu (proto pro ně není GUI).

Tim grafickym editorem ACL myslite takovou tu klicovou dirku pevne definovane velikosti, kde porad vsim soupete nahoru a dolu a zleva doprava? V tom se to moc dobre neuklizi, kdyz tam nic poradne nevidite. Alespon chliv, ktery jsem ja videl, byste v tom delat nechtel. Autorum tehlech dialogu by meli useknout obe ruce az u zadku. A Billovi Gatesovi za to, ze od dob Win NT furt jeste nejdou zvetsit. Navic ani nemaji tab na taskbaru, pokud se pamatuji, takze kdyz vam na jedinem desktopu pod neco zapadnou, tak se nahledate.

A ne vsichni admini vedi, jak s ACL delat. Tedy vedi, jak s ACL delat bordel. 50 serveru, 500 workstejsnu a je to. :-)

Editace ACL je opravdu ve fixed size dialogu (příští verze Windows je bude mít zvětšovací). To v praxi ale není problém. Pokud se vám dialog roluje do stran, nastavte si lepší velikost sloupců tažením myší.

Opravit ACL zpravidla znamená jít do dialogu Advanced, zaškrtnout Replace All a stisknout OK. Smozřejmě existují i složitější manévry ;)

Ano, špatní admini neumí dělat s ACL. Buď jim země lehká.

Četl jsem původně "hazet pervitin svinim", což mě dost pobavilo.

Prosim, vysvetluj. V cem je NTFS tolik lepsi nez ext3, krome toho ze se s nim pri defragu uzije o dost vic srandy? Vykonem jsou na tom podobne, zurnal maji oba, chyb obsahuji srovnatelne. Ja mam na ext3 i oggy nebo FLACy (tech druhych minimum) a fragmentaci nevidim. Filmy bohuzel newarezim a na HDTV nemam misto (fyzicky ani na disku).

Kterou zkratku neznam?

NTFS viz http://www.root.cz/clanky/defragmentace-disku-v-linuxu/nazory/178641/

NTFS na fragmentaci samozrejme trpi, i kdyz podstatne mene, nez FAT a to az do doby, kdy zaplneni didku dosahne 88%.

Zurici flame war me vyprovokovala ke googlovani a nasel jsem zajimavy link: http://www.digit-life.com/articles/ntfs/. Doporucuji precist cast "Part 2. Features of NTFS defragmentatoin" (vcetne preklepu). Zajimave je, ze jednim z duvodu fragmentace je pouzit defragmentacni API, ktera zanechava disk plny malych der, ktere pak OS vyplni pomalu rostoucimi soubory. Nasledne se muze defragmenbtovat znovu a tak porad dokola. Prikladem by mohla byt fragmentace swap file, pokud ho clovek nema nastaven natvrdo na pevnou velikost, jako ja.

Cili se da rici, ze nejlepsi je disk nedefragmentovat, dokud to jede slusne, potom presypat data jinam, zformatovat a nasypat zpet. U systemove partsny se tohle ale dela blbe, clovek potrebuje druhy pocitac a pak jeste musi nasypat zpet MBR. Cili se nam ta defragmentace na Windows nejak komplikuje.

Ze NTFS je architektonicky mnohem lepsi, nez EXT3 sem psat muzes, ovsem chtelo by to krapet podlozit. Propaganda Microsoftu, o kterou se tu asi s nami delis, neni zrovna argumentem. Napis sem zcela objektivni zduvodneni, proc je NTFS lepsi, nez EXT3. Fakt by me to zajimalo. Nepopiram, ze je to robustni FS, ktery prezije docela dost, ale uz se mi stalo, ze jsem nedokazal smazat adresar a v nem lezicich nekolik souboru, ktere se samovolne prejmenovaly (bez padu systemu) na jmena obsahujici otazniky a podobne znaku. Windows NT utilitka na opravu disku (scandisk nebo jak se to) s tim nic nenadelala, pomohl az format. A problemy s fragmentaci a skvele defrag API me take moc nerajcuji.

Mozna, nevim. Vidim jen to, co pisi.

Nicmene se mylite, co se tyce tech otazniku. Ty vznily tak, ze jsem preinstaloval NT na novy disk. Pak jsem tam strcil stary disk, presypal vsechno do jednoho podadresare. Postupne jsem to pak probiral a kopiroval jinam. Zbytek jsem tam nechal valet, kdybych si vzpomnel, ze jeste neco potrebuji. Pak najednou zahadne vznikly ty otazniky ve jmene toho adresare, kde byla ta stara data. A kdyz jsem pak jednou chtel vymazat vsechno, co zbylo a nebylo potreba, zbyl mi ten adresar a v nem nekolik adresaru s podobne zmrsenymi nazvy a par souboru s podobnymi nazvy uvnitr. Nebylo cesty, jak to smazat, pomohl pak az format, pri dalsim upgrade na vetsi disk. Chkdsk nic nezmohl, ani kdyz byl. A Unicode tehdy snad vubec na Windows NT neexistovalo. To snad az tusim Windows XP. Nevim, kdo by tam ty Unicode znaky za mymi zady nacpal. Krome toho, kdyby to byl Unicode a neodpovidalo to specifikacim FS, Windows NT a co ja vim ceho, ocekaval bych od chdsk, ze to uvede do stavu odpovidajicimu specifikacim, i kdyby ty nazvy mel zmenit. Smazat to nejde, dalo se sice vlezt do tech divnych adresaru, ale ty soubory uz otevrit nesly. Tak co s tim?

Obávám se, že se mýlíte vy. Windows NT jsou kompletně v Unicode od první verze, nikoliv od XP :). Ne-Unicode aplikace (tj. ty psané pro Windows 9x bez použití Unicode layeru) jedou v jedné vybrané code page, stejně jako na Windows 9x, a jejich volání se překládají do Unicode. Pokud je v názvu souboru znak, který je mimo kódovou stránku ne-Unicode aplikace, zobrazí se ten znak jako otazník. Total Commander a podobé kousky neumí (nebo dlouho neuměly) Unicode, protože je psala prasata (Total Commander mimo jiné ukládal konfiguraci v Program Files). Ve vašem případě si navíc tipnu, že jste po instalaci Windows nechal kódovou stránku na americké (locale je na tom nezávislé), takže ne-Unicode aplikace viděly i české znaky jako otazníky. Předpokládám, že některé dřevní aplikace měly také zmršenou češtinu v menu apod.

Popsaná situace je by design. Stačilo vzít Windows Explorer, a soubory byly v pohodě. Tedy ještě mohl zafungovat třeba antivir napsaný prasaty, ale to už by bylo asi fakt moc :). Dalším zjevným řešením by bylo přepnout code page ne-Unicode aplikací. Chkdsk s tím neměl co dělat, protože FS byl v pořádku.

Když to shrnu, problém byl v kombinaci zprasených aplikací a vaší neznalosti. Smozřejmě IT jako obor má maximum takových situací eliminovat, a uživatele tím nezatěžovat. Pokud ale pracujete s unixy, podobná překvapení jistě zažíváte každý druhý den.

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í... ;)

O com inom ako o tom, aky je NTFS skvely suborovy system, by mala byt diskusia k clanku o tom, ako defragmentovat automaticky sa defragmentujuce suborove systemy?
A nie je ten linux smiesny? Ani editor registrov nema!

Pečtěte si přísěvek, na který jsem reagoval. Byl k věci? Proč tedy vyčítáte nedržení se tématu mě, a nikoliv jeho autorovi?

Kdyz demagogovi nejde mlzit v jednom tematu, prechazi mlzit do tematu pribuzneho, LO mi neodbytne pripomina placeneho agenta Microsoftu, ktery ma za ukol presvedcovat v diskuzich ne a malo odbornou verejnost, ze windows je lepsi, jakymkoli zpusobem za jakoukoli cenu :-).

No co, třeba je za to alespoň slušně placen:-)

Myslenka roku: Pak se ale vnucuje zcela logicka otazka, kdo plati vas ostatni...

Ja do diskuzi na stranky microsoftu demagogii o windows sirit nechodim :-).

Jasně. My radši budem přesvědčovat, že Linux je lepší, jakýmkoliv způsobem za jakoukoliv cenu.

Mluv prosim za sebe, ja tohle nemam za potrebi.

a prosim ta, k comu je linuxu potrebny editor registrov, ked veskera konfiguracia sa zapisuje do textovych suborov v adresari /etc? staci ti na to nejaky jednoduchy textovy editor (napr. vim, ci ten v mc),
ale na Windowse rady 9x a WinNT je potrebny editor registrov, lebo v nich je konfiguraxcia v podobe niekolkych binarnych suborov a bez editora sa asi tazko nieco nastavi

Opakuji se, jiz jsem to psak jinde, ale prectete si http://www.digit-life.com/articles/ntfs/, cast Part 2. Features of NTFS defragmentatoin. Jak se zda, neni to s fragmentaci NTFS tak slavne, jak Microsoft tvrdi a defrag API je opravdu nejake blbe. Jedinym zpusobem, jak defragmentovat NTFS disk, je presun na jiny disk, format, presun zpatky. Format je asi jedinym zpusobem, jak defragmentovat MFT. Ani defrag API to neumi. Cili se smejte, ale na Windows je to jeste horsi, nez na Linuxu. S fragmentaci na NTFS je to tak, ze k ni dochazi v docela velke mire, i kdyz mene, nez na FATu. Rozdil je v tom, ze vykonove se to na NTFS mnohem mene projevuje, nez na zminene vykopavce FAtu.

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.

pokial iba subory vyhodite a date spat kopirovanim, tak pydefrag pomoze

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.

a cim to teda bylo?

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

Skôr je to spôsobené tým, že XFS journaluje len metadata (nie dáta samotné). Blok plný núl zrejme znamená, že XFS prealokovalo nejaký nový blok/extent, táto transakcia prebehla, ale už nestihol prejsť samotný zápis (a pôvodné dáta ležia niekde inde na partícii). AFAIK jediný FS, ktorý môže journalovať aj dáta súborov, je ext3 (ordered mode), čo ale zase spôsobí, že sa môže kľudne stať, že bude súbor zapísaný napoly (po hraniciach blokov).

Tento problém sa dá jednak riešiť cez transakčné FS API, ktoré je "z bežných FS" implementované v Reiser4 a NTFS (tuším ešte ZFS?). Teoreticky by niečo podobné bolo jednoducho implementovať do log-structured FS (a la JFFS2), ale tie nie sú vhodné pre bežné (seekovacie) disky.

Typicky sa transakcie na FS riešia copy-on-write s tým, že po uzavrení "user" transakcie (z aplikácie) nasleduje FS-metadata transakcia, ktorá "poprehadzuje pointre" zo starých dát na nové dáta (typicky veľmi rýchle).

Transakčné FS API je fajn...ale prišlo tak neskoro, že to už prakticky skoro nikto nevyužije - pr. databázy si riešia transakcie vo vlastnej réžii. Kto chce, vyrobí si "poor man's transaction" "simuláciou" copy-on-write - všetky súbory zapíšem s novými menami, zmažem staré a premenujem novo zapísané (neni to samozrejme atomické, ale pre bežné desktop aplikácie dostačujúce, plus niektoré aplikácie to fakt tak robia).

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?

ako som uz spominal, pydefrag nedefragmentuje uplne, iba pod urcity treshold tj 1 fragment na 2 megabajty. pokial sa defragmentuje nejaka CF karta, ci usb kluc, tak by to nemal byt problem pouzit toto, aspon mam dojem, ze to ludia pouzivali. na ntfs to nefunguje (nema informaciuu o fragmentacii)

neviem, ludia sa to obcas pytaju na forumoch.

No jo, lide se na forech obcas ptaji, jestli je mozno otehotnet pri felaci.

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.

Dalsi duvod, proc jsem na Linuxu.

No, já bych možná připomenul, že na Windows už se nějaký ten pátek dá používat i novější FS než FAT.

Ale jinak Váš příspěvek je v kontextu ostatních, které se hádají o tom, že na Linuxu není kloudný defragmenter žádný (kromě "kopírovacího" přístupu), docela vtipný.

1) NTFS se taky fragmentuje
2) Reiser4 se ani po 2 letech nezfragmentoval tak, abych to musel resit. 0,5% fragmentace nebudu resit

1) Jistě. Tvrdí tu někdo opak?
2) Ale jak tu už dost lidí psalo, záleží na způsobu využití FS a na jeho zaplnění. Jak to je tedy u Vás?

Ruzne velke soubory, casta obmena - nedavno jsem stahnul dve DVD o 4,2GB kazde, po tydnu jsem je vypalil a smazal. Vcera jsem odstranil adresar s 13339 soubory (2,9GiB celkem), ktere se tam valely uz asi pul roku. Casto menim hudbu. Mailserver ani jine zateze disku neprovozuji, az na Portage. FS mam bez defragu uz dva roky. Takze takove to prumerne domaci zatezovani...
FS je reiser4, system Gentoo.

Zapomnel jsem, ten disk je 20GB, zaplneni je od cca 50% do 100% (kdyz neco zapomenu vcas vypnout, stalo se mi to uz dvakrat, nasledky zadne), vetsinou okolo 80%. Na tom samem disku a se stejnym chovanim uzivatele byly predtim Windows XP, se kterymi porovnavam. Byly originalni, jestli to Hulana nebo LO zajima.

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.

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

Proč? Programy snad nepřistupují ke konkrétním sektorům, ale drží si nějaké file descriptory a to že tomu "něco" bude přehazovat soubory pod rukama vůbec nemusí vidět. (Jo, tak bude to složitější na implementaci než kopírování, ale nevidím důvod, proč by to nemělo jít.)

Podle me nejlepsi defrag je koupit si jeste jeden disk a vsechno na nej zkopirovat a pak to prekopirovat zpatky.

Jistě. Taky nejlevnější. A hlavně to budu určitě dělat na běžícím systému.

Proč? Programy snad nepřistupují ke konkrétním sektorům, ale drží si nějaké file descriptory a to že tomu "něco" bude přehazovat soubory pod rukama vůbec nemusí vidět. (Jo, tak bude to složitější na implementaci než kopírování, ale nevidím důvod, proč by to nemělo jít.)

Ano, existujú online repackery (defrag), napr. pre XFS, plánované (tj. neviem v akom stave je implementácia) sú pre Ext4 a Reiser4.

Ono najlepší "defrag", čo sa týka vplyvu na výkon je aj tak zobrať súbory, ku ktorým jedna aplikácia/proces pristupuje a prekopírovať ich (typický alokátor spraví to, že sa ich bude snažiť naalokovať blízko seba, čím spôsobí menšie seekovanie). Naopak "obyčajný defrag" nemá ani šajnu v súvislostiach ktorý fajl sa bude ako používať, takže ich síce môže defragmentovať, ale zároveň rozhádzať po disku (a bude to seekovať viac).

BTW defrag mal skôr zmysel v DOSe, kde sa čítal jeden fajl v jednom momente (dnes je to tak skôr kvôli dobrému pocitu modulo extrémne prípady, keby sme rozsypali fajly po disku jak čaj). Moderné FS alokujú fajly nie po jednotlivých blokoch, ale po extentoch (premenlivo dlhý súvislý pás blokov), tu delayed allocation dosť pomáha proti fragmentácii preventívne.

Pr. XFS má niekoľko B+ stromov, podľa jedného hľadá voľný extent najbližšej vhodnej veľkosti, podľa druhého hľadá extent/blok v blízkosti predchádzajúceho, tie B+ stromy sú tuším per AG (allocation group, ale už si to nastropro nepamätám).

Počet fragmentov na MB apod. je absolútne nič nehovoriaca metrika (nehovorí nič o čase seeku/"vzdialenosti" medzi fragmentami, nezaoberá sa o koreláciami medzi čítaním súborov atď).

IMHO je v systemovem adresari nejaky soubor, ve kterem je napsane poradi souboru na disku, jmenuje se layout.ini

Pri zaplneni disku uvolni NTFS pul prostoru predalokovaneho pro MFT. Pokud to nestaci, uvolni pul zbytku a tak dale, az kam muze. Kdyz pak dojde k uvokneni disku a NTFS potrebuje zvetsit MFT, udela to, kde je misto. Pokud mate disk, ktery bezi casto na hranici kapacity, muzete mit MFT rozhazene na disku po malych kousich (ja mel jednou asi 4, vic se mi nepovedlo). Defragmentovat MFT nelze jinak, nez znovuvytvorenim FS. Otazka je, jak dalece hrozny dopad ma fragmentace MFT na vykon.

Máte špatné informace. Fragmentace MFT nastane až když je partition prakticky plná, a to už je výkon stejně v háji. Windows XP a vyšší umí defragmentovat MFT, ve Windows 2000 to uměly nástroje typu Diskeeper (ovšem jen na odmountovaném volume).
http://support.microsoft.com/kb/227463
http://support.microsoft.com/kb/174619
http://www.amosdec.com/pdf/DIVERS/DSKvsW2000defrager.pdf

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.

Zkuste zagooglovat a najit defragmentor od Cyrillic Software. Firma jiz asi neexistuje, ale ten defragmentor se jeste nekde obcas vali. Je z doby Win NT, ale asi by chodil, minimalne na XP. Delal v podstate to same, co defrag z Windows 2000 a vyse, predpokladam, ze nemel dementni omezeni na FS s default allocation unit, jako ve Windows 2000 a chodil z command line. Akorat se musela najit ta spravna kombinace options, aby to skutecne zacalo defragmentovat. Me se ho jeste podarilo najit tady: http://download.enet.com.cn/speed/toftp.php?fname=060481999090101. Je to sice cinsky, ale pokud snad cinsky nahodou neumite, kliknout na modre tlacitko se zlutou sipkou zvladnete. Me zabral hned prvni download link. Ovsem pozor, je to Ciny. Dal bych to na mesic do karanteny a pak proscanoval.

No, uz par let to nepotrebuju, mam Linux, k Winum lezu leda tak ve skole.

Defrag ve Windows 2000 nešel s bloky většími než 4kB, s menšími ano. Od Windows XP toto omezení neexistuje. Předpokládám, že Diskeeper ho neměl ani ve Win2K, ale zkoumat to nebudu.
http://support.microsoft.com/kb/227463

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

este poznamocka. fully defragmented u neho znamena, ze je pod tresholdom fragmentacie. tj 0.5 fragmenta na megabajt, tusim.
nebolo by zle dorobit do (asi) rsync moznost, nech sa pokusi ulozit s co najmensou fragmentaciou, a tiez nastavit zavyslos od inych files, aby ich umiestnoval blizko seba

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

Provedl jsem jeste nejake experimenty a funkce tohoto defragmentatoru se vyznamne lisi podle aktualni situace na disku - zkusil jsem defragmentovat adresar a ani po 10 cyklech se nedostal pod 47%, pak jsem smazal na disku (zabrano bylo 79%) nekolik vetsich souboru a provedl jsem defrag znovu. Vysledek - 5.5%. Fuknce teto defragmentace zavisle ciste na algoritmu pouziteho souboroveho systemu je tedy dost diskutabilni.

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.

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