Vlákno názorů k článku
Defragmentace disků v Linuxu

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