Vlákno názorů k článku Defragmentace disků v Linuxu od highway - Dekuji za clanek, mam dotaz: Jak defragmentovat v...
-
alpha (neregistrovaný)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)
-
alpha (neregistrovaný)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. -
alpha (neregistrovaný)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.
-
Jirka (neregistrovaný)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. -
abyssal (neregistrovaný)
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 ;) -
abyssal (neregistrovaný)"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). -
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. -
abyssal (neregistrovaný)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. -
JardaP (neregistrovaný)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
-
alpha (neregistrovaný)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.
-
JardaP (neregistrovaný)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.
-
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
ČLÁNKY DO MAILU