No nevím, já být na straně výrobce OS, tak bych to tak nebagatelizoval, memory leak je vždy poměrně průser a je úplně jedno, jestli je v malování nebo chkdsk. :-)

Xspy: předpokládám, že Vy osobně jste zcela absolutně neomylný a nikdy jste neudělal chybu, že ano?

To neni chyba. To je jen blbe schovany kurvitko ktery si do OS prosadily vyrobci pameti aby si lidi zacali myslet ze i 4GB je malo ;)

Problem nastava jen a pouze v pripade parametru /r
Dle vyjadreni MS byla vetsi spotreba pameti umyslem (v kazdem pripade zustane 50MB+ volnych - zkousel jsem), predpoklad je ze kdyz nekdo pouzije /r chce to mit rychleji hotove a jinou praci behem kontroly neplanuje... podle meho nazoru to snad ani chyba neni :-)

ViktorN: To je jasny, ze neudeal, kdyz ten osel za celej svuj zivot nic nevytvoril

Bobrnautus: Tys to debugoval, že víš, že tam jsou memory leaky nebo jenom tak meleš nesmysly?

2Honza748: clovek nemusi programovat windows, aby mel zkusenosti s ladenim pametove narocnych aplikaci, proste je to pruser :)

Ako vy Cesi hovorite: "Kdepak asi udelali soudruzi z Redmondu chybu?" Tolko to ladili a hladali "zlaty kod" az to dobabrali... A mozno je to zamer, ako piratom trosku "osladit" zivot pri pouzivani leaknutych zostaveni od GRP a WZT... Ktovie, co este vyplave na povrch po intenzivnom testovani 7-ciek. Stale plati, ze prva ako-tak pouzitelna verzia akychkolvek doteraz vydanych okien, ma suffix SP*

WIFT: Mozna se do pameti uklada komplet adresarovy strom - to by teoreticky mohlo mit nejake urychlovaci ucinky. Ale tech souboru by muselo byt vazne hodne pokud by tohle ucpalo celou pamet ...

No a co? Konečně aplikace, která využije jinak z poloviny(čí více) prázdnou paměť na něco užitečného... Jak je patrné, aplikace si obsazenost hlídá. Dle mého dohadu ti, kteří mají zkušenost, že se jim objevilo BSOD, měli hlavně problém s pamětí na HW úrovni ( např. přetaktování apod.) nebo zároveň s chkdsk spustily jinou žravou aplikaci např. Firefox nebo začali pracovat s Adobe Photoshop, apod. a Windej-si spadli díky chybám v těchto aplikacích...

Honza478: Máš pravdu, v debuggeru jsem to opravdu měl a podle mě to memory leak je. Ale nejsem neomylný, schválně to zkus taky, třeba to zvládneš líp.

to randomofamber:

Je to chyba "ako Brno", pretoze aplikacie ako chkdsk vyuzitim neviem akeho mnozstva RAM nijako nezrychlis, kedze hlavnou brzdou/bottleneck-om je praca so samotnym HDD...

O důvod víc, proč nepoužívat chkdisk

Zase takova fatalka to neni ... ja chkdsk pouzival jak v RC tak v RTM, a 8 giga RAM to nesezralo ani vzdalene ... no a pokud nekdo pouziva 32bit Win7, tak dobre mu tak (-:

randomofamber: Podle mě si to aplikace nehlídá, jenom systém ji nedovolí alokovat víc paměti (těch 50MB si nechá jako rezervu, kdyby něco potřeboval kernel, pro LDT tabulky jiných aplikací atd.)

Bobrnautus: ok, stahnu si symbols pro rtm a vyzkousim.

Už se těším, až někdo zveřejní, kde je v tom kódu chybka (memory leak) a natrhne MS prdel. Nicméně do té doby, něž to někdo prokáže, bych asi s neprokazatelnými výroky posečkal. Pokud to bug je (což je pravděpodobné, ale ne prokázené), tak si MS svým vyjádřením ušil z ostudy kabát. Nicméně z mého hlediska to určitě není kritická chyba. Přes deset let dělám (možná dobře, možná špatně) správce pár počítačů a chkdisk s pařepínačem /r jsem nepoužil ani jednou. Pravda, kdybych to dělal často, tak je to problém ...

Spirit_pcf: Zajímavé. Já mám disků 6 a rtm mi tu běží jako z praku.

Toto není chyba, toto je vlastnost.

Vždyť je to jednoduché, testování povrchu disku skoro nikdo nedělá (a když už, tak by dnes měl použít utilitu výrobce), takže se nelze divit, že chybu nikdo neodchytl. Navíc test povrchu fakt není k tomu, aby se u toho pracovalo.

kert: Chkdsk je systémová utilita už od dob Dosu. Jádro to sice není, ale k základní sadě nástrojů systému to patří. A bez parametru /r si ho Windows pouštějí sami po každém nekorektním vypnutí.

Komanche: souhlas. Já teda doufám, že mi rtm vydrží dýl, než do března ;-)

