Vybíráme optimální disk pro PC – optimalizace softwaru

Diskuze čtenářů k článku

Julda  |  05. 12. 2003 01:25  | 

Super, tak tohle o prefetch jsem nevedel, tento clanek je lepsi nez predchozi

Souhlasím  |  Nesouhlasím  |  Odpovědět
reini  |  05. 12. 2003 05:43  | 

Líbí se mi, že tu je spousta informací soustředěná na jednom místě.

Malá poznámka ke Speed disku: se SP4 pro W2k už nefunguje (bohužel) a update neexistuje. Pokud někdo znáte řešení, sem s tím. Já vím jen o System Works 2004.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 10:52  | 

známý používá SystemWorks2003 na OS Win2k SP4 a neříkal, že by mu nefungoval SpeedDisk ?!?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zorg  |  07. 12. 2003 10:02  | 

Používám SystemWorks 2003 na W2000 SP4 a opravdu to vypíše hlášku že to není podporováno, ale když jsem jí ignoroval, tak se vůbec nic nestalo.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Fireman  |  05. 12. 2003 07:32  | 

Opet pekny clanek.... skoda ze uz ten serial konci. Velice se mi libil a dozvedel sem se i o XP Cahce filter.... neco podobneho uz hledam delsi dobu.

Diky

Souhlasím  |  Nesouhlasím  |  Odpovědět
Anders  |  05. 12. 2003 07:49  | 

Vazeny pane Šustr, proc si myslite, ze SpeedDisk je lepsi nez O&O defrag?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pepik  |  05. 12. 2003 09:40  | 

A co VoptXP...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 10:54  | 

má lepší algoritmy zřídění. ale ten rozdíl mezi těmi uvedenými programy není nijak velký

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 10:55  | 

no fuj, co jsem to napsal. samozřejmě jsem chtěl napsat "třídění" ne "zřídění"

Souhlasím  |  Nesouhlasím  |  Odpovědět
Drake  |  06. 12. 2003 01:23  | 

Mimo jiné proto, že SpeedDisk vám např. umožňuje definovat, která data mají být na konci disku, t.j. s nejpomalejším čtením.

Stejně si ale myslím, že jsou všechny defragmentátory hrozně pitomé, protože nerespektují adresářovou strukturu... nebo se to alespoň o žádném neví. Dalo by se vymyslet tolik inteligentních nastavení.....

Souhlasím  |  Nesouhlasím  |  Odpovědět
Johny Bravo  |  05. 12. 2003 08:23  | 

A co Diskeeper?

Souhlasím  |  Nesouhlasím  |  Odpovědět
MM_tank  |  05. 12. 2003 09:28  | 

Diskkeeper autor zřejmě nezná, o to hůř potom působí, když nám vnucuje pořádí  nejlepšími programy na defragmentaci jsou i zde programy Norton Speed Disk, OO Defrag a Raxco perfect Disk (v tomto pořadí, první je nejlepší). Samozřejmě nemůžu souhlasit

Souhlasím  |  Nesouhlasím  |  Odpovědět
Roman Štědronský  |  05. 12. 2003 09:33  | 

Diskeeper je rychlý, ale někdy nechává až příliš nedokončenou práci. A hlavně - mám silné podezření, že dělá chyby v NTFS (mám Windows XP), které sice lze opravit, ale riziko ztráty dat roste. Než jsem ho nainstaloval, byla pohoda, občasné ověření disku neohalilo žádnou chybu. Nějakou dobu po instalaci a několika defragmentacích to najednou už moc defragmentovat nechtělo, tak jsem dal kontrolu disku. A najednou při startu lítaly celé obrazovky výpisu, co všechno se kde opravuje (deskriptory apod.). Po odinstalaci jsem zatím na tenhle problém nenarazil. Co z toho vyplývá, milý Watsone?

Souhlasím  |  Nesouhlasím  |  Odpovědět
dssfsdf  |  05. 12. 2003 10:43  | 

ze by sis mel urezat pracky v predlokti a zdrzet se pocitacu mily holmesi

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Fiala  |  05. 12. 2003 10:46  | 

Nevim, co z toho vyplyva tobe, ale ja Diskeeper pouzivam hoodne dlouho (od W2k) a nikdy jsem nemel problem s narusenim NTFS.
Zkousel jsem ruzne programy na defragmentaci a skoncil jsem u Diskeeperu.

