Vlákno názorů k článku Defragmentace disků v Linuxu od anonym - No, jeste pred tim pythonem me zaujalo, to...
-
anonymníNo, jeste pred tim pythonem me zaujalo, to ze Linux vlastne nepotrebuje defragmentaci .... nicmene, tuhle naprostou demagogii pominu. Spis me zajima ten python .... jako defragmentator v pythonu? A navic pomoci beznych prikazu filesystemu nejakym poustenim furt dokola? No, to uz je fakt sila i na root:)
-
Ash (neregistrovaný)Klídek, jde o defragmentaci souborů, ne disku který je z 99% zaplněn :) Takže bez nějakého nízkoúrovňového nástroje se dá obejít, tohle není FAT.
Pomocí běžných příkazů fs zjistíte fragmentaci a pomocí rsync to s největší pravděpodobností (nemáte plný disk) defragmentujete (protože jakýsi výchozí stav je u ne FAT systémů "nefragmentováno", že). -
kvr (neregistrovaný)Dalsi Alenka v risi divu. V clanku je to napsane docela dobre, ve chvili, kdy neni filesystem preplnen, k nejake vetsi fragmentaci nedochazi (pokud prichazite z windos, muze vas to samozrejme prekvapit - po 6 letech behu Linuxu na zhruba 90% zaplnenem disku jsem mel fragmentaci 7%, po cca mesici zakoupeneho notebooku s WXP (TM) na 30% zaplnenem disku fragmentaci asi 42%).
K druhe casti - pokud uz si tedy dal vubec nekdo tu temer zbytecnou praci s psanim defragmentatoru, je za prve uplne jedno, jestli je v pythonu, C, jave nebo assembleru, za druhe, ac se to nemusi zdat, muzou ty vysledky z dlouhodobeho hlediska byt vyrazne lepsi, nez presun kompletniho obsahu filesystemu na zacatek disku ;) (o nutne podmince ve WXP - uzivateli, ted se pokud mozno 10 hodin nedotykej klavesice a mozna ani to nebude stacit (tu logiku algoritmu bych nekdy mimochodem rad pochopil) - ani nemluve).
Takze, priste min narazek na kvalitu clanku a vice premyslet! -
LO (neregistrovaný)Jak tu fragmentaci počítáte? Každý nástroj jí totiž bohužel počítá jinak.
Ve Windows se používá System Restore, kde se ukládají změny v systému (instalace, odinstalace apod). Tyhle věci jsou komprimované na úrovni FS, a jej jich hromada. Při kompresi na úrovni FS se soubor silně fragmentuje (tuším, že se komprimují bloky 16 clusterů, takže komprimovaný soubor je pak na disku děravý jak řešeto). V praxi to samozřejmě ničemu nevadí, protože se komprimují soubory, které se používají minimálně (třeba ty data System Restore), ale FS je pak více fragmentovaný. -
Anče (neregistrovaný)jisteze je to problem. fragmentace jako takova je nevyhodna a zpomaluje praci pri I/O a daty. to je proste fakt.
to co popisujete je dle meho nazoru proste vadny navrh aplikace. a resenim je pouzivat neco jineho nez nejake system restore ktere popisujete.
a abych parafrazoval: snad to nejkdy budete moci udelat (ve smyslu: svobodne se rozhodnout ze tu a tu konkretni cast windows nebudete pouzivat, protoze vam nevyhovuje) -
LO (neregistrovaný)Když soubor uložíte nekomprimovaný, a poté jej zkomprimujete, zabere méně místa, než zabíral původně. NTFS provádí kompresi po 16 clusterech. Když je zkomprimujete na 4 clustery, na disku zůstane díra 12 clusterů volného místa. Protože stejně nekomprimujete soubory, u kterých záleží na výkonu, je to celkem jedno. Ovšem ve výpisu fragmentovaných souborů budete mít například komprimované soubory ze System Restore, které jsou rozsekané na stovky fragmentů. Vliv na výkon to má nulový, ale při počítání procenta fragmentace (což je číslo, které stejně každý počítá jinak) se to dost projeví.
-
abyssal (neregistrovaný)No neviem, neprijde mi ako najlepší nápad nechávať diery v komprimovaných súboroch. Keďze FS compression routine musí na každých 16 clusterov spraviť read&write, tak je už skoro jedno, či sa presunú, alebo nie, pretože zapísať ich treba. Teoreticky by tam mohlo byť spomalenie kvôli seeku pri komprimácii extrémne veľkých súborov >=.5GB, ale tam už nejaká diera nejak nezaváži ak by boli "kompaktované" dajme tomu po 1 MB (tj. nevyžadovať úplnu "bezdierovosť", ale zhlukovať po skupinách).
Tam ani tak nejde o tie SysRestore súbory, k tým sa moc nepristupuje, skôr o tie, čo sa natlačia do dier medzi ne (netvrdil by som že "vliv na výkon nulový"). -
abyssal (neregistrovaný)Tam by som sa nebál, že sa tam nacpú veľké súbory (to žiadny aspoň polointeligentný alokátor nespraví), ale môže tam narvať kopu malých. Proces čítajúci ich potom bude nútiť disk seekovať (v závislosti od počtu dier a počtu malých súborov).
Napr. alokátor usúdi, že file1 sa tam zmestí, dá ho tam, do ďalšej diery dá file2, pretože je blízko file1, takže sa moc seekovať nebude, ale takýmto spôsobom ak sa tam narve tak 100-500 fajlov (lebo každý je blízko predchádzajúcemu), tak to už seekovať bude dosť pri náhodnom prístupe k nim (napr. inštalátor ich tam narve a aplikácia k ním nejakým úplne iným spôsobom bude pristupovať, čo je bežný use case).
Fragmentovaný free space je podobne blbý ako fragmentované fajly (tam závisí, či sa viac číta, alebo viac maže/vytvára). -
LO (neregistrovaný)Ohledně defragu ve Windows by bylo dobré zmínit, že jde o opravdový defrag (ne prosté zkopírování souboru), provádí se na namountovaném FS, je pro aplikace po celou dobu transparentní, a systém pro něj nabízí API. Ve Vistě navíc defrag běží s nízkou prioritou I/O operací, takže uživatele nijak neruší. No, třeba se unixy časem také naučí ;)
-
eee (neregistrovaný)Unixy se naucily defragmentovat automaticky behem prace se souborovym systemem. Takze defrag nepotrebuji. K fragmentaci dochazi maximlna pri zaplnenem disku, kdy jsou schopnosti automaticke defragmentace omezene. Po uvolneni disku se toto opet samovolne napravi, pokud se s temi soubory hybe, coz je pravdepodobne u preplneho disku u tech jeho poslednich souboru. Pokud se nahodou s nejakym nehybe, pomuze prave tento nastroj, ktere takove trvale soubory rozhybe a diky automaticke defragmentaci se tim defragmentuji. A to prosim na namoutovanem FS, pro aplikace je celou dobu transparentni, system k tomu nabizi api (pro zjisteni fragmentovanych souboru), prioritu si uzivatel muze nastavit jakou chce a defragmentaci muze provest jen na vybranych souborech, treba jen v jednom adresari. Pochybuji, ze se tohle windows nekdy nauci.
-
sb (neregistrovaný)Nemáš pravdu. Ještě v XPčkách to nefunguje dobře - pokud otevřeš (nebo třeba i vytvoříš) soubor, následně ho zavřeš a pak se ho pokusíš smazat tak to s docela vysokou pravděpodobností selže. Smazání se neprovede, protože widle mají ten soubor ještě otevřený. A to i pokud tuhle posloupnost provádíš v rámci jednoho threadu.
Po zavření se provádí volání různých háčků (antiviry atd), což v případě vytíženého CPU vede k tomu, že následující smazání souboru selže protože jej má někdo otevřený. Widle to neumí pořešit - otevřený soubor nesmažeš.
Řešil jsem toto v kódu už několikrát - ale jen na windows portu, v unixu nikdy. -
BTJ (neregistrovaný)Ano, tomu se prave rika ty security dekriptory a access righty. To, ze to nechapes je sice smutne, ale vzdycky muzes pouzit UTFG, aby si zjistil co to znamena. To, ze nemuzes nastavit, aby ti jiny proces nemohl smaznout file (co asi podle tve reakce v linuxu nejde) bych povazoval za velmi zasadni nedostatek file systemu .... toliko asi k te vyspelosti linuxovych filesystemu ....
-
pokud otevřeš (nebo třeba i vytvoříš) soubor, následně ho zavřeš a pak se ho pokusíš smazat tak to s docela vysokou pravděpodobností selže
Co má tohle společného se security descriptory a přístupovými právy?Ano, tomu se prave rika ty security dekriptory a access righty.
To, ze nemuzes nastavit, aby ti jiny proces nemohl smaznout file (co asi podle tve reakce v linuxu nejde) bych povazoval za velmi zasadni nedostatek file systemu...
No tak kdo co může smazat se řeší pomocí přístupových práv, případně nějakých mandatory access control, ne? -
Myslim ze si prehliadol FILE_SHARE_DELETE :) Ono to vsetko ma svoj vyznam a osobne mi pride vhodnejsie obcas vopruzovat userov, ako nemoznost exkluzivne locknut file :) Taky flock() je v linuxe len poradny a pokial niektory proces nedodrzi lockovaciu konvenciu (napriklad zaskodnicky), pruser s nekonzistenciou dat je na svete...
-
To, ze nemuzes nastavit, aby ti jiny proces nemohl smaznout file (co asi podle tve reakce v linuxu nejde) bych povazoval za velmi zasadni nedostatek file systemu
Úplně to zakázat sice nejde (root může všechno), ale souborový systém si umí poradit i s tím, že mi někdo ten soubor pod rukama ukradne nebo smaže. V UNIXu jsou otevřené inody, ne VFS cesty. Když někdo zruší VFS cestu (smazáním nebo přesunutím souboru), inode buď existuje dál s jinou VFS cestou, nebo bude existovat ještě tak dlouho, dokud ho nezavřou všechny programy, přestože VFS cesta už neexistuje. -
Jenže bohužel aplikace nepracuje s inody, ale s cestou k souboru. Jinými slovy aplikace otevřela handle k souboru /home/franta/cosi, a ne k inode. Když soubor smažete, je to celkem problém (například nelze /home/franta/cosi otevřít ze jiného procesu). Ještě větší problém by vznikl, kdybyste vytvořil nový soubor /home/franta/cosi, protože pak by různé aplikace viděly pod stejným názvem úplně jiný soubor. Pravděpodobně vidíte, že se jedná o průvih.
-
Petr (neregistrovaný)Ne. Vidim, ze se jedna o uzitecnou vlastnost, kterou pri sprave systemu casto pouzivam.
Pokud lze Unixu neco v tomto smeru vytkout, pak je to API na mazani souboru. Soubor nemohu smazat pres ofile (pres handle), ale jen pres cestu. Vzdy je tam jiste okenko mezi tim, co si overim "/cesta/soubor je to, co chci smazat" a co provedu "smaz /cesta/soubor". Pokud bych mohl pouzit ofile (handle), mel bych jistotu o identite toho, co mazu. -
LO (neregistrovaný)Upřímně doufám, že Windows nebudou nikdy defragmentovat soubory stylem "zkusíme soubor překopírovat někam jinam, třeba se fragmentace zlepší". A protože mají už hodnou dobu API pro defragmentaci, je tu velká šance, že se tak opravdu nestane.
Pokud chcete defragmentovat jednotlivé soubory, viz utilita contig od sysinternals. Ve Vistě to řešit nemusíte, protože defrag běží jako plánovaná úloha každých pár dní. A běží s nízkou prioritou I/O operací, takže uživatele nijak neomezuje. Třeba se to unixy také jednou naučí ;) -
R (neregistrovaný)A uz v tej viste konecne ten defrag funguje? V NT4.0 oficialne nebol potrebny. Vo Win2K sa zrazu objavil a nefungoval. Rovnako nefunguje ani v XP. Prejde si cely disk, par suborov defragmentuje a potom skonci s tym, ze nic viac spravit nevie. Niekedy sa po par prechodoch umudri, niekedy nie. Zaujimave, ze o&o defrag funguje - trial verzia je sice zadarmo, ale potom treba platit...
-
V unixech oficiálně defrag nebyl nikdy potřeba. A když potřeba nebyl, ale už to bez něj fakt nešlo :), tak provedl backup na pásku, FS se smazal a znovu vytvořit, a pak se provedl restore. Nyní tu máme článek o metodě "zkus soubor zkopírovat jinam, a třeba se to zlepší" ;).
V NT4 bylo API pro defragmentaci, a nástroj dodávala společnost Executive Software v základní verzi zdarma. Ve Win2K i XP samozřejmě defragmentace funguje. Jsou tam pochopitelně omezení. Je také důležité si uvědomit, že není účelem mít celý disk ve vizualizaci defragu v zelené barvě, ale mít dobrý výkon FS. To není nezbytně totéž. Například 600MB file se 20 fragmenty není žádný problém. -
Peter Cernoch (neregistrovaný)Tady bych trochu nesouhlasil.
Vykon disku pro i/o operace a jeho defragmentace jsou (mebo alespon muzou byt) dve rozdilne veci:
Defragmentace podle mne znamena, ze data souboru jsou za sebou fyzicky umistena byte po bytu, bez nutnosti preskakovat jakekoliv nesouvisejici "mezi-clustery".
Vykon zase znaci, ze casto ctene soubory jsou fyzicky presunuty takovym zpusobem, aby nedochazelo ke zbytecnym prodlevam pri jejich cteni. V nekterych pripadech to muze odpovidat vyse zminene defragmentaci, v jinych se zase data paralelne "rozprostrou" mezi vsechny plotny disku tak, aby nedochazelo ke zbytecnemu komihani hlavicek disku.
Jestli se v necem mylim, rad si prectu jine vysvetleni. -
eee (neregistrovaný)Doufas ze windows nikdy nebudou umet defragmentovat prubezne pri praci, jako to umi linux, procpak? Me to prijde velmi vyhodne.
Musim te zklamat, unixy rovnez umi planovane spoustet ulohy na pozadi s nastavitelnou prioritou, rekl bych dokonce, ze dele nez vubew windows existuji :-). -
JardaP (neregistrovaný)Tim bych si nebyl jisty. V dobe prvnich Linuxu to mohly byt tak Windows 98 a Windows NT. Windows 98 ma jakysi klikaci task scheduler. Na nastaveni priority si nejak nemohu vzpomenout, i kdyz jsem ho nikdy moc nepouzival. Windows NT ma at prikaz, ktery je tak blby, ze radsi nekdo napsal ntcron. Na command line utilitu pro spusteni procesu s jinou, nez defaultni prioritou, si nejak nemohu vzpomenout. Zadne prekvapeni v systemu, kde neni ani whois. Nevylucuji, ze neco bylo v Ressource Kitu, ale na nic si nevzpominam. Ovsem vzhledem k tomu, jak "dobre" byl RK zdokumentovan, kdyz jedinou dokumentaci byly nazvy utilit a nekdy i help, ktery umely vypsat po aplikaci nektereho z rady switchu (-? /? -h -help /h /help), je mozne, ze jsem neco prihledl. Takze leda sehnat nejakou utilitku z Internetu, ale tyhle veci se sefovi tezko vysvetluji. Koneckoncu se mu nedivim, kdo mu zaruci, ze v tom nejsou chyby nebo nejake svinstvo.
-
Windows 98, a tuším i NT 4 po nějakém SP, mají scheduler s GUI. V NT byl příkaz AT, který byl zcela v pohodě. Příkaz pro spuštění procesu s jinou prioritou se jmenuje start. Resource Kit Tools jsou zdokumentované velmi dobře v přiložených souborech, a samozřejmě v Resource Kitu jako takovém.
Kdo vám zaručí, že v něčem,co si stáhnete pro Linux (včetně vlastního distra) není nějaké svinstvo? Asi nikdo, že? -
JardaP (neregistrovaný)Prominte, ale k RK, ktery jsem mel k Win NT ja, nebyla dokumentace prakticky zadna. Par .doc fajlu na CD (asi tak 3), pak u nekterych utilitek help. U nekterych jen nesrozumitelny vypis options (treba subinacl, o kterem bylo prd i v Technetu, navic to prd bylo zastarale, pro predpotopni verzi). Mozna, ze se nekde susily knihy, ale ty jsou mi na prd, kdyz neznam jejich topologickou polohu, ktera muze byt ve filialce na druhem konci mesta.
Sheduler s GUI byl v NT Ressource Kitu. Byl uplne hrozny, neco, co by napsali pionyri v hodinach vyuky programovani na IQ151. A rikejte si, co chcete, na Win NT a vyse jedine ntcron. Navic, byly i doby, kdy se Microsoftu zahadne ztracely polozky at scheduleru z registry. Pravda, je to jiz dlouho.
Svinstvo muze byt vsude, nicmene oficialni fajl v distru nebo ze site Microsoftu je pravdepodobne cisty, i kdyz v obou pripadech se chybicka vloudila. Microsoft mel viry, nejaka lokalizovana verze nejakeho distra mela rootkit. Ovsem kdyz pujdete na Tucows nebo warez sajty, riskujete mnohem vic. -
SubInACL jsem nepoužíval. Většina utilit vypisuje sama o sobě slušnou nápovědu, další mají dokumentaci v instalačním adresáři. A ano, v knize byly utility popisované. Na CD byla elektronická verze knih.
V NT4 po instalaci nějakého SP nebo verze MSIE byl k dispozici plánovač podobný tomu ve Windows 98 nebo Windows 2000. Ruku do ohně za to ale dávat nebudu. Položky AT se mi z registry neztrácely. Tedy ztrácely, poté co se job provedl ;)
Oficální file v distru možná bude OK. Když ovšem něco stáhnete, tak je to bez digitálního podpisu sázkou do loterie. Proto MS své soubory podepisuje. -
anonymníNa CD byla stara bela.
Typicka instalace Linuxu obsahuje prakticky vse z oficialni distribuce. Nevim, jestli vsechna distra pouzivaji podpisy nebo md5sum nebo neco v tom stylu, ale koncept rozhodne neni neznamy.
Typicka instalace Windows obsahuje par veci od Microsoftu a hafo veci z jinych, casto neoveritelnych a casto naprosto neduveryhodnych zdroju.
Riziko je u neoficialnich veci vyssi i na Windows. Pro Linux byva zverejnovan spise zdrojak, protoze by jinak autor musel delat binarky pro kdejake distro. Na Windows je temer vzdycky binarka, zdrojak by stejne nebylo cim zkompilovat. -
Možná proto, že FS ani na Linuxu při práci nic nedefragmentuje :). Snížení celkové fragmentace může být vedlejším efektem vytváření a mazání souborů na disku, což je u dnešních FS více-méně nezávislé na konkrétním FS (podobně jako fakt, že novější FS začínají masivně fragmentovat až při vysokém stupni zaplnění disku).
Ano, unixy umí pouštět plánované úlohy. Ovšem málo který unix umí řídit prioritu I/O operací. A Linux (mimochodem ještě pořád nemá ani prioritizaci IRQ?) mezi takové systémy nepatří. Abych to vysvětlil i pro eee: priorita procesu nezajišťuje, že nezabere velké procento přenosového pásma disku. Proces s nízkou prioritou dostane čas procesoru, jen pokud ho nikdo jiný zrovna nepotřebuje (odborníci odpustí zjednodušení). Bohužel pokud proces s nízkou prioritou například prochází adresáře a čte soubory, vygeneruje s klidem přes svou nízkou prioritu daleko více I/O operací, než ostatní procesy dohromady. Ostatní procesy potom čekají na disk, a celý systém je tuhý. Proto má Vista řízení priority I/O operací, a možnost zaručeného průtoku dat. -
Glubo (neregistrovaný)Jen škoda, že není v běžně dostupných souborových manažerech pro windows toto API použito a proto když člověk kopíruje velký objem dat, u kterého by mu nevadila nižší priorita, aby mohl na popředí pracovat, tak je situace obdobná jako v systémech bez I/O priority. Bohužel mít API není vše, je potřeba, aby to API taky někdo používal a fungovalo to.
-
S tím API jsou to moje slova, ale zpravidla takové věci říkám o Linuxu ;). Samozřejmě Vista používá prioritizaci I/O operací tam, kde to má smysl. Například přehrávání multimédií, defrag apod. Když kopírujete data v GUI, jde o akci na popředí, a tedy logicky s normální prioritou. Věřím, že nějaký nástroj typu Total Commander jednou nabídne kopírování s nastavitelnou prioritou. Ovšem když vezmu v úvahu, že některé amatéry psané file managery dodnes neumí Unicode, a léta ukládaly nastavení do konfiguráku v adresáři Program Files(!), může to chvíli trvat ;)
-
Rejpal (neregistrovaný)
"One of the coolest things about CFQ is that it features I/O priorities (since 2.6.13). That means you can set the I/O priority of a process so you can avoid that a process that does too much I/O (daily updatedb) starves the rest of the system, or give extra priority to a process that shouldn't be starved by other processes, by using the ionice tool included in schedutils (since version 1.5.0)."
Co přesně potřebujete, že Vám tohle nestačí? -
Anče (neregistrovaný)moooc vtipne: "...jde o opravdový defrag (ne prosté zkopírování souboru)..."
jisteze to musi delat jinak! ten windowsackay FS je tak spatny ze tam vznika fragmentace uz i pouhym kopirovanim, takze by jim to kopirovani je zhorsovalo stav.
naopak vyspele FS se maji tendence dostavat pohybem souboru zpet do rovnovazneho stavu... sorry ale to je setsakra velky rozdil!
windows proste nemaji momentalne z tohoto pohledu zadny fs kterym by dokazali zaujmout. a nevypada to ze by dokazali vyvynout, ukradnout nebo jak to ted delaji ... neco co by mohli nabidnout jako opravdovy FS. Ledaze by si malomeci koupili k pristim vanocum ZFS...:-) -
anonymníJo to je fakt:) Srovnavat ext3 s 30 let starou FAT, to je linuxarum podobne:o) S nicim jinym ten svuj systemek nez s 30 let starou technologii, ani nemuzou... Taky uz nejaky patek (davno pred ext3) existuje treba NTFS, ale takovehle honosne informace tu davat, mi pripadne jak hazet perly svinim.
Samozrejme z principu veci bude treba na file serveru, kde budou HDTV filmy, podstatne mene fragmentovane na FAT32, ale to jen tak mimochodem .... to, ze nekomu bezi linux x let bez fragmentace, kterou si nemuze objektivne zjistit je fakt super:) Linux se svyma 250 tisici malickych souboru, kde se vetsina vejde do jednoho logickeho clusteru, to je fakt srovnani jak cyp! Pokud budete ten filesystem skutecne pouzivat a budete tam mit mp3ky, filmy a vsechno, tak se samozrejme zafragmentuje uplne stejne jak cokoliv jineho ...
Ale jinak se bavim, jak hromada zabednenych(zfanatizovanych) linuxaru, ten svuj malicky filesystem a operacni systemek obecne obhajuje ... co by se stalo, kdyz bych napsal zcela objektivni fakt, ze NTFS je architektonicky podstatne lepsi nez EXT3FS.
To by tu asi napsala spousta neznalku velky flame o tom, jak je ext3 lepsi i navzdory tomu, ze nemaji ani nejmensi paru ani o tak zakladni veci, co ktera zkratka vlastne vubec znamena:o) -
anonymníAha, takze pokud tam budes mit staticky system, kde nebudes nijak kopirovat a mazat velke soubory, tak mi laskave vysvetli, proc bys mel kdy pouzivat nejakou defragmentaci? Cimz se dostavame k tomu, proc serverove systemy defragmentaci prakticky nepotebujou. A sice zcela jednoduse proto, ze se jednou nainstalujou a nikdo do nich nehrabe zpusobem, ktery by zpusobil fragmentaci. Coz je naprosto, ale zcela uplne jiny pripad nez pripad desktopu (Windows), kde se takova cinnost predpoklada v mire vetsi nez velke a jsme u toho, proc linux defragmentaci nepotrebuje a sic, protoze to neni desktopovy system a pro tech par individui, co ho jako desktop pouzivaji hold vznikl tento velmi ale opravdu velmi pochybny defragmentovaci nastroj v pythonu:)
Jen tak nastinim, ze defragmentace, teda aspon za mych mladych let, byla povazovana za vypocetne velmi narocny algoritmus na optimalizaci, nicmene to se asi zmenilo, kdyz se to dela v pythonu, stylem: zkusim to 10x a kdyz to nepomuze, tak uz se to asi nezlepsi:)
Ale jako takove technicke introduction, kde asi ty linuxy dneska technologicky jsou, je to vhodne. Jen tak pro informaci, NTFS 3.1 je z vyse jmenovanych FS nejnovejsi, da se teda predpokladat, ze bude implementovat nejnovejsi technologie, chapu, ze lidi tu technologicky umreli u windows 95 (nekteri 3.11) a u FAT a s tim vse srovnavaji, ale jen jsem chtel pripomenout, ze je tu treba to NTFS, proti ktere jsou veci jako ext3fs technologicky po vsech strankach zastarale ... ale zase proc se hadat s lidma, co nevi, ze NTFS ma security descriptory a tvrdi, ze jen linux dokaze smazat pouzivany soubor ... no, fakt hazeni pervitinu svinim ... -
JardaP (neregistrovaný)PROC je NTFS lepsi? To, ze je, jsem tu cetl jiz nekolikrat. Ale to proc mi tu furt chybi. Jinak ACL umi EXT3 take. Potiz je jen v tom, ze to neumi vsechny utilitky a tak se treba zalohuji ACL zvlast, protoze je tar neumi. Tedy, pokud se to zatim nezmenilo.
Jinak s temi ACL se na Windows NT da nadelat takovy bordel, ze uz pak nikdo nevi, co, jak, kdy a proc a jiz to jen tak ze setrvacnosti existuje. Nastroj, ktery by se to vypsalo do nejakeho csv a prohrablo programem, neexistuje. Existuji utilitky z Ressource Kitu, ktere obvykle neumi nastavit separator ve vypisu a tak jsou na hovno. Diky nazvum s mezerami se programove tezko odlisuje, kde co konci a kde zacina neco jine. A pokud do te NT site hrabne nekdo s enhanced ACL editorem nebo jak se to, je to uz uplny bordel. Kazde z access right, jak je kazdy zna, se rozpadne na dve a mozna vice detailnejsich prav, pricemz zjistit, co cemu odpovida, lze jen systemem pokus-omyl. Primitivni pristupova prava na NIXech stylu ugo maji sve vyhody v pripadech, kdy s nimi lze vystacit. Vznik takoveho chlivku je totiz fyzicky nemozny.
BTW, na NTFS mi chybi symlinky. Hardlinky sice ntfs umi, ale ty moc nepouzivam. Navic Microsoft, jako obvyhle, chytre nedodava utilitku, ktera by s nimi umela. Takze zase zbyva jen sysinternals.
BTW, zda se, ze pervitin svinim nehazis, ale zeres ho sam. Tak nevim, jak pusobi pervitin. Rika se, ze heroin=agresivita, kokain=arogance. Ze by pervitin=anonymita? -
NTFS má řadu features, které konkurenční FS nemají. Umí ACID transakce (například zapiš do souboru A, zapiš do souboru B, proveď update databáze C, poté proveď jeden commit nebo rollback). Má ACL, quoty, transparentní kompresi, transparentní šifrování, ukládá názvy souborů vždy v Unicode, umí snapshoty, má podporu rozšířovacích modulů (například bezešvá integrace HSM), umí hard linky, je POSIX compliant. Windows nabízejí také backup API, které vám umožní provést zálohu čehokoliv bez ohledu na permissions (pokud máte permissions k tomu API), s tím že šifrované soubory se dumpují šifrované. To je velmi silná sada features.
Access Control List se dá z command line editovat pomocí cals/icals. V praxi se to ale dělá téměř výhradně z GUI. Samozřejmě vACL lze vyrobit bordel, ale zase nabízí velikou flexibilitu. Naštěstí admini vědí, jak s ACL dělat. V unixech musíte vytvářet stovky skupin, místo každé kombinace práv jednu skupinu, což je daleko horší přístup. Pokud máte na unixech ACL (což dodnes není samozřejmé), bordel lze vyrobit stejný, jako ve Windows. Rozdíl je v tom, že ve Windows ho lze v grafickém editoru ACL rychle a pěkně uklidit.
Hardlinky se pravují utilitou fsutil. Obecně se doporučuje je nepoužívat, protože mohou vést k cyklu ve stromu (proto pro ně není GUI). -
JardaP (neregistrovaný)Tim grafickym editorem ACL myslite takovou tu klicovou dirku pevne definovane velikosti, kde porad vsim soupete nahoru a dolu a zleva doprava? V tom se to moc dobre neuklizi, kdyz tam nic poradne nevidite. Alespon chliv, ktery jsem ja videl, byste v tom delat nechtel. Autorum tehlech dialogu by meli useknout obe ruce az u zadku. A Billovi Gatesovi za to, ze od dob Win NT furt jeste nejdou zvetsit. Navic ani nemaji tab na taskbaru, pokud se pamatuji, takze kdyz vam na jedinem desktopu pod neco zapadnou, tak se nahledate.
A ne vsichni admini vedi, jak s ACL delat. Tedy vedi, jak s ACL delat bordel. 50 serveru, 500 workstejsnu a je to. :-) -
Editace ACL je opravdu ve fixed size dialogu (příští verze Windows je bude mít zvětšovací). To v praxi ale není problém. Pokud se vám dialog roluje do stran, nastavte si lepší velikost sloupců tažením myší.
Opravit ACL zpravidla znamená jít do dialogu Advanced, zaškrtnout Replace All a stisknout OK. Smozřejmě existují i složitější manévry ;)
Ano, špatní admini neumí dělat s ACL. Buď jim země lehká. -
anonymníUzasne. Je treba peti generace Windows na to, aby byla opravena zcela zasadni a velmi neprijemna, rekl bych jedna z nejhorsich, chyba v GUI! To se nam ten pokrok hybe. Koneckoncu teprve pata generace Windows opravila zavirani start menu, kdykoliv se otevrelo nejake menu, a to jeste snad az po SP2.
-
alpha (neregistrovaný)Prosim, vysvetluj. V cem je NTFS tolik lepsi nez ext3, krome toho ze se s nim pri defragu uzije o dost vic srandy? Vykonem jsou na tom podobne, zurnal maji oba, chyb obsahuji srovnatelne. Ja mam na ext3 i oggy nebo FLACy (tech druhych minimum) a fragmentaci nevidim. Filmy bohuzel newarezim a na HDTV nemam misto (fyzicky ani na disku).
Kterou zkratku neznam? -
JardaP (neregistrovaný)NTFS na fragmentaci samozrejme trpi, i kdyz podstatne mene, nez FAT a to az do doby, kdy zaplneni didku dosahne 88%.
Zurici flame war me vyprovokovala ke googlovani a nasel jsem zajimavy link: http://www.digit-life.com/articles/ntfs/. Doporucuji precist cast "Part 2. Features of NTFS defragmentatoin" (vcetne preklepu). Zajimave je, ze jednim z duvodu fragmentace je pouzit defragmentacni API, ktera zanechava disk plny malych der, ktere pak OS vyplni pomalu rostoucimi soubory. Nasledne se muze defragmenbtovat znovu a tak porad dokola. Prikladem by mohla byt fragmentace swap file, pokud ho clovek nema nastaven natvrdo na pevnou velikost, jako ja.
Cili se da rici, ze nejlepsi je disk nedefragmentovat, dokud to jede slusne, potom presypat data jinam, zformatovat a nasypat zpet. U systemove partsny se tohle ale dela blbe, clovek potrebuje druhy pocitac a pak jeste musi nasypat zpet MBR. Cili se nam ta defragmentace na Windows nejak komplikuje.
Ze NTFS je architektonicky mnohem lepsi, nez EXT3 sem psat muzes, ovsem chtelo by to krapet podlozit. Propaganda Microsoftu, o kterou se tu asi s nami delis, neni zrovna argumentem. Napis sem zcela objektivni zduvodneni, proc je NTFS lepsi, nez EXT3. Fakt by me to zajimalo. Nepopiram, ze je to robustni FS, ktery prezije docela dost, ale uz se mi stalo, ze jsem nedokazal smazat adresar a v nem lezicich nekolik souboru, ktere se samovolne prejmenovaly (bez padu systemu) na jmena obsahujici otazniky a podobne znaku. Windows NT utilitka na opravu disku (scandisk nebo jak se to) s tim nic nenadelala, pomohl az format. A problemy s fragmentaci a skvele defrag API me take moc nerajcuji. -
Samozřejmě většina FS vykazuje fragmentaci, a ty zbylé mají různé zásadní nevýhody (napříkad fixní velikost souboru, tam pak fragmentace není).
Linkovaný článek je postavený na zastaralých informacích. Například kopie prvního bloku se v půjce partition nacházela naposledy na NT 3.51, defragmentace po 16 blocích byla naposledy ve Windows 2000 (s odůvodněním, že tak malá fragmentace nemá vliv na výkon). Defragmentace swapu není problém, protože swap zůstává na své minimální velikosti, dokud nenastane nedostatek paměti. Ta minimální velikost zůstává trvale nefragmentovaná, zbytek nemá smysl defragmentovat (existuje jen krátkodobě).
Ano, na unixech je lepší nedefragmentovat, protože pro to zpravidla chybí nástroje. Tradičním způsobem defragu je pak vysypat disk na pásku (raději na 3 pásky), znovu vytvořit FS, a provést restore. Ve Windows naštěstí umíme defragmentaci na přimontovaném FS, a nyní i s nízkou prioritou I/O operací (neruší ostatní diskový provoz).
Poškozený FS opraví chkdsk. Pokud jména obsahují otazníky, jde o názvy obsahující Unicode znaky, a vy používáte aplikaci, která neumí Unicode (třeba Total Commander, psaný pro Windows 9x). Zkuste Windows Explorer, nebo jakýkoliv jiný nástroj, který nepsala prasata.
Proč je NTFS dobrý FS? Viz
http://www.root.cz/clanky/defragmentace-disku-v-linuxu/nazory/182761/ -
JardaP (neregistrovaný)Mozna, nevim. Vidim jen to, co pisi.
Nicmene se mylite, co se tyce tech otazniku. Ty vznily tak, ze jsem preinstaloval NT na novy disk. Pak jsem tam strcil stary disk, presypal vsechno do jednoho podadresare. Postupne jsem to pak probiral a kopiroval jinam. Zbytek jsem tam nechal valet, kdybych si vzpomnel, ze jeste neco potrebuji. Pak najednou zahadne vznikly ty otazniky ve jmene toho adresare, kde byla ta stara data. A kdyz jsem pak jednou chtel vymazat vsechno, co zbylo a nebylo potreba, zbyl mi ten adresar a v nem nekolik adresaru s podobne zmrsenymi nazvy a par souboru s podobnymi nazvy uvnitr. Nebylo cesty, jak to smazat, pomohl pak az format, pri dalsim upgrade na vetsi disk. Chkdsk nic nezmohl, ani kdyz byl. A Unicode tehdy snad vubec na Windows NT neexistovalo. To snad az tusim Windows XP. Nevim, kdo by tam ty Unicode znaky za mymi zady nacpal. Krome toho, kdyby to byl Unicode a neodpovidalo to specifikacim FS, Windows NT a co ja vim ceho, ocekaval bych od chdsk, ze to uvede do stavu odpovidajicimu specifikacim, i kdyby ty nazvy mel zmenit. Smazat to nejde, dalo se sice vlezt do tech divnych adresaru, ale ty soubory uz otevrit nesly. Tak co s tim? -
Obávám se, že se mýlíte vy. Windows NT jsou kompletně v Unicode od první verze, nikoliv od XP :). Ne-Unicode aplikace (tj. ty psané pro Windows 9x bez použití Unicode layeru) jedou v jedné vybrané code page, stejně jako na Windows 9x, a jejich volání se překládají do Unicode. Pokud je v názvu souboru znak, který je mimo kódovou stránku ne-Unicode aplikace, zobrazí se ten znak jako otazník. Total Commander a podobé kousky neumí (nebo dlouho neuměly) Unicode, protože je psala prasata (Total Commander mimo jiné ukládal konfiguraci v Program Files). Ve vašem případě si navíc tipnu, že jste po instalaci Windows nechal kódovou stránku na americké (locale je na tom nezávislé), takže ne-Unicode aplikace viděly i české znaky jako otazníky. Předpokládám, že některé dřevní aplikace měly také zmršenou češtinu v menu apod.
Popsaná situace je by design. Stačilo vzít Windows Explorer, a soubory byly v pohodě. Tedy ještě mohl zafungovat třeba antivir napsaný prasaty, ale to už by bylo asi fakt moc :). Dalším zjevným řešením by bylo přepnout code page ne-Unicode aplikací. Chkdsk s tím neměl co dělat, protože FS byl v pořádku.
Když to shrnu, problém byl v kombinaci zprasených aplikací a vaší neznalosti. Smozřejmě IT jako obor má maximum takových situací eliminovat, a uživatele tím nezatěžovat. Pokud ale pracujete s unixy, podobná překvapení jistě zažíváte každý druhý den. -
anonymníAno, kodova stranka byla asi americka. Windows byla anglicke verze. Ovsem podotkneme, ze na disku nebyl jediny soubor s ceskym nazvem ani soubor, s jakymkoliv znakem s diakritikou v nazvu. Navic adresar existoval po dlouhou dobu se jmenem ktere jsem mu dal a ktere necinilo zadne problemy. Teprve po te se samovolne prejmenoval. Jak k tomu doslo nemam nejmensi tuseni. S neznalosti Windows to nema co delat, se zprasenymi aplikacemi take ne. Pokud Windows nedokaze smazat soubor na svem disku, je to problem zprasenych Windows. Nemela v prve rade vznik takoveho souboru povolit.
BTW, Windows jsou s timhle otravna. Staci zkopirovat z Linuxu pres Sambu soubor s nazvem s dvojteckou nebo otaznikem ci nekolika jinymi znaky a je to v haji, pricemz dvojtecka je ze vsech nejvic vypecena. Windows to nedokazi ani smazat. Staci, abych nekomu vytvoril pres sit soubor s takovym nazvem, ktery mu zaplacne cely disk a muze si jit koupit novy disk a vse preinstalovat. -
LO (neregistrovaný)A proto je optimálním algoritmem defragmentace zkopírovat soubor na jiné místo na disku, a doufat, že bude méně fragmentovaný. A tento postup pak opakovat do doby, než bude fragmentovaný dost málo. Ošklivé Windows mají nějaké blbé API, které umožňuje přímo hýbat s bloky na disku, fuj ;)
http://msdn2.microsoft.com/en-us/library/aa363911(VS.85).aspx
Windows mají fakt mizerný FS. NTFS pravda žurnálový FS, který má nyní i ACID transakce (napříč soubory), má Access Control Listy, transparentní kompresi, Sparse files ("děravé" soubory), žurnál změn (zásadně urychluje backup), transparentní šifrování, Alternate data streams, quoty, Volume Shadow Copy, Single Instance Storage, RAID 1/5 a další. Ano, je to všechno v jednom FS, a je to na každém počítači s Windows řady NT. Ale na Linuxu máme lepší FS. Jeden umí quoty, další access control listy, pak jeden který umí oboje, dva co umí transparentní šifrování... ;) -
a prosim ta, k comu je linuxu potrebny editor registrov, ked veskera konfiguracia sa zapisuje do textovych suborov v adresari /etc? staci ti na to nejaky jednoduchy textovy editor (napr. vim, ci ten v mc),
ale na Windowse rady 9x a WinNT je potrebny editor registrov, lebo v nich je konfiguraxcia v podobe niekolkych binarnych suborov a bez editora sa asi tazko nieco nastavi -
JardaP (neregistrovaný)Opakuji se, jiz jsem to psak jinde, ale prectete si http://www.digit-life.com/articles/ntfs/, cast Part 2. Features of NTFS defragmentatoin. Jak se zda, neni to s fragmentaci NTFS tak slavne, jak Microsoft tvrdi a defrag API je opravdu nejake blbe. Jedinym zpusobem, jak defragmentovat NTFS disk, je presun na jiny disk, format, presun zpatky. Format je asi jedinym zpusobem, jak defragmentovat MFT. Ani defrag API to neumi. Cili se smejte, ale na Windows je to jeste horsi, nez na Linuxu. S fragmentaci na NTFS je to tak, ze k ni dochazi v docela velke mire, i kdyz mene, nez na FATu. Rozdil je v tom, ze vykonove se to na NTFS mnohem mene projevuje, nez na zminene vykopavce FAtu.