cafte lidi, kto mi poradi. zhanam nejaku (idealne free) utilitku kde by som vedel sledovat I/O write/read hodnoty diskov v real time. idealne podobne ako DU meter na network usage. Poznate take nieco?

Takže si to shrňme, nový checkdisk lépe využije dostupnou paměť a je tedy rychlejší.
 
Jestli se nic "lepšího"na W7 vyhrabat nepovedlo, tak to bude asi velmi kvalitní systém...

Azazel: Děláš špatné závěry. To, že dokáže obsadit celou paměť, ho rychlejším neudělá. Jeho rychlost je daná v podstatě jen rychlostí disku, obsazení paměti je chyba, která se vyskytla až ve finální verzi, předtím zde nebyla.

Jirka: Ono je důležité vědět jak to funguje
varianta 1, přečteš jeden byte, zapíšeš byte, přečteš byte a porovnáš - celé to zopakuješ pro všechny byty na disku
varianta 2, přečteš 1GB, zapíšeš 1GB, přečteš 1GB a porovnáš - celé to zopakuješ pro všechny GB na disku
 
První varianta (schválně trochu extrém) bude paměťově zcela nenáročná, ale bude trvat půl roku a zatížení disku bude enormní. Je to prostě normální optimalizace úlohy, která se dělá ve výjimečných situacích, při které se s počítačem stejně normálně nepracuje (ke všemu se na kontrolovaný disk nedá přistoupit) a u které jde v první řadě o maximální rychlost.
 
Očekával bych, že se najde nějaký novinář, který místo toho, aby tuhle "aféru" podesáté opsal, vyzkouší, jestli a o kolik je ten nový checkdisk rychlejší než starý...
 
PS: kdyby to byl memory leak, tak není nic snazšího, než to zjistit a už by to na beton někdo udělal.

Konecne neaka aplikacia vyuziva ram na plno! Akurat pri pri tejto to nema zmzsel ako pise Jirka1.:))))

Azazel: Příklad je to hezký, ale nesmyslný. Na tohle ti stačí alokovat maximálně v řádu stovek MB. Při 100MB bufferu a přenosové rychlosti 100MB/s si disk navíc seekne jednou za sekundu. To je zpoždění max 20ms - 2% času. Mnohem víc udělá samozřejmě fragmentace disku.

Spirit_pcf: memtestem? Už jsem měl v ruce několik ramek, které v memtestu prošly v pohodě a ve windows ani omylem.

On existuje sebevrah, který tento příkaz používá? Co pamatuji, už z dob dosu, tak chkdsk byl nejsnažší způsob, jak sejmout souborový systém :-) :-) Ten příkaz nikdy pořádně nefungoval!!
Na prověření disku exsistují utility výrobce.
Memtest - je hodně nespolehlivý. Často chyby nenajde. Ale na každé nově sestavené mašině ho přes noc pustím. Ale nespoléhám na něj. Spíš spoléhám na Goldmemory - nejtěžší test. Ale minimálně to musím nechat běžet přes noc - víkend je lepší. V práci mi ho koupili a nedám na něj dopustit. (kolik ramek mi vyřadil - v Alfě se vždycky tváří podivně ale fotky je přesvědčí, aby okamžitě navalili jiné. Jen OCZtka jsem měl vadné jen jednou. - moc často je nekupuji).

Naprosto nepodstatná věc. Jsou horší - např. nejde z timeline vyexportovat video ze střižny a tak holt zůstanem u vyladěných XP.