Proc by mel delat chyby, kdyz to, co je soucast Windows je vlastne hodne orezana verze Diskeepera ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 10:57  | 

1) proč používat DiskKeeper, když už je v OS ?
2) DiskKeeper bohužel často (většinou na velkých oddílech) za sebou nechává nedodělanou práci...zkoušeno několikrát. Poté, co se dokončil DiskKeeper, tak byl puštěn SpeedDisk, který měl na nějaký čas ještě práci...což o kvalitě DiskKeeperu právě nevypovídá...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Fiala  |  05. 12. 2003 11:59  | 

Mezi Diskeeperem, ktery je v operacnim systemu a "ostrym" Diskeeperem je propastny rozdil. Pokud jste srovnaval ostatni s tim integrovanym, nedivim se

Kazdy program na defragmentaci ma svuj algoritmus srovnavani, podle nej nejoptimalnejsi. Takze pokud budu poustet ruzne defragmentacni programy za sebou, vzdy budou "neco" presouvat, protoze se jim bude zdat, ze to neni rozlozeno optimalne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 13:12  | 

přesně tyto reakce jsem čekal

1) ne, nebyla to osekaná verze, nevlastním WinXP.
2) já měl na mysli počet fragmentovaných souborů, které DiskKeeper nechal bez povšimnutí. samozřejmě že každy soft přesouvá data trochu někam jinam, ale mě šlo pouze o to, kolik jich zůstane fragmentovaných a jak moc.

Souhlasím  |  Nesouhlasím  |  Odpovědět
wang  |  09. 12. 2003 11:03  | 

btw, zkuste si hned po defragmentaci Speeddiskem  to spustit znovu...take bude mit co na praci (zkouseno vcera)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Roman Štědronský  |  05. 12. 2003 11:27  | 

Chyby by mohl dělat právě proto, že ve Windows je hodně ořezaná verze. Po té, co jsem na ten problém narazil a filesystém opravil, jsem 2x provedl boot-time defragmentaci adresářů a MFT a několikrát on-line defragmentaci a... bylo tam zase několik chyb. Je možné, že problém primárně neleží v Diskeeperu, ale rozhodně nemám chuť odinstalovávat různé ovladače a aplikace a testovat, zda to pořád ještě blbne... Se zabudovaným defragmentátorem problém není.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Sergej  |  05. 12. 2003 08:28  | 

Nikdy jsem nenapsal názor k článku, ale tady mi to nedá...

Moc pěkné a poučné. Díky za celý seriál.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ombre  |  05. 12. 2003 08:58  | 

Článek se mi také líbil, ale už se mi nelíbí představa, že bych měl ve W2K defragmentovat každých 14 dní 80 a 120 GB disky. To by mě asi za chvíli omyli.

ombre

Souhlasím  |  Nesouhlasím  |  Odpovědět
AB  |  05. 12. 2003 09:29  | 

Mezi druhou a sestou rano se to v pohode stiha, staci to naplanovat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ombre  |  05. 12. 2003 15:25  | 

Jestli myslíš druhou ráno, tak to ani omylem, jestli odpoledne, tak na to není čas.

Pokud opravdu nějaký chobot defragmentuje disky každých 14 dní, tak je mi ho líto, nehledě na to, že se odrazí na jeho životnosti (toho disku:). Disk je stavěn na x "motohodin" a častá defragmentace z toho jistě kus ukrojí.

 Já disk nedefragmentuju vůbec a disky na tom líp, než při pravidelné defragmentaci. Stačí si něco přečíst o instalaci programů na disk a jeho následném zdefragmentování. Nic pěkného.

ombre

Souhlasím  |  Nesouhlasím  |  Odpovědět
tomik  |  05. 12. 2003 09:01  | 

??? "čím je stránkovací soubor blíže systému, tím musí hlavička disku méně vyhledávat" ???

Co to je za ptákovinu když budu dělat nějakou paměťově náročnou operaci, např. parsování velkého XML, bude asi výhodné, aby data byla poblíž sebe.

Řekl bych, že obecně vůbec nezáleží kde je systém a kde stránkovací soubor, protože systém stránkuje ze všeho nejméně, to bych očekával od uživatelských programů a dat.

