Vlákno názorů k článku
Jak je to s defragmentací na Linuxu?
od ... - O tomto hovorim uz niekolko rokov a kazdy...
-
mm (neregistrovaný)Je to hloupost.
Prinos te defragmentace je zanedbatelny, ze ani nestoji za to se tomu venovat.
Cas od casu se vynori radoby senzacni clanek kdesi na nejakem blogu s radoby "testy" a to je tak vsechno. Pro "odborniky" na diskusich je to duvodem si porvat, ze i na Linuxu je nutno neustale defragmentovat (a tak si zvysit sve winwsove sebevedomi) :-). Schvalne se zkuste zeptat primo autoru souboroveho systemu (ext2, ext3) na jejich nazor :)
Mimochodem ani v pripade Windows na NTFS neni defragmentace nutna - i tam to ma casto spise placebo efekt. -
Uživatelka si přála zůstat v limbu (neregistrovaný)No, když máš 20MB soubor, tak ho jedním vrzem přečteš za půl sekundy. Když má 600 fragmentů (se stává, ne každý si nechává 1/3 disku nevyužitou pro lepší pocit), protáhne se ta doba o nějakých +-8 miliseknund na jeden fragment. Což asi docela poznáte.
-
Už se to tady řešilo níže... Neznám OS dokáže zapsat 20MB soubor na 600 fragmentů u normálně zaplněného disku (<85-90%). Pokud máte na disku 0,01% volného místa, tak bych to chápal, ale to pak máte úplné jiné problémy s nejvyžší prioritou než hloupou fragmentaci.
Zůstaňme v příkladech v reálných mezích. -
Lael Ophir (neregistrovaný)To se naopak stane celkem jednoduše, zvláště pokud je vysoká fragmentace volného místa (což s procentem zaplnění nemá nezbytně souvislost). Založte si soubor o velikosti 1 bloku, zavřete ho, odmountujte FS, přimontujte, prodlužte soubor o blok, a tak pokračujte, až se dostanate na 20MB. Alokátor samozřejmě na začátku nevěděl, že soubor bude mít 20MB, takže pro něj nehledal 20MB místa. Zpožděná alokace nezabere, protože jí spolehlivě zabijete zavřením souboru, unmountem a mountem (nebo tím že soubor zavřete a budete nějakou dobu čekat). Jak soubor postupně poroste, situace se bude opakovat. Zpočátku možná dojde k přesunutí souboru na jiné místo (záleží od FS), ale časem se začne fragmentovat. Pochopitelně kdybyste založil rovnou 20MB soubor, dopadlo by to o dost lépe, protože by alokátor hledal souvislých 20MB.
-
To také není vyloženě příklad z praxe, že. To, co je popsáno výše není tak úplně pravda. Alokátor u takové postupu samozřejmě netuší, jak velký bude zapisovat soubor - potud souhlasím. Na druhou stranu "inteligence" alokátoru není tak nízká, aby zapisoval do místa kde ihned následuje další fragment souboru. Takže opakovaným připisováním dat k souboru se samozřejmě zapisuje za poslední data - dokud je to možné - pak alokátor hledá jiné vhodné místo.
Výše popsané bude obtížné simulovat i v případě, že takto budu rozsekávat souborů více najdnou. Protože každý soubor se bude zapisovat na úplně jiné místo disku. Tudíž to nebude ABABABABABABAB, ale AAAAA a někde úplně jinde zase BBBBB.
Co se týče poznámky o silně fragmentovaném nebo zaplněném disku, tak jsme zase v oblasti extrémů, že ano.
Ale mám takové tušení tuto "inteligenci" by měl zvládat i NTFS. Pokud si matně pamatuji, na na NT4.0 ani nebyl defragmentační nástroj na NTFS. -
Lael Ophir (neregistrovaný)Jistě, alokátor bude počítat s tím, že soubor bude mít více než jeden blok. V případě NTFS nejprve vyhradí místo v MFT, po zvětšení souboru alokuje několik bloků, atd. Ale přesto bude fragmentace vyšší, než když alokujete rovnou 20MB, protože jak sám píšete: "opakovaným připisováním dat k souboru se zapisuje za poslední data - dokud je to možné". Když to možné není, dojde na další fragment, a až nebude místo tam, situace se bude opakovat. Naopak pokud na začátku vytvoříte 20MB soubor, bude s daleko vyšší pravděpodobností uložen souvisle.
Alokátor NTFS je popsán v MS KB article 841551. -
Lael Ophir (neregistrovaný)To asi tak trochu kecáte. Windows Explorer (a obecně Windows API) totiž při kopírování nejprve alokuje soubor cílové velikosti, a pak teprve do něj zapisuje.
Ostatně jsem to právě zkusil. Jeden soubor 2.7GB, druhý 1.4GB, oba kopírovány najednou. Výsledek? Oba jsou bez fragmentace, "měřeno" pomocí contig -a. -
Fragmentace souborových systémů jako Ext2, Ext3, ReiserFS apod. začíná až někdy u 80% zaplnění disku. Znatelná fragmentace začíná až u 90-95% zaplnění. Průměrná fragmentace je zhruba 2%. A pokud si pořádně přečteš ten "defragmentační" skript, zjistíš, že fragmentovaný soubor jen zkopíruje a původní smaže. Tohle opakuje několikrát. A proč to funguje? Protože kopírováním se rozumné souborové systémy částečně defragmentují samy.
Zakažte už někdo Pavlu Chalupovi psát zprávičky, ať se tu neobjevují takové pitomosti pořád dokola.
