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
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 ?
Mělo by to být prosté: X-Setup od X-Teq nebo Tweak UI od Microsoftu.
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.
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!
"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?
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!
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?
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.
http://techreport.com/news_reply.x/3494
12:00 am, March 19, 2002 ??? To asi neni uplne aktualni info co?
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.
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.
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.
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
a neviete neviete niekto, kde sa dá získať ten súbor dskcache.exe (mimo MS) ?
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.
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();
Skutecne pekny a zajimavy clanek. Chvalim autora. Jen houst
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.
http://www.tomshardware.com/storage/20020830/ide_raid2-03.html tady to docela objasnujou, presne potvrzujou, co jsem rekl.
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
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
přesně tak
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..
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.
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 :)).
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.
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ší
máte pravdu, omlouvám se
A jak se postavit k tomuhle:
Optimální z hlediska rychlostiOptimální z hlediska dostupnostiOptimální z hlediska ceny
Prachy jsou pro mě nejdůležitější, takže třetí volba je pro mě nejoptimálnější
Hawg
Ze treti volba je pro me optimalni.
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")
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 ?
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.
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.
na výrobci disku do RAIDu záleží, ale jinak souhlasím
Č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.
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í.
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
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.
"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%
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...
jen muj podle meho skromneho nazoru pocit:)
marek
http://www.ine.sk
to jsem chytl od imho jezevce
podle imho meho imho skromneho imho nazoru to imho nevadi:)
Cool!!!
??? "čí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.
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...
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í...
Č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
Mezi druhou a sestou rano se to v pohode stiha, staci to naplanovat.
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.
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.
A co Diskeeper?
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
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?
ze by sis mel urezat pracky v predlokti a zdrzet se pocitacu mily holmesi
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 ?
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á...
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.
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.
btw, zkuste si hned po defragmentaci Speeddiskem to spustit znovu...take bude mit co na praci (zkouseno vcera)
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í.
Vazeny pane Šustr, proc si myslite, ze SpeedDisk je lepsi nez O&O defrag?
A co VoptXP...
má lepší algoritmy zřídění. ale ten rozdíl mezi těmi uvedenými programy není nijak velký
no fuj, co jsem to napsal. samozřejmě jsem chtěl napsat "třídění" ne "zřídění"
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í.....
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
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.
známý používá SystemWorks2003 na OS Win2k SP4 a neříkal, že by mu nefungoval SpeedDisk ?!?
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.
Super, tak tohle o prefetch jsem nevedel, tento clanek je lepsi nez predchozi
Potvrďte prosím přezdívku, kterou jsme náhodně vygenerovali, nebo si zvolte jinou. Zajistí, že váš profil bude unikátní.
Tato přezdívka je už obsazená, zvolte prosím jinou.