Jako další obecné tvrzení bych uvedl také to, že při zpracování většího souvislého bloku dat, je umístění na disku méně důležité oproti situaci, kdy je třeba okamžitě zapsat malé množství dat na různá místa disku ( update databázového souboru, vyprázdnění bufferu, zápis do FAT...) proto pokud vím svého času umístila IBM HPFS uprostřed oblasti.

 

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 11:01  | 

no ano. ale budete kvůli každému souboru přerozdělovat disk tak, aby ten datový soubor a swap byly právě co nejblíže u sebe ?
tím systémem jsem v článku nemyslel jen OS, ale v podstatě celý systémový oddíl - tzn. i hry, programy...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Drake  |  06. 12. 2003 01:29  | 

třeba NTFS má MFT soubor uložený uprostřed disku, aby k němu byl snadný přístup odevšaď. Jenom nechápu, prož při překročení 85% zaplnění disku (nebo tak nějak) vytvoří další fragment uprostřed těch zbývajících 15% nezávisle na tom, jestli je v MFT ještě dost místa nebo už dochází...

Souhlasím  |  Nesouhlasím  |  Odpovědět
nemo  |  05. 12. 2003 09:07  | 

Zdravim, tento serial nebyl spatny (az na serverova reseni, tam znalosti trosku vazly), ale mne osobne prilis nevyhovovalo to, ze zabiral vzdy hlavni misto mezi clanky...proc? Proc ne treba kazde utery, proc den po dni?
Prijde mi to trosku DISKOstredne ale je to jen muj imho pocit...

Souhlasím  |  Nesouhlasím  |  Odpovědět
marek  |  05. 12. 2003 09:29  | 

jen muj podle meho skromneho nazoru pocit:)

marek

http://www.ine.sk

Souhlasím  |  Nesouhlasím  |  Odpovědět
nemo  |  05. 12. 2003 09:55  | 

to jsem chytl od imho jezevce

Souhlasím  |  Nesouhlasím  |  Odpovědět
marek  |  05. 12. 2003 11:13  | 

podle imho meho imho skromneho imho nazoru to imho nevadi:)

marek

http://www.ine.sk

Souhlasím  |  Nesouhlasím  |  Odpovědět
Brus  |  08. 12. 2003 12:49  | 

Cool!!!

Souhlasím  |  Nesouhlasím  |  Odpovědět
kuna  |  05. 12. 2003 09:48  | 

Oproti minulym vytvorum autora, tak ted ho mohu jen pochvalit. Autor pridal odkazy na zajimave stranky, kde leze neco stahnout ci neco zajimaveho se dozvedet.
Co se tyka RAID 0. Muj nazor a zkusenost je pouzivat RAID 0 jen omezene a jen pro docasne ulozeni (editace video a audio) a pak hned vypalit. Je dvojnasobne nebezpeci ztraty dat (dva datove na sobe zavisle disky). Osobne si myslim ze je jen pokusem vyrobcu jak nalakat zakazniky pridanim neceho co v podstate nema prilis pro NORMALNIHO zakaznika vyznam (diskova rychlost v idealnim pripade vzroste tak o 50%, ale prakticky tak 10-20%) Dulezite je ale aby byl IN a mohl se pochlibit pred "kamosema"
Nebezpeci ztraty dat je ale vzdy. Kazdy si musi rozhodnout jak jsou pro neho data dulezita. V praci na CAD WS pouzivame pro system 1 disk a pro data RAID 1 a presto kazdy den zalohujeme na pasku. Je to drahe, ale jeste se nam nestala jedina ztrata dat a system je komplet nainstalovan za 20 minut ze zalohy.

Souhlasím  |  Nesouhlasím  |  Odpovědět
dubin  |  07. 12. 2003 02:33  | 

"Je dvojnasobne nebezpeci ztraty dat (dva datove na sobe zavisle disky). "

- tak tohle je nesmysl, z matematiky můžeme jednoduše spočítat celkovou spolehlivost systému, který se skládá ze dvou podsystémů

např. budeme-li uvažovat spolehlivost jednoho disku 90% potom spolehlivost celého systému je 0,9 x 0,9 tj  81%

Souhlasím  |  Nesouhlasím  |  Odpovědět
S  |  05. 12. 2003 09:56  | 

