Hlavní navigace

Názor ke zprávičce Microsoft vytvořil stabilizátor zrychlených videí od Sten - na prvním místě jde o stav před 11...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 15. 8. 2014 18:12

    Sten (neregistrovaný) ---.parawide.eu

    na prvním místě jde o stav před 11 lety. Na druhém místě není důvod mít první zápis velkého souboru typicky menší než jeden cluster. Pokud soubor vytváříte, první request může klidně mít pár MB.

    Typicky třeba výstup z enkodéru videa, z multiplexeru, ze síťového proudu nebo i z kompresního algoritmu (OOXML) nemá bloky o velikosti několika MB.

    Pokud ho kopírujete, na prvním místě vám CopyFileEx nastaví velikost cílového souboru stejnou jako u zdrojového, plus se používají I/O requesty s velikostí v MB, nikoliv kB.

    Takže pokud tomu FS řeknete, že bude mít soubor tolik a tolik dat, tak je dokáže naalokovat nefragmentované. Hmm, to asi musí být hodně komplexní algoritmus :-)

    fakt? Nic takového jsem v dokumentaci neviděl. Jestli vy ano, tak to sem hoďte. Jestli ne, můžete napsat test pomocí Defrag API C# wrappers (a nechat si u toho zdát, že byste měl něco podobného k dispozici na Unixech), a já slibuju, že si pak ten váš test sjedu.

    V dokumentaci to není, je to vidět z obrazu disku defragmentačních utilit. Soubory vytvořené po sobě různými aplikacemi jsou za sebou.

    Proč bych si o tom měl nechat zdát? Vidím kód, který importuje nějaké funkce z kernel32.dll. V Linuxu použijete libext2fs (třeba i v Pythonu), nebo pokud to chcete naskriptovat v shellu, tak ex4defrag umí podávat informace o jednotlivých souborech. Jaký je v tom rozdíl?

    problém je v tom, že když máte po disku náhodně roztroušená data, tak nebudete mít ani ty 2GB souvislého volného místa. Když vezmu svůj disk (450GB, 180GB dat, 450k souborů), s vaším přístupem byste měl při ideálně souvislém ukládání souborů a zanedbání metadat a adresářů souvislé bloky o velikosti jen 630kB, výpočet (450G-180G)/450k. Když ten disk zaplníte stejným způsobem na dvojnásobek, tedy na 80% kapacity, bude souvislé bloky volného místa jen okolo 100kB. A to na disku, kde máte ještě 90GB volného místa, plus jsme zanedbali ta metadata, která chcete také ukládat po celém disku. Zkuste si pak vytvořit 1GB DB soubor - bude z něj řezanka. A se zvyšujícím se procentem zaplnění disku se to bude prudce zhoršovat. Je už jasnější, že umisťovat soubory náhodně po disku je nesmysl?

    Ty data nejsou roztroušena náhodně, ale organizovaně. Pokud máte soubor, který je zavřený a od vytvoření se nezměnil, asi se měnit nebude a můžete šoupnout další hned za něj. Nicméně pokud máte soubor otevřený pro zápis, asi nebude zrovna ideální strčit další soubor od jiné aplikace hned za něj.

    aha, takže najednou se hodí mít metadata víc dohromady, a netrousit je náhodně po disku. A přitom jste ještě minule NTFS vytýkal, že se snaží je držet pohromadě.

    Pohromadě máte ta metadata, která se pravděpodobně budou používat najednou. NTFS rve dohromady všechna metadata bez ohledu na to, kdy je kdo bude používat.

    tak silné tvrzení by to chtělo podpořit velmi dobrými argumenty :)

    Co třeba těmi měřeními fragmentace, které jsme zde uvedli?

    kupodivu to není problém ani ve Windows, vizte ENABLE_QUICK_E­DIT_MODE. A pokud chcete použít na konzoli myš jako pointer, stačí zavolat SetConsoleMode s ENABLE_MOUSE_INPUT, budete pak dostávat events. Nicméně původní pointa byla ta, že GUI nástroje instalované s UNIXy byly (a často nadále jsou) ve srovnání s Windows naprosto tragické, takže je pokrytecké Windows vyčítat, že neobsahovaly víc nástrojů v lepší kvalitě.

    Kupodivu to problém je, protože v Linuxové konzoli funguje copy&paste či drag&drop i bez nějakého nastavování, myš funguje i přes SSH a taková terminálová aplikace funguje i tam, kde žádné GUI není (hodně štěstí při spouštění aplikace používající SetConsoleMode v DOSu).

    GUI nástroje v UNIXech byly tragické, protože nebyly potřeba, zatímco ve Windows byly tragické a navíc jste neměl moc na výběr.