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

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

To je důvod, proč Windos provádějí i reorder souborů s ohledem na četnost jejich používání. Neděje se tak pro všechny soubory, ale určitě třeba pro ty, které jsou použité při startu OS (a myslím ještě pro aplikace).

Těžko budete hledat extent nejbližší vhodné velikosti, když netušíte, jak bude soubor velký. A přiznejme si, zpravidla to nevíte. Aplikace vytvoří prázdný soubor, a mnoho FS už v tu chvíli alokuje (NTFS udělá jen záznam v MFT). Zapíšete pár byte nebo kB, postupně připisujete... Jestli víte o alokátoru s rozostřeným viděním času, rád si o něm přečtu. Zatím jsem četl jen o výtazích s rozostřeným viděním času ve Stopaři ;)

"To je důvod, proč Windos provádějí i reorder souborů s ohledem na četnost jejich používání. Neděje se tak pro všechny soubory, ale určitě třeba pro ty, které jsou použité při startu OS (a myslím ještě pro aplikace)."

Je k tomu nejaký link jak presne to robia? (robí to nejaký explicitný proces, sám NTFS driver, meria sa počet prístupov, počet čítaní, počet čítaných blokov...?) Inak mi neni jasné, načo sa pozerá na súbory použité pri štarte, tie budú spravidla úplne iné než tie, ktoré sa budú používač pri štarte (až na psychologický efekt zrýchlenia štartu o trocha).

XFS má stratégiu podľa alokátoru, inak sa bude správať u defaultného a inak u filestreams alokátoru. Je pravda, že uhádnuť dopredu veľkosť súboru obecne nejde, ale s delayed allocation sa dajú aspoň naalokovať maximálne dlhé extenty až sa mine pamäť (ďalšie sa budú hľadať typicky v rovnakej AG, v závislosti od alokátoru a voľného miesta). Allocation groups (AG) sú volené tak, aby v rámci nich bol seek krátky (po začatom zápise sa až po zaplnení "preskočí" do ďalšej AG).

BTW vytvoriť záznam o existencii súboru je možné okamžite (s alokáciou miesta sa dá počkať až sa rozbehne zápis, jak to scheduluje XFS).

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

K tomu se vrátím, teď bohužel není kdy :(.

Čekat s alokací "až se mine pamäť" (předpokládám až se naplní paměť) je špatně. Vede to k hromadě dirty pages, a když pak z nějakého důvodu paměť potřebujete, musíte nejprve zuřivě hrabat po disku (a ten kdo tu paměť potřeboval čeká). Navíc v případě problému typu výpadku proudu přijdete o velkou spoustu dat, což je nepřijatelné. OS se naopak má snažit, aby data dostal na disk bez zbytečného prodlení. V případě serverových aplikací by pak mělo být zaručeno, že když se navrátí synchronní volání, případný výpadek napájení nezpůsobí ztrátu dat (aneb proč jsou důležité baterií zálohované řadiče).

NTFS drží metadata souboru v MFT, a vlastní data buď v MTF (pokud je jich málo), nebo zvlášť. Protože alokační blok s metadaty stejně musíte modifikovat při změně dat souboru, je původně-malý soubor (v řádu kB - musel bych se podívat) přímo v MFT spolu s metadaty. Když se zvětší, bude se alokovat mimo MFT (včetně dat zapsaných původně do MFT), záznam v MTF se zaktualizuje, a tam uložená data souboru zneplatní. Tím je zajištěno, že malé soubory jsou pohromadě se svými metadaty, což je rychlé. V běžném scénáři to nevede ke ztrátě výkonu.

Odkladať alokáciu naopak preukázateľne zvyšuje výkon. Aby sme si rozumeli: XFS má vlastný buffer, takže samozrejme nespotrebuje celú voľnú pamäť. Druhá cache je u I/O vrsty, ktorá robí page caching pri mmap-e, ale tá tiež nespotrebuje všetku voľnú pamäť (dá sa nastaviť akú veľkú časť maximálne má použiť).

Samozrejme delayed allocation je blbá pri výpadku prúdu apod. Samozrejme je stále možné otvárať súbory alebo mountiť FS sychrónne (čo zase brzdí výkon). XFS má naviac "writebarrier", čo umožňuje dokonca zaistiť, že dáta nezostali len v HDD cache a že sa dostali "na platne". Nepoznám iný "bežný" FS s touto featurou.

XFS a Reiser3,4 robia tiež tail-packing (tj. držia malé adresáre/súbory hneď pri metadátach, aj keď u XFS neviem či to robí aj pre súbory). Tail-packing je dobrý pre zmenšovanie fragmentácie a ak read o hodne prevyšuje write/append (kvôli výkonu).

Inak mať MFT na začiatku partície neni moc dobrý nápad, pretože sa potom musí moc seekovať medzi čítaním dát a metadát.

Shodneme se, že odložená alokace způsobí problém v případě události typu výpadek proudu.

Ve Windows můžete použít CreateFile s flagem FILE_FLAG_WRITE_THROUGH.

MFT by hlavně neměla být příliš fragmentovaná, což NTFS celkem dobře zajišťuje.

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

Ne, nemám takový pocit. A to mimo jiné proto, že vím, jak vypadá MS API pro defragmentaci (které používá mimo jiné defrag vestavěný ve Windows).

http://msdn2.microsoft.com/en-us/library/aa363911(VS.85).aspx

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