Vykon RAID0 je fakt jen o cca 10% vetsi nez u samotneho disku ?? Neni to nejak malo ? zil jsem v domneni, ze to je vice, treba 30-40%. V tom pripadne nechapu, proc se to vubec dela nebo to plati jen u IDE disku ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
netm@ster  |  05. 12. 2003 10:12  | 

Kuna nevi co povida. Narust je sice od vyrobce k vyrobci jiny, ale mene nez 20% to urcite neni. Napr Hitachi maji narust kolem 40%.

Jinak RAID1 take neni nic tak bezvadneho. Relativne bezpecnejsi je dle meho nazoru az RAID5, ktery se kazdopadne u serveru pouziva casteji.

Souhlasím  |  Nesouhlasím  |  Odpovědět
kuna  |  05. 12. 2003 11:04  | 

Uvedom si prisim ze tu mluvime o teoretickem a skutecnem narustu. V teoretickem skutecne mas narust tvych 40%. To plati pro kontinuelni zapis a cteni, ale pro nahodne cteni a zapis jde vykon rapidne dolu a nezalezi na vyrobci.Vzdy zalezi na typu dat. Mam-li mnohamegove soubory RAID 0 nadhera. Podivej se ale kolik je napr ve WIN souboru pod 1 mega - naprosta vetsina.
RAID 1 ma tu vyhodu, ze pokud ti klekne jeden disk tak to nezaznamenas na vykonu (nemusi se nic dopocitavat) a hlavne napr UNIXY ti ho podporuji nativne (SW) to znamena ze nepotrebujes zadny RAID radic. Pro normalni PC naprosto zbytecne drahe.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 11:25  | 

na výrobci disku do RAIDu záleží, ale jinak souhlasím

Souhlasím  |  Nesouhlasím  |  Odpovědět
xyz  |  05. 12. 2003 12:40  | 

Čo viem, tak win verzie server (NT4.0, 2000, 2003) majú tiež v sebe RAID 1 a tiež SW. Takže to nie je výsada UNIX-ov, ako to tu niekto prezentuje. Je pravda, že Linux je aj desktopový systém a tiež to dokáže. Ale Linux je akosi univerzálnejši. A MS tie svoje produkty delí, takže napríklad Win98 to nevedia, lebo segment užívateľov, ktorí ho používajú to veľmi ani nepotrebuje a nemá na to (nie finančne). To je ako keby ste mi povedali, že mám voziť vo Favorite veľké kusy nábytku. Nepôjde to, ale na to ten Favorit nebol predsa vyrobený. Linux síce vykrikuje, aký je dobrý, ale je zvyčajne na troch plných CD, aby mal taký široký záber. Pozrite si, koľko zaberá WIn98 na CD. Takže s tým RAID na UNIX-och nezavádzajte.

 

A mám poznámku k Diskeeper. Necháva po sebe nedokončenú robotu. Nie preto, že za ním nájde NDD fragmentáciu, ale preto, že ju nájde sám po sebe, keď ho pustím druhý krát.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 11:04  | 

při normální práci na PC (hry, office a já nevím co ještě) je ten rozdíl opravdu jen tak 10%. v testech je ten rozdíl ale mnohem větší - ale testy nic nevypovídají o reálné situaci.

nárůst o 50% nebo i více je pouze v situacích, kde se opravdu využije téměř dvojnásobný datový tok na úkor trochu slabšího vyhledávání !! což není případ normálního použití.

Souhlasím  |  Nesouhlasím  |  Odpovědět
One  |  07. 12. 2003 09:03  | 

no ten vykon muze byt i treba pres 80% ale jen ve specializovanych aplikacich . treba rip na velkoplosnou tiskarnu (plotry) takovej obrazek 3*1 m kterej visi na chodbe nejake firmy a lidi kolem neho chodi je tisknutej treba na 720*720 dpi a rip musi prevzorkovat puvodni obrazek do tohoto rozliceni tj.cca 9 GB cisteho obrazku + nejake to prepocitavani a tady samozrejme narust vykonu bude obrovskej .. casto i vetsi nez dokaze tisknou tiskarna
jinak omezeni na slapsi vyhledavani se da do jiste miry obejit velkou RAM tak od 1 GB

Souhlasím  |  Nesouhlasím  |  Odpovědět
Radecek  |  05. 12. 2003 10:03  | 