Zepheer: Od dob Dosu se dost změnilo a na NTFS zas tolik utilit není. Navíc - pokud Windows uvidí chybu, spustí chkdsk sami s parametrem /f. Chkdsk /r zase pouze testuje povrch, zatím jsem neměl důvod kvůli tomu použít soft od výrobce disků. Bad sectory vždy našel spolehlivě a destrukce dat také neproběhla.

Jirka1: A to si myslíš nebo si to zkoušel?

Ona je řeč o defragmentaci?

BTJ sice popletl defragmentaci s kontrolou disku, ale jinak má 100% pravdu

To je blbost. Nějaký ňouma někde napíše, že chkdsk bere spoustu paměti, aby byl rychlejší a další ňouma se toho pak chytne a rozhlašuje to. Tuto blbost může ale napsat jenom někdo, kdo tomu absolutně nerozumí a nemá s tim absolutně žádné zkušenosti. A jako bonbónek k tomu ještě napíše, že když jiná aplikace bude potřebovat paměť, tak jí chkdsk/defragmetace uvolní... Je sice pravda, že pokud při čtení souborl zvětšíme buffer/cache, tak se čtení/zápis zrychlí, ale tohle má určitou mez, která je v řádu jednotek megabajtů. A ne rozhodně několik giga, jak sežere chkdsk. V tomto případě se jasně jedná o memory leak, kdy aplikace zřejmě alokuje další paměť pro buffer místo toho, aby použila buffer předchozí a nebo jej alespoň dealokovala. Další možnost je, že chkdsk nejdřív načte celý disk do paměti (což je blbost), jenže i v tomto případě bude zrychlení takové, že bude na úrovni chyby měření... Nejideálnější režim přístupu na disk pro aplikace typu chkdsk jsou asynchronní operace (a věřím, že je MS použil), kdy k výraznému zrychlení dochází při zvětšování bufferu zhruba na 2 MB (čili 4 MB, protože asynchronní operace vyžaduje 2 buffery). Při dalším zvětšování je už zrychlení minimální, a pokud se zvyšuje do řádů několika stovek MB, tak dochází naopak ke spomalování. Takže v aplikace chkdsk jde jasně o bug.

Muscle: Tys to měřil? S výkonem aplikací mám své zkušenosti ... takže vím, že co se nezměří to zkrátka není pravda i kdyby sis to tisíckrát rozumově zdůvodnil. Mě naopak přijde zcela logické, že čím větší blok ci načtu do paměti, tím to bude rychlejší ... a mez je spíše v řádech gigabytů než megabytů.
Tvůj problém je, že píšeš o čtecích/zápisových bufferech, o kterých je to ovšem jen částečně - checkdisk potřebuje číst několikrát to samé a potřebuje to v paměti porovnávat - a tam platí, že čím víc toho načte do paměti tím lépe.
 
Pokud by se jednalo o memory leak, tak už by se to vědělo ... není nejmenší problém takto masivní memory leak odhalit a úplně k tomu stačí ten program, zdrojáky nejsou potřeba.
 
PS: Nemohl by se toho někdo z redakce cdr.cz ujmout a vyzkoušet o kolik je to rychlejší? Buďte trochu investigativní ;)

Azazel: neměřil jsem konkrétně chkdsk, ale čtení a zápis souborů v mém posledním projektu, který potřeboval pracovat se soubory v řádech několika GB. Načtení a práce se souborem musela být, co nejrychlejší (po různých optimalizacích jsem načetl 2,5 GB soubor za 30 sekund. Jestli to jde rychleji, to nevím, ale velikost načteného bloku měla vliv minimální). A pokud byl buffer dostatečně velký (několik málo MB), tak vyšší velikost už neměla absolutně žádný vliv na rychlost. Když měl buffer několik set mega, tak dokonce docházelo ke spomalení (měřeny synchornní operace, asynchronní operace a paměťově-mapované soubory)

BTJ: ano, ono je celkem logické, že když je to cílené chování, tak na něj Microsoft chce vydat záplatu.