Nevim jak vas ostatni, ale kdyz slysim tohle "ceske" slovo, tak bych vrazdil. Vyskytuje se to tu porad, stokrat muze clovek vykladat, ze takove slovo neexistuje a navic postrada smysl, stejne se to tu objevi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tomas  |  05. 12. 2003 10:20  | 

Jo jo, pravda Radečku, autor by mohl umět česky ... pořád ne všichni ví, že optimální = úplně nejvíc maximálně nejlepší

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 11:05  | 

máte pravdu, omlouvám se

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jirka  |  05. 12. 2003 11:21  | 

A jak se postavit k tomuhle:

Optimální z hlediska rychlosti
Optimální z hlediska dostupnosti
Optimální z hlediska ceny

Prachy jsou pro mě nejdůležitější, takže třetí volba je pro mě nejoptimálnější

Hawg

Souhlasím  |  Nesouhlasím  |  Odpovědět
Viktor Janeba  |  05. 12. 2003 12:23  | 

Ze treti volba je pro me optimalni.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Freaky  |  07. 12. 2003 22:27  | 

To mate stejne, jako kdyz vyrobci a firmy nabizeji CRT Televizory a Monitory s "PLOCHOU", "ULTRAPLOCHOU" a "EXTRAPLOCHOU" atd. obrazovkou (Flat square tube, Flat, Ultra Flat, Real Flat, Natural Flat)

Tak preci budto je plocha a nebo neni  (jeste bych pochopil bych "skoroplocha")

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petrik  |  05. 12. 2003 10:08  | 

Velikost stripe urcuje, na jak velke casti se deli zapisovany soubor a sude se zapisuji na 1. disk, liche na druhy, v pripade vice disku to je ob 3. atd. Spravne? Je tedy logicke, ze cim vetsi velikost stripe (512kB), tim lepe pro cteni/zapis velkych souboru, naopak pro male soubory je lepsi maly stripe, protoze i ten se rozdeli na dva a vice jeste mensich. Take ve vetsine setupu a navodu k RAIDum je uvedeno pro A/V editing VZDY vetsi stripe nez pro server a desktop. Z tech testu sice vypliva neco jineho, ale je to divne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petrik  |  05. 12. 2003 10:16  | 

http://www.tomshardware.com/storage/20020830/ide_raid2-03.html tady to docela objasnujou, presne potvrzujou, co jsem rekl.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 11:24  | 

ono je to hodně složité. v podstatě existují 2 "teorie"

1) teorie Toms Hardware a XBitLabs - čím větší stripe, tím vyšší STR a naopak.

2) teorie HDDInfo a StorageReview - přesně naopak než bod 1).

já souhlasím s bodem 2, za prvé proto, že mi to přijde logičtější a za druhé proto, že se vší úctou k XBitLabs a Toms Hardware, přeci jen specializované servery na hdd problematiku asi o tom budou vědět více...

a proč souhlasím s bodem 2 ?
1) čím větší stripe size, tím je menší nutnost seeku obou disků zároveň, protože je větší šance, že malé soubory budou jen na jednom disku, tudíž při požadavku na přečtení 5 souborů každý o velikosti třeba 100kB bude znamenat, že při velikosti stripe 128kB je šance, že např. na prvním disku budou 3 soubory a na druhém ty zbylé dva. samozřejmě je možné, že všech pět souborů bude zrovna na prvním disku, ale to už je statistika
2) čím menší stripe, tím sice větší šance, že disk bude muset seekovat, ale disky obecně mají rády spíše fronty (s hloubkou 1) kdy jsou požadavky na co nejmenší za sebou se nacházející data (tzn raw data/video apod). tam už je to o firmware. navíc pokud není RAID 0 jen na dvou discích, ale na více, jen se rozdíl prohloubí.

pokud máte čas, rozepište proč si myslíte, že je to podel bodu 1 (THW a XBL) a může se o tom pobavit

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petrik  |  05. 12. 2003 13:27  | 

Aha, takze by se dalo obecne rici, ze vetsi stripe je lepsi pro mensi pristupovou dobu, mensi naopak pro vetsi burst, takze se skutecne potvrzuje vas bod 2. Je ale zajimave se nad tim zamyslet

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 14:54  | 

přesně tak

Souhlasím  |  Nesouhlasím  |  Odpovědět
Drake  |  06. 12. 2003 00:48  | 

Ovšem pouze za předpokladu, že jsou ty načítané soubory za sebou a k řadiči doputuje instrukce o přečtení celého velkého segmentu.

Mám pár dotazů:

Raid čte vždy celou velikost min. jednoho stripe? Nebo čte celou velikost stripe setu (odpovídající stripy na všech discích)? Z hlediska filesystemu - čte se vždy celý cluster nebo jenom jeho postačující část? Pokud se totiž pletu, mění to následující pravidla:

Ohledně malých souborů:

Mám takový dojem, že OS načítá vždy po jednotlivých souborech (a ty po jednotlivých clusterech kdyby byl soubor větší než cluster), takže reálně by ve vašem příkladě dostal řadič min. 5 pokynů ke čtení. První soubor by se četl z prvního stripu z ploten, další dva pak z cache HDD, 4. z druhého stripu z ploten a 5. z cache druhého HDD. Mimochodem v případě jednoho disku by se jednalo o jeden přístup na plotny a 4 přístupy do cache disku. Samozřejmě musí být cluster size několikrát menší než stripe size.

To vše v ideálním případě, že jsou soubory za sebou. Jestliže nejsou, nemá ta matoda žádný přínos a je asi nepatrně lepší mít cluster size N* větší než je stripe size (pro Ndisků v raid-0), což zrychlí načítání bezpečně všech souborů. Navíc tady je v případě souvislého uložení souborů je přínos raidu ještě větší: pole dostane příkaz načíst cluster-y prvního souboru, oba disky načtou každý svůj stripe, a pak následující 4 soubory už se jenom kopírují paralelně z cachí obou disků najednou. Tzn tentokrát je to jen jedno čtení z ploten, zbytek z cache a navíc jde vše paralelně.

Přístup k náhodně rozmístěným souborům je samozřejmě ovlivněn tím, že každý přesun hlaviček vás stojí v průměru kolem 0,7 MB dat (50MB/s krát 0,014 s avg. acces time), které mohly za tu dobu být načtené, což představuje nějakých 170 clusterů o NTFS-defaultní velikosti 4 KB. Maximální teoretická přenosová rychlost je tedy kolem 300KB/s a raid tu nemá žádný přínos, spíš naopak kvůli ne-úplně-stejnému chování jednotlivých disků. Naštěstí je šance něčeho takového opravdu malá, reálně se rychlost načítání pohybuje v oblasti 3-10 MB/s. Bohužel, i když je reálné rozmístění souborů lepší, raid-0 tady stejně nepomůže celými 40-60% výkonu jako při kontinuálním čtení, ale jen tak těmi zmïňovanými 10-20%

Ohledně velkých souborů:

Ano, menší stripe size může zvětšit plynulost (i když nepatrně) a klade menší nároky na velikost výstupního bufferu, ale určitě zvětší overhead z dělení příkazů mezi jednotlivé disky a následně z častějšího skládání výstupu. (Testováno, maximum rychlosti někde kolem 128 KB stripe size, rozdíly minimální)

Vaše teorie naopak předpokládá, že OS pošle řadiči příkaz k načtení souvislého bloku dat obsahujícího všechny clustery všech pěti souborů.

Ohledně raid-5:

Je třeba dbát na to, aby se např do pole nezapisovala data o velikosti jednoho stripu, protože pak pole musí načíst z disků zbývajících N-2 stripů a dopočítat paritu celého segmentu pro N-tý a pak to teprve může celé zapsat. Cluster size tedy nemá cenu dělat menší než (N-1) * stripesize.

 

Uff, nějak jsem se rozepsal..

Souhlasím  |  Nesouhlasím  |  Odpovědět
Drake  |  06. 12. 2003 00:55  | 

mimochodem, jedním z dobrých defragmentátorů je prý třeba PowerQuest Drive Image se zapnutým Smart Sector copy.. stačí jen udělat image a pak ho zapsat do místa původní partišny. V ideálním případě defragmentujete 60GB dat nějaké dvě-tři hodiny. Nevýhodou je nutnost dalšího prázdného disku ( může být menší, dá se to komprimovat), výhodou by mělo být třeba i to,že to defragmentuje i zamčené soubory.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Drake  |  06. 12. 2003 01:11  | 