...a teď k té chybě :-)
Jako laika mne poučte, proč při procházení sektorů disku pro ověření jejich závadnosti, potřebuji takový buffer? Co by potom potřeboval takový defragmenter? Terrabyty? Jak to tedy, že v nižších OS takové nároky na kontrolu povrchu nejsou. Jakto, že v XPčkách není taková paměť potřeba? To je kontrola povrchu ve W7 oproti XP o tolik rychlejší? Nejde mi teď o to, zda je, ale při porovnání nároku na paměť chkdsk v XP a W7 (vyjádřeno třeba v procentech...) tak jestli je odpovídající zrychlení? Osobně to NEMUSÍM měřit, výsledek mi je znám předem (to znamená, že ne vše se MUSÍ změřit aby to byla pravda :-), takže nemudrujte o tom, čím to je, ale zda výsledek odpovídá nárokům. Z toho se pak dá vyvodit, zda ten SW funguje tak, jak chtěli autoři :-D Tož takto by měla znít diskuse.... :-p

Nvíc se ten problém objevuje pouze při testování jiného než systémového disku. Taktéž cílené chování?

Já mám jen obavu, že nejde o chybu samotného chkdsk.exe ale o chybu diskového subsystému Win7 a to by bylo jiné kafe...

Muscle: na systémový disk nejde za běhu checkdisk vůbec pustit - pustí se po restartu před startem systému ... a moc bych se divil, kdyby se to chovalo jinak
 

Wift: pokud to bude rychlejší, tak proč by tu paměť nevyužil? Ještě se nikdo nenamáhal dokázat, že to rychlejší není

... a protože to nikdo nezměřil, nemůže to být pravda :-) Nebo jak si máme my všichni, co věří v teorii relativity, tento výrok vyložit?

Máček: Trik je v tom, že věda (matematika, fyzika, apod.) je deterministická .... počítače nejsou ;)

Jenže matematika je taktéž o logice a to je zase doména počítačů. Kontrola povrchu na XPčkách mi na 160GB disku trvá hodinu při 134 146 souborech. Chkdsk si vezme v PEAK 13MB WS. Pokud nebudu brát ohled na to, že WIFTovi to vzalo přes 3G na 60GB svazku a lehce přes 2500 souborů, tak prostou logikou a použití trojčlenky (matematika a počítače :-) je jasné, že na W7 by to u mě mělo trvat 30 sekund (velikost alokace versus náročnost). Dle videa to nebylo pouhých 30 sekund (potažmo když je to zrychleno 3x a má délku půldruhé minuty a na konci to bylo na 10% procesu) a ještě k tomu to bylo pouhých 42% z mé kapacity a pouhá 2% z počtu souborů... No prostě aniž bych si musel instalovat W7 je mi jasné, že se takové brutální zrychlení nerovná. A tedy je veškerá alokace neodůvodnitelná.

Wifte, co to vyzkoušet a napsat o tom článek? Tohle filozofování je jen a jen plýtvání časem...

Azazel: Tak jsem to vyzkoušel. Win 7 RC (7100), i v ní si chkdsk bere plnou paměť. Chkdsk naalokoval 3,9GB a testoval 500GB disk 2 hodiny 5 minut. Ve WinXP SP3 chkdsk naalokoval 19MB a test trval 2 hodiny 7 minut. Takže rozdíl je minimální, vše je dáno jen rychlostí disku. Ale alespoň žádné modré smrti jsem se nedočkal :-)
Jen jsem při tom objevil drobnou chybku, snad je v RTM opravena. Chkdsk nyní ukazuje % i počet testovaných souborů nebo sektorů v případě prázdného místa. Počet testovaných souborů se měnil, ale procent bylo celou dobu 10.

WIFT: Koukám, že s těmi procenty je to zase nová "vlastnost". Klasické XP dělají procenta zvlášť pro soubory a zvlášť pro volné místo. U souborů to bohužel počítají podle jejich počtu, ne podle velikosti, takže někdy to dlouho stojí a pak zas rychle poskočí.

A pak že na to nejde aplikovat prostou úvahu a matematiku :-) A ještě k tomu je víceméně jasné, že ve W7 ta "úspora" mohla být dána nikoliv optimalizací chkdsk ale diskovým subsystémem, nebo mi chcete tvrdit, že na tuhle část žádný programátor v MS nesáhl?