Mimochodem, někde jsem viděl nádherný, pečlivě udělaný test vlivu velikosti stripů a clusterů v dvoudiskovém RAID-0 na přenosovou rychlost (malé i velké soubory, kopírování oběma směry), a byl jsem docela zklamaný, že to nemá skoro žádný vliv, dokonce i oproti jednomu disku to nevykazuje moc velký rozdíl.

No a pak jsem si všimnul, kde pánové ze severní evropy udělali chybu - jako druhé úložiště při kopírování použili single disk. No nezabili byste je?

Dokonce tomu i odpovídaly vyšší dosažené rychlosti při čtení ze singl a zápisu na raid oproti opačnému směru :)).

Souhlasím  |  Nesouhlasím  |  Odpovědět
cslovak  |  05. 12. 2003 11:03  | 

Skutecne pekny a zajimavy clanek. Chvalim autora. Jen houst

Souhlasím  |  Nesouhlasím  |  Odpovědět
xyz  |  05. 12. 2003 12:42  | 

a neviete neviete niekto, kde sa dá získať ten súbor dskcache.exe (mimo MS) ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza Šustr  |  05. 12. 2003 13:16  | 

no, původně jsem ho chtěl dát na živě také, ale předpokládám, že bez povolení MS by to bylo nelegální, takže jsem od toho upustil. každopádně lze ho po chvíli pátrání najít např. pomocí google.

Souhlasím  |  Nesouhlasím  |  Odpovědět
xyz  |  05. 12. 2003 22:30  | 

Máte pravdu s tým povolením. Po chvíli hľadania na google som ho skutočne našiel. Ale MS asi vie, prečo ho len tak voľne nešíri. Mám podozrenie, že to asi robí na niektorých čipových sadách problémy a skutočne môže dôjsť k strate dát ak sa nezapíšu okamžite, ale držia sa v cache a zápis sa odloží na neskoršie. Má s tým niekto skúsenosti (s používaním toho súboru) ?
postamble();

Souhlasím  |  Nesouhlasím  |  Odpovědět
petr andrs  |  05. 12. 2003 12:45  | 

Po te co jsem videl, ze nektere jine OS davaji SWAP na extra partition, tak jsem to ve win udelal taky a fragmentace swapu jiz opravdu nehrozi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Klima  |  06. 12. 2003 20:45  | 

No, on nikdo nerekl, ze je to idealni, ale aspon s pristupem do swapu neni rezie kvuli souborovemu systemu. Mimochodem, nektere jine OS sice swap davaji na jiny oddil, ale pak ho skoro nepouzivaji. Kdyz uz jsem u toho, dokaze mi nekdo vysvetlit, proc XP maji tendenci mit 400MB swapu, kdyz mam 256MB RAM a pri startu Windows se spousti ICQ, AVG a nic jineho? Ony te pameti opravdu potrebuji tolik (boze, chran nas od toho...), nebo maji tak obrovske memory leaky (boze, totez...)? Mne proste sere, kdyz mam pracovat s takovou kravou systemem. Ja od nej totiz chci, aby byl co nejmin videt pod aplikacemi - minimum sezrane pameti a procesoroveho casu. Ale asi jsem sam, protoze jinak by prece M$ nedelal to, co dela.

Souhlasím  |  Nesouhlasím  |  Odpovědět
noone  |  07. 12. 2003 11:26  | 

Jakým programem jsi zjišťoval velikost swapu? Já mam ve W98 nastavený swap napevno na 512MB, ale využije se jen málokdy(Na zjištění velikosti swapu používám Cacheman). Nastav si taky pevnou velikost swapu, nebere to tolik CPU.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Freaky  |  07. 12. 2003 22:34  | 

Ja jsem SWAP zakazal a pri beznem provozu (Antivir,Firewall,Winamp,DC++,IE2-3okna) me to zere 200-300MB RAM, takze to neni tak husty s tou zravosti WinXP jak jsem si vdycky myslel

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin  |  05. 12. 2003 13:49  | 
netm@ster  |  05. 12. 2003 16:05  | 

12:00 am, March 19, 2002 ??? To asi neni uplne aktualni info co?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Klima  |  06. 12. 2003 20:35  | 

Nebudu tvrdit, ze vidim do NTFS, ale vzdycky jsem byl presvedcen, ze ho netreba defragmentovat, protoze kod v jadre se o to stara sam. Rovnou rikam, ze Windows obecne a XP zvlaste pouzivam jenom z donuceni, takze nejsem prilis informacne na vysi, pokud jde o jejich nedostatky.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mark  |  07. 12. 2003 21:01  | 

V minulem dilu bylo slibeno reseni problemu s Tagged Command Queuing  u WIN XP a W2k SP2+ s disky Hitachi... Bohuzel jsem tady reseni nenalezl :( Pomuze nekdo?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Wagner  |  07. 12. 2003 22:18  | 

Je vhodné zadat sytému pevnou velikost stránkovacího souboru. Zamezí se tím jeho fragmentaci. Tuto velikost je vhodné nastavit na 512 MB v případě, že máte pouze 256MB RAM a nepoužíváte počítač na editaci audia/videa. Pokud máte 512 MB RAM, mohou „odvážnější“ vypnout stránkovací soubor zcela, ti „méně odvážní“ mohou nastavit pevnou velikost na 256MB.

Pokud máte 512 MB RAM, XP Profi mi doporučují nastavit velikost na 766 MB. Nechápu důvod k vypnutí stránkovacího souboru nebo nastavení na menší velikost než doporučenou (u 256 MB se obvykle doporučovalo nastavení na 2-3 násobek už v dobách Win98/2000). K tomu IMHO snad není nutná odvaha, ale řádná dávka hlouposti!

Souhlasím  |  Nesouhlasím  |  Odpovědět
Brano  |  08. 12. 2003 01:30  | 

"Funkce Prefetch ve Windows XP je použita pouze pro programy ve stejném oddílu jako je systémový adresář (to lze někdy považovat za výhodu)"
No ja mam rozdeleny disk na oddiel so systemom - 3 GB a vsetko ostatne vratane programov mam na D-cku. Takze to vyzera, ze u mna ziadny program Prefetch nepouziva. Nevie niekto povedat o kolko by to mohlo urychlit chod programov, keby som ich mal nainstalovane na systemovom oddieli?

Souhlasím  |  Nesouhlasím  |  Odpovědět
X-22  |  08. 12. 2003 13:23  | 

Díky autorovi za mnoho podnětů a rád bych příhodil své zrníčko na hromádku. MS dělá utilitku BootVis, která urychluje bootování operačního systému Windows XP. Protože už to popsal CDR server, odkazuji tam. Zkoušel jsem to a má to něco do sebe ...

Mimochodem, nevíte někdo, jak je to doopravdy s tím ničením (snižováním životnosti) disků při zapnutém uspávání disku v Power Options v Control Panel? Nemyslím teoreticky, ale jestli to doopravdy výrazně snižuje životnost disku. Prosba - nezajímá mě něcí subjektivní střelba od boku, ale nějak něčím podložený názor (stačí odkaz). Díky!

Souhlasím  |  Nesouhlasím  |  Odpovědět
X-22  |  08. 12. 2003 13:31  | 

Ještě jsem si vzpomněl na jeden typ. U Windows NT-2000-XP-2003 se někdy doporučuje při existenci více disku v systému umístit stránkovací soubor na jiný fyzický disk než na ten, kde je systém. Viz třeba tady, nebo zde

Souhlasím  |  Nesouhlasím  |  Odpovědět
x  |  08. 12. 2003 14:23  | 

Vie niekto, ako sa da dat cely adresar documents and settings na iny disk (napr. D:) ? Existuju na to urcite nejake corporate nastroja, lebo to mame takymto sposobom vo firme, ale da sa to aj nejakym beznym sposobom spravit ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
X-22  |  08. 12. 2003 15:02  | 

Mělo by to být prosté: X-Setup od X-Teq nebo Tweak UI od Microsoftu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
palo  |  08. 12. 2003 22:48  | 

prosim vas nevite zde je nekde srozumitelny popis (ci clanek) ktere systemove ... procesy a proc musi bezet

na Win NT, 2000, XP? (predevsim XP)


diky


palo

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Megatest 18 grafických karet

Ukliďte data v počítači

Jak dobře koupit starší telefon

Vylepšete zvuk televize: test 7 soundbarů