Jeden z vývojářů ext4 začal používat vlastní souborový systém
1. 7. 2008 13:35
Adam Štrauch
Pro souborový systém je to velký den, když mu jeho vlastní vývojář začne důvěřovat a nasadí ho do ostrého provozu. Na LWN.net se můžeme dočíst, jak vývojář ext4 Ted Ts'o nasadil na svůj notebook právě tento souborový systém. V jeho komentáři k tomuto přechodu se mu podařilo narazit jenom na jeden nepříjemný bug při zapnutém „delayed allocation“, kdy soubor mohl mít nulovou hodnotu blocksize hned po té co byl vytvořen. Ted píše, že zatím na nic velkého nenarazil, ale bude zálohovat svůj notebook častěji.
Ext4 (fourth extended filesystem) byl zařazen do jádra 2.6.19 a jedná se o rozšířené ext3 a je sním zpětně kompatibilní. Díky tomu je možné mountovat ext3 filesystém jako ext4 a obráceně. Tato vlastnost mu je často vytýkána, protože držením zpětné kompatibility mají vývojáři v ledasčem svázané ruce a některé vlastnosti se tam tak dostat nemohou. Ext4 posunuje limity svého starého bratříčka. Maximální velikost souboru může být 16TB (místo 2TB), velikost oddílu 1EB (místo 16TB) a počet podadresářů je neomezený (místo 215). Maximální počet souborů zůstal stejný (232). Ext4 se také snaží bojovat různými způsoby proti fragmentaci. Jednou z těchto metod je zmíněná vlastnost „delayed allocation“, díky které se zápis na disk oddaluje co nejvíce je to možné a zapisují se až větší bloky dat. Další vlastností zabraňující fragmentaci je „persistent pre-allocation“. Díky tomu nové ext4 alokuje pro soubor větší prostor než je zprvu potřeba. To se velmi hodí například databázím. Tyto metody nezabrání fragmentaci úplně, a proto ext4 má nástroj pro online defragmentaci, díky němu můžeme defragmentovat jednotlivé soubory nebo celý souborový systém.
Dále čtěte…
- Vyšlo linuxové jádro 3.4 22. 5. 2012 9:15
- Linux 3.4 vyjde již tento týden 14. 5. 2012 12:46
- Microsoft je jedním z největších přispěvatelů do Linuxu 4. 4. 2012 13:12
- Co nabídne chystané jádro 3.4? 4. 4. 2012 11:29
- Vyšlo jádro 3.3 20. 3. 2012 12:59
machrostroj (neregistrovaný)
1. 7. 2008 14:43
Nový
bla bla
celé vlákno
hmmmmmmm takze lunetix uz bude umet defragmentovat... jeste dalsich dvacet let a uz mozna bude mit i kloudny gui :D
Rejpal (neregistrovaný)
1. 7. 2008 15:00
Nový
Re: bla bla
celé vlákno
Linux samozřejmě umí defragmentovat už velmi dlouho, pokud člověk nutně cítí tu potřebu. Tedy celkem pochopitelně to nedělá na FAT32. :-)
Lael Ophir (neregistrovaný)
2. 7. 2008 17:46
Nový
Re: bla bla
celé vlákno
Ještě kdyby nebylo nutné kvůli tomu FS odmountovat. Mimochodem FAT32 z defragmentace zrovna dost těží. Proč ho nedefragmentovat?
1. 7. 2008 15:43
Nový
Re: bla bla
celé vlákno
Uprimne receno od dob co jsem presedlal na Linux a bez sebemensiho problemu uspesne provozuji Ext3 jsem jeste nikdy nemel potrebu defragmentovat disk...
Vlastne jsem si vzdycky myslel, ze pravidelna ztrata casu defragmentaci je povinnosti pouze na FAT ci NTFS...
Co se tyce "kloudneho GUI" jedna se o velmi relativni otazku - kazdemu co jeho jest a diky bohu je na tom Vasem "lunetixu" k vyberu z mnoha...
Jinak ne nadarmo se rika, ze odrikaneho chleba nejvetsi krajic, ze?
Vlastne jsem si vzdycky myslel, ze pravidelna ztrata casu defragmentaci je povinnosti pouze na FAT ci NTFS...
Co se tyce "kloudneho GUI" jedna se o velmi relativni otazku - kazdemu co jeho jest a diky bohu je na tom Vasem "lunetixu" k vyberu z mnoha...
Jinak ne nadarmo se rika, ze odrikaneho chleba nejvetsi krajic, ze?
Tommy (neregistrovaný)
1. 7. 2008 16:03
Nový
Re: bla bla
celé vlákno
Linux za běžných okolností defragmentovat víceméně nepotřebuje, protože ukládá soubory takovým způsobem aby k defragmentaci pokud možno nedocházelo. Ne že by k ní nedocházelo vůbec nebo že by nešlo vymyslet krajní situace kdy je defragmentace problém i na Linuxu, ale za běžného používání k tomu nedochází.
Ale třeba se to ty vaše Windows časem naučí taky, nebojte ... určitě to pak ale uvedou s velkým humbukem jako přelomovou novinku kvůli které je potřeba reinstalace celého systému ...
Ale třeba se to ty vaše Windows časem naučí taky, nebojte ... určitě to pak ale uvedou s velkým humbukem jako přelomovou novinku kvůli které je potřeba reinstalace celého systému ...
Windowsak (dokonca Vistak) (neregistrovaný)
1. 7. 2008 16:16
Nový
Re: bla bla
celé vlákno
Chytraku a vies o tom, ze Linux fragmentuje volne miesto. Napriklad ak pri starte system potrebuje subor /etc/rc.d/s01 a za tym bude potrebovat napr. /etc/conf.d/gpm, tak je sice pekne, ze su subory v jenom suvislom streame, ale hlavicka kvoli sposobu ulozenia suborov v Linuxe moze absolvovat prelet mozno aj cez cely disk. Naozaj chytra feature.
aura:99
1. 7. 2008 16:59
Nový
Re: bla bla
celé vlákno
V praxi není důležitá délka přeletu, ale počet přeletů. Mnohem horší je fakt, že Windows běžně házejí soubory za sebe. Nejlépe malé a nejlépe ty co se mění :)
Inkvizitor (neregistrovaný)
1. 7. 2008 17:18
Nový
Re: bla bla
celé vlákno
No to je fakt hrůza. Dokonce ty soubory můžou být na dvou různých discích a pak létají dvě hlavičky. ;-)
Rejpal (neregistrovaný)
1. 7. 2008 17:24
Nový
Re: bla bla
celé vlákno
Doba přesunu hlavičky na blok na sousední stopě a na blok na druhém konci disku se liší tak o půl řádu. Rotaci ploten nijak neurychlíte, a vzhledem k tomu, jak disk skrývá svou fyzickou geometrii, je obtížné hádat, jak jsou bloky situované vůči sobě po obvodu. "Přes celý disk" tedy v reálu není v porovnání s dokonalým řazením čtených bloků za sebe o moc horší, neř "jen o pár stop bokem". Ostatně poměrně brzo tohle díky SSD nebudeme muset tolik řešit, tedy aspoň ne tam, kde to může opravdu vadit. :-)
Kyknos (neregistrovaný)
1. 7. 2008 19:10
Nový
Re: bla bla
celé vlákno
co ten tvůj disk, ehm celý počítač? :)
Rejpal (neregistrovaný)
1. 7. 2008 19:15
Nový
Re: bla bla
celé vlákno
Co disk? Co počítač? Stavím se, ale musí to pár dní počkat, ju? (Navíc ještě pokašlávám doma.)
uživatel si přál zůstat v anonymitě
1. 7. 2008 18:10
Nový
Re: bla bla
celé vlákno
Windows fragmentují volné místo taky, v tom si nijak nepomůžete. To, co popisujete, je spíše prefetch, který funguje trošku jinak.
Postupně analyzuje běžně používané programy a načítání jejich částí (kusy kódy, kusy knihoven atd.) a tyto části uloží samostatně a seřadí je na disku tak, aby jejich načítání bylo co nejplynulejší. Lze tak velmi výrazně zrychlit jak start systému, tak pochopitelně start i běh nejpoužívanějších aplikací. Prefetch je průběžně defragmentován a dále optimalizován. Tohle Linux skutečně v tuto chvíli nemá a rozhodně by to byla velmi užitečná věc.
Jinak co se týče fragmentace - NTFS neukládá soubory hned za sebe. To se dělo na FAT. NTFS se v tomhle ohledu chová podobně jako ext3. Lze diskutovat o konkrétním algoritmu, lze diskutovat o tom, kolik volného místa je vhodné za souborem nechat, ale princip je v obou případech stejný - už při založení souboru se počítá s dalším zvětšováním souboru. Pochopitelně čím více zaplníte disk a čím častěji měníte obsah, tím větší je pravděpodobnost, že budete mít data fragmentovaná. Windows sice průběžně defragmentují (a ve Vistě je to na odezvě systému skutečně neznatelné), ale některé věci defragmentovat nestihne.
Vezměme konkrétní příklad:
Systémový disk - je tam nejen systém, ale také veškerý software, uživatelská nastavení, browser cache, temp a další často užívané věci. Není tam swap.
Sestava analýzy pro svazek D: VISTA
Velikost svazku = 77.43 GB
Velikost clusteru = 4 kB
Využité místo = 52.86 GB
Volné místo = 24.57 GB
Procenta volného místa = 31 %
Fragmentace souborů
Fragmentace souborů (procenta) = 1 %
Celkový počet přesunutelných souborů = 228,529
Průměrná velikost souboru = 230 kB
Celkový počet fragmentovaných souborů = 527
Celkový počet přebytečných fragmentů = 2,552
Průměrný počet fragmentů na soubor = 1.01
Celkový počet nepřesunutelných souborů = 87
Fragmentace volného místa
Volné místo = 24.57 GB
Celkový rozsah volného místa = 4,901
Průměrné volné místo na rozsah = 5 MB
Největší rozsah volného místa = 17.98 GB
Fragmentace složek
Celkový počet složek = 25,496
Počet fragmentovaných složek = 2
Počet přebytečných fragmentů složek = 4
Fragmentace hlavní tabulky souborů (MFT)
Celková velikost tabulky MFT = 224 MB
Počet záznamů tabulky MFT = 229,049
Procento využití tabulky MFT = 99
Celkový počet fragmentů tabulky MFT = 26
Fragmentace je mizivá.
Datový disk - celkem velké zaplnění, data se průběžně mění (cca 1-2 GB denně).
Sestava analýzy pro svazek E: work
Velikost svazku = 298 GB
Velikost clusteru = 4 kB
Využité místo = 249 GB
Volné místo = 48.96 GB
Procenta volného místa = 16 %
Fragmentace souborů
Fragmentace souborů (procenta) = 7 %
Celkový počet přesunutelných souborů = 170,520
Průměrná velikost souboru = 2 MB
Celkový počet fragmentovaných souborů = 1,556
Celkový počet přebytečných fragmentů = 187,107
Průměrný počet fragmentů na soubor = 2.17
Celkový počet nepřesunutelných souborů = 5
Fragmentace volného místa
Volné místo = 48.96 GB
Celkový rozsah volného místa = 139,198
Průměrné volné místo na rozsah = 369 kB
Největší rozsah volného místa = 358 MB
Fragmentace složek
Celkový počet složek = 11,340
Počet fragmentovaných složek = 47
Počet přebytečných fragmentů složek = 141
Fragmentace hlavní tabulky souborů (MFT)
Celková velikost tabulky MFT = 187 MB
Počet záznamů tabulky MFT = 191,486
Procento využití tabulky MFT = 99
Celkový počet fragmentů tabulky MFT = 2
Tady je už fragmentace znát hlavně kvůli zaplněnosti disku. Je tady ovšem silně fragmentovaný volný prostor. Každopádáně to už akutně chce větší disk...
A pak mám verzovací a zálohovací disk pro více PC. Tam se data mění hodně (20-30 GB denně), navíc tam nikdy není víc než 10 % volného místa (dost často to jsou jen stovky MB) a tam je to prostě fragmentované obrovsky a nic s tím nenadělá žádný filesystém. Že se tam děje hodně změn je ostatně vidět i na MFT.
Sestava analýzy pro svazek F: TEMP
Velikost svazku = 233 GB
Velikost clusteru = 4 kB
Využité místo = 214 GB
Volné místo = 19.06 GB
Procenta volného místa = 8 %
Fragmentace souborů
Fragmentace souborů (procenta) = 67 %
Celkový počet přesunutelných souborů = 34,261
Průměrná velikost souboru = 11 MB
Celkový počet fragmentovaných souborů = 295
Celkový počet přebytečných fragmentů = 367,472
Průměrný počet fragmentů na soubor = 12.76
Celkový počet nepřesunutelných souborů = 6
Fragmentace volného místa
Volné místo = 19.06 GB
Celkový rozsah volného místa = 154,902
Průměrné volné místo na rozsah = 129 kB
Největší rozsah volného místa = 277 MB
Fragmentace složek
Celkový počet složek = 3,022
Počet fragmentovaných složek = 12
Počet přebytečných fragmentů složek = 48
Fragmentace hlavní tabulky souborů (MFT)
Celková velikost tabulky MFT = 208 MB
Počet záznamů tabulky MFT = 41,057
Procento využití tabulky MFT = 19
Celkový počet fragmentů tabulky MFT = 3
Postupně analyzuje běžně používané programy a načítání jejich částí (kusy kódy, kusy knihoven atd.) a tyto části uloží samostatně a seřadí je na disku tak, aby jejich načítání bylo co nejplynulejší. Lze tak velmi výrazně zrychlit jak start systému, tak pochopitelně start i běh nejpoužívanějších aplikací. Prefetch je průběžně defragmentován a dále optimalizován. Tohle Linux skutečně v tuto chvíli nemá a rozhodně by to byla velmi užitečná věc.
Jinak co se týče fragmentace - NTFS neukládá soubory hned za sebe. To se dělo na FAT. NTFS se v tomhle ohledu chová podobně jako ext3. Lze diskutovat o konkrétním algoritmu, lze diskutovat o tom, kolik volného místa je vhodné za souborem nechat, ale princip je v obou případech stejný - už při založení souboru se počítá s dalším zvětšováním souboru. Pochopitelně čím více zaplníte disk a čím častěji měníte obsah, tím větší je pravděpodobnost, že budete mít data fragmentovaná. Windows sice průběžně defragmentují (a ve Vistě je to na odezvě systému skutečně neznatelné), ale některé věci defragmentovat nestihne.
Vezměme konkrétní příklad:
Systémový disk - je tam nejen systém, ale také veškerý software, uživatelská nastavení, browser cache, temp a další často užívané věci. Není tam swap.
Sestava analýzy pro svazek D: VISTA
Velikost svazku = 77.43 GB
Velikost clusteru = 4 kB
Využité místo = 52.86 GB
Volné místo = 24.57 GB
Procenta volného místa = 31 %
Fragmentace souborů
Fragmentace souborů (procenta) = 1 %
Celkový počet přesunutelných souborů = 228,529
Průměrná velikost souboru = 230 kB
Celkový počet fragmentovaných souborů = 527
Celkový počet přebytečných fragmentů = 2,552
Průměrný počet fragmentů na soubor = 1.01
Celkový počet nepřesunutelných souborů = 87
Fragmentace volného místa
Volné místo = 24.57 GB
Celkový rozsah volného místa = 4,901
Průměrné volné místo na rozsah = 5 MB
Největší rozsah volného místa = 17.98 GB
Fragmentace složek
Celkový počet složek = 25,496
Počet fragmentovaných složek = 2
Počet přebytečných fragmentů složek = 4
Fragmentace hlavní tabulky souborů (MFT)
Celková velikost tabulky MFT = 224 MB
Počet záznamů tabulky MFT = 229,049
Procento využití tabulky MFT = 99
Celkový počet fragmentů tabulky MFT = 26
Fragmentace je mizivá.
Datový disk - celkem velké zaplnění, data se průběžně mění (cca 1-2 GB denně).
Sestava analýzy pro svazek E: work
Velikost svazku = 298 GB
Velikost clusteru = 4 kB
Využité místo = 249 GB
Volné místo = 48.96 GB
Procenta volného místa = 16 %
Fragmentace souborů
Fragmentace souborů (procenta) = 7 %
Celkový počet přesunutelných souborů = 170,520
Průměrná velikost souboru = 2 MB
Celkový počet fragmentovaných souborů = 1,556
Celkový počet přebytečných fragmentů = 187,107
Průměrný počet fragmentů na soubor = 2.17
Celkový počet nepřesunutelných souborů = 5
Fragmentace volného místa
Volné místo = 48.96 GB
Celkový rozsah volného místa = 139,198
Průměrné volné místo na rozsah = 369 kB
Největší rozsah volného místa = 358 MB
Fragmentace složek
Celkový počet složek = 11,340
Počet fragmentovaných složek = 47
Počet přebytečných fragmentů složek = 141
Fragmentace hlavní tabulky souborů (MFT)
Celková velikost tabulky MFT = 187 MB
Počet záznamů tabulky MFT = 191,486
Procento využití tabulky MFT = 99
Celkový počet fragmentů tabulky MFT = 2
Tady je už fragmentace znát hlavně kvůli zaplněnosti disku. Je tady ovšem silně fragmentovaný volný prostor. Každopádáně to už akutně chce větší disk...
A pak mám verzovací a zálohovací disk pro více PC. Tam se data mění hodně (20-30 GB denně), navíc tam nikdy není víc než 10 % volného místa (dost často to jsou jen stovky MB) a tam je to prostě fragmentované obrovsky a nic s tím nenadělá žádný filesystém. Že se tam děje hodně změn je ostatně vidět i na MFT.
Sestava analýzy pro svazek F: TEMP
Velikost svazku = 233 GB
Velikost clusteru = 4 kB
Využité místo = 214 GB
Volné místo = 19.06 GB
Procenta volného místa = 8 %
Fragmentace souborů
Fragmentace souborů (procenta) = 67 %
Celkový počet přesunutelných souborů = 34,261
Průměrná velikost souboru = 11 MB
Celkový počet fragmentovaných souborů = 295
Celkový počet přebytečných fragmentů = 367,472
Průměrný počet fragmentů na soubor = 12.76
Celkový počet nepřesunutelných souborů = 6
Fragmentace volného místa
Volné místo = 19.06 GB
Celkový rozsah volného místa = 154,902
Průměrné volné místo na rozsah = 129 kB
Největší rozsah volného místa = 277 MB
Fragmentace složek
Celkový počet složek = 3,022
Počet fragmentovaných složek = 12
Počet přebytečných fragmentů složek = 48
Fragmentace hlavní tabulky souborů (MFT)
Celková velikost tabulky MFT = 208 MB
Počet záznamů tabulky MFT = 41,057
Procento využití tabulky MFT = 19
Celkový počet fragmentů tabulky MFT = 3
aura:96
1. 7. 2008 18:11
Nový
Re: bla bla
celé vlákno
Uživatel si sice přál zůstat v anonymitě, ale má na to dokonce registrovaný glejt, který nevyplnil.
Ooaniki (neregistrovaný)
1. 7. 2008 19:00
Nový
Re: bla bla
celé vlákno
Takze kdyz uz nevime cim dal argumentovat ... tak se snazime zmenit tema :)
Rejpal (neregistrovaný)
1. 7. 2008 19:10
Nový
Re: bla bla
celé vlákno
Jak, "změnit téma"? Jako odpověď na tvrzení, že Linux fragmentuje volné místo a že to je problém, uvedl předřečník reálnou demonstraci toho, že volné místo je na NTFS fragmentováno zcela obdobným způsobem.
(Překlad "celkový rozsah volného místa" je sice matoucí, ale jakmile si člověk uvědomí, že se zde pouze microsoftí uklízeč slov III. cenové skupiny chytře nepodíval na překlad slova "extent", aby se vyhnul práci, je vymalováno. :-))
(Překlad "celkový rozsah volného místa" je sice matoucí, ale jakmile si člověk uvědomí, že se zde pouze microsoftí uklízeč slov III. cenové skupiny chytře nepodíval na překlad slova "extent", aby se vyhnul práci, je vymalováno. :-))
JardaP (neregistrovaný)
1. 7. 2008 22:35
Nový
Re: bla bla
celé vlákno
Np, ja nevim, ale Windows pak delaji co? Fragmentuji vse, tedy i volne misto. Na NTFS dokonce defragmentace vytvori spoustu fragmentovaneho mista tam, kde predtim byly fragmentovane soubory. Nemel byste si stezovat v Redmontu? Navic soubory z rc.d jsou typicky tak male, ze je jen tezko lze mit fragmentovane. Jedna se tedy o dost blby priklad.
aura:96
2. 7. 2008 0:24
Nový
Re: bla bla
celé vlákno
Jardo, já vím, že jsi velký odpůrce MS, proto se radši ve svém vlastním zájmu vyhni veškerým komentářům, které se kolem MS točí. Sobě ušetříš nervy a ostatním poznání, že jsi taky pořádný pitomec.
Ale abych nesklouzl jen do reakce ad hominem (které si jsem vědom, ale stejně jsem ji nemohl odpustit), zkusím dodat něco k věci.
Start systému typicky načítá mnoho souborů či jen jejich částí, které nejsou nijak řazeny u sebe. Nejde tedy o fragmentaci jednotlivých souborů, ale o jejich řazení na disku. Tuhle konkrétní věc neřeší žádný filesystem (alespoň nevím o žádném, který by sám přeskupoval soubory), ani NTFS. Může jí řešit jedině daný OS a Windows ji řeší v podobě prefetch a v případě Vist se ještě rozšiřuje v rámci superfetch, který nejen uspořádá vybrané části souborů, ale rovnou je přednačítá do cache (nabízí se otázka, co bude dál - hyperfetch? ultrafetch?). Tohle Linux skutečně zatím nemá (mám pocit, že ale nějaký projekt na tohle téma jsem zahlédl) a faktem je také to, že tahle funkce dokáže start systému i aplikací zrychlit řádově. V případě superfetch se to navíc může týkat i SSD, které zde trefně zmínil Rejpal*.
Další věcí je zmíněná fragmentace. Tvůj argument, že "Na NTFS dokonce defragmentace vytvori spoustu fragmentovaneho mista tam, kde predtim byly fragmentovane soubory" je sice do jisté míry pravdivý, ale nezohledňuje další věci. Vzhledem k tomu, že zmíněný defrag není vlastností filesystemu, ale operačního systému, nelze ani důsledky oddělit od operačního systému.
NTFS má určitý způsob chování. Podobně jako třeba Ext3 řeší to, že většina souborů fragmentována nebude (při vzniku souboru je vytvářena rezerva na další zvětšení souboru, malé soubory vyplňují místo u souborů, které nebyly změněny atd. - více informací lze vyhledat na patřičných zdrojích) a u "typického" využití disku bude fragmentace velmi malá. Jak jsem psal jinde, lze se dohadovat o nastavených limitech oproti Ext3, ale to je tak vše. NTFS má každopádně už od svého počatku celkem rozumné výchozí chování, ne ideální (to ani nejde), ale rozumné. Nicméně OS má navíc k dispozici i defrag, se kterým se od začátku počítalo také (nelze prostě navrhnout filesystem, který bude ideální v KAŽDÉ situaci).
Typické nastavení Windows obsahuje mimo jiné i pravidelný defrag (určitě od dob XP, nevím, jestli i dřív). Tento defrag řeší pouze fragmentaci souborů a neřeší fragmentaci volného místa. Osobně si myslím, že to je naprosto v pořádku. Proč? Defrag tím totiž nijak nenaruší základní koncepci NTFS, tj. dostatek volného místa za soubory, které byly nedávno změněny či založeny.
Dovolím si malou odbočku (když už tak žvaním, tak je to stejně jedno, pochybuju, že to někdo dočte). Sám jsem začínal na PC ještě v prehistorické době DOSu 2.x. Někdy v té době se objevily úžasné Norton Utilities se svým Speed Diskem. Graficky pěkně znázorňoval fragmetaci a bylo úžasné sledovat, jak se přesouvají clustery a vše se pěkně rovná na začátek disku (kolik lidí na to vydrželo fascinovaně zírat dlouhé minuty?). Defragmentovaly se tak nejen všechny soubory, ale také volné místo. Průser však byl, že změna kteréhokoli souboru znamenala velmi často novou fragmentaci. A tak jsme měli SpeedDisk nastaven třeba při každém pátém startu a prostě to žralo čas (i když moc to nevadilo, protože tehdy se úkoly s počítačem dělaly kupodivu rychleji než dnes).
Zpět k současnému defragu - volné místo tedy už z principu nijak neřeší, protože to není žádoucí. Častěji se mění stávající soubory, než že tam přibude nějaký nový extra velký soubor. Takže fragmentace volného místa se bere jako přijatelnější výsledek. A jestli jste to někdo dočetl až sem a přitom víte, co jsem psal na začátku, tak u mne máte jedno pivo. Pochopitelně ho dostane ten, kdo si o něj řekne osobně.
----
* V případě prefetch je ale třeba MS přiznat bod za to, že řeší situaci už nyní, v době HDD, i když už se poměrně dlouho ví, že HDD alespoň pro systém nejsou cestou budoucnosti. Nicméně superfetch je řešením i v době SSD.
Ale abych nesklouzl jen do reakce ad hominem (které si jsem vědom, ale stejně jsem ji nemohl odpustit), zkusím dodat něco k věci.
Start systému typicky načítá mnoho souborů či jen jejich částí, které nejsou nijak řazeny u sebe. Nejde tedy o fragmentaci jednotlivých souborů, ale o jejich řazení na disku. Tuhle konkrétní věc neřeší žádný filesystem (alespoň nevím o žádném, který by sám přeskupoval soubory), ani NTFS. Může jí řešit jedině daný OS a Windows ji řeší v podobě prefetch a v případě Vist se ještě rozšiřuje v rámci superfetch, který nejen uspořádá vybrané části souborů, ale rovnou je přednačítá do cache (nabízí se otázka, co bude dál - hyperfetch? ultrafetch?). Tohle Linux skutečně zatím nemá (mám pocit, že ale nějaký projekt na tohle téma jsem zahlédl) a faktem je také to, že tahle funkce dokáže start systému i aplikací zrychlit řádově. V případě superfetch se to navíc může týkat i SSD, které zde trefně zmínil Rejpal*.
Další věcí je zmíněná fragmentace. Tvůj argument, že "Na NTFS dokonce defragmentace vytvori spoustu fragmentovaneho mista tam, kde predtim byly fragmentovane soubory" je sice do jisté míry pravdivý, ale nezohledňuje další věci. Vzhledem k tomu, že zmíněný defrag není vlastností filesystemu, ale operačního systému, nelze ani důsledky oddělit od operačního systému.
NTFS má určitý způsob chování. Podobně jako třeba Ext3 řeší to, že většina souborů fragmentována nebude (při vzniku souboru je vytvářena rezerva na další zvětšení souboru, malé soubory vyplňují místo u souborů, které nebyly změněny atd. - více informací lze vyhledat na patřičných zdrojích) a u "typického" využití disku bude fragmentace velmi malá. Jak jsem psal jinde, lze se dohadovat o nastavených limitech oproti Ext3, ale to je tak vše. NTFS má každopádně už od svého počatku celkem rozumné výchozí chování, ne ideální (to ani nejde), ale rozumné. Nicméně OS má navíc k dispozici i defrag, se kterým se od začátku počítalo také (nelze prostě navrhnout filesystem, který bude ideální v KAŽDÉ situaci).
Typické nastavení Windows obsahuje mimo jiné i pravidelný defrag (určitě od dob XP, nevím, jestli i dřív). Tento defrag řeší pouze fragmentaci souborů a neřeší fragmentaci volného místa. Osobně si myslím, že to je naprosto v pořádku. Proč? Defrag tím totiž nijak nenaruší základní koncepci NTFS, tj. dostatek volného místa za soubory, které byly nedávno změněny či založeny.
Dovolím si malou odbočku (když už tak žvaním, tak je to stejně jedno, pochybuju, že to někdo dočte). Sám jsem začínal na PC ještě v prehistorické době DOSu 2.x. Někdy v té době se objevily úžasné Norton Utilities se svým Speed Diskem. Graficky pěkně znázorňoval fragmetaci a bylo úžasné sledovat, jak se přesouvají clustery a vše se pěkně rovná na začátek disku (kolik lidí na to vydrželo fascinovaně zírat dlouhé minuty?). Defragmentovaly se tak nejen všechny soubory, ale také volné místo. Průser však byl, že změna kteréhokoli souboru znamenala velmi často novou fragmentaci. A tak jsme měli SpeedDisk nastaven třeba při každém pátém startu a prostě to žralo čas (i když moc to nevadilo, protože tehdy se úkoly s počítačem dělaly kupodivu rychleji než dnes).
Zpět k současnému defragu - volné místo tedy už z principu nijak neřeší, protože to není žádoucí. Častěji se mění stávající soubory, než že tam přibude nějaký nový extra velký soubor. Takže fragmentace volného místa se bere jako přijatelnější výsledek. A jestli jste to někdo dočetl až sem a přitom víte, co jsem psal na začátku, tak u mne máte jedno pivo. Pochopitelně ho dostane ten, kdo si o něj řekne osobně.
----
* V případě prefetch je ale třeba MS přiznat bod za to, že řeší situaci už nyní, v době HDD, i když už se poměrně dlouho ví, že HDD alespoň pro systém nejsou cestou budoucnosti. Nicméně superfetch je řešením i v době SSD.
JardaP (neregistrovaný)
2. 7. 2008 9:31
Nový
Re: bla bla
celé vlákno
Vite, ja jsem nikdy netvrdil, ze fragmentace volneho mista na NTFS je spatne, pouze jsem konstatoval, ze defragmentaci NTFS vznika fragmentovane volne misto (ktere tam, mimochodem bylo pravdepodobne i predtim, pouze mene fragmentovane). Tez jsem netvrdil, ze fragmentace volneho mista je chybnou a spatnou vlastnosti NTFS, pouze jsem konstatoval, ze defragmentaci NTFS vznikne disk s fragmentovanym volnym mistem. Napsal jsem "na NTFS, protoze na FATu k tomu nedochazelo, protoze byl pouzivan jiny defragmentacni program (minimalne we Windows rady 9x/Me - co s FATem nadela novy defrag jsem nikterak nestudoval, NT/XP na FATu jsem nikdy nemel). Win 9x/Me defragmentacni program vypadal, jako vykuchana verze vami zmineneho SpeedDisku.
O defragu se zminujete vy, nikoliv ja. Pokud tedy chcete obhajovat jeho cinnost, neni nutne ho obhajovat prede mnou, ja jeho cinnost nikterak nenapadam. Proc na NTFS a jinych, lepsich nez FAT souborovych systemech jsou diry mezi soubory vim. Nenapadam dokonce ani NTFS, dokonce ho i pouzivam od doby NT 4.0, kdy jste si mohl na Internetu od rady lidi precit leda to, ze je to smejd a FAT je lepsi. Na FATu mam akorat bootdisk, abych mohl snadno editovat boot.ini, kdyby doslo k pruseru.
Opakuji znovu, ze pouze konstatuji, ze defragmentaci vznika deravy, ci jeste deravejsi disk. Cinim tak proto, ze "Windowsak (dokonca Vistak)" vytyka "chybu" fragmentace volneho mista Linuxu, zjevne bez znalosti pricin. Upozornuji tedy na stejny problem ve Windows a odesilam ho, aby si stezoval v Redmontu, protoze jeho nejlepsi system trpi stejne hroznymi problemy, jako ten nemozny Linux. Je to nyni jasne? :-)
P.S.: O me nervy se nebojte, lide, jako "Windowsak (dokonca Vistak)" me nerozciluji, ale rad si rypnu.
BTW, defrag na NTFS obsahuji Windows od verze W2k. Na W2k mel ale mensi problem: umel defragmentovat pouze disky s default allocation unit. Pokud to tedy neopravil nejaky SP, coz je mozne. V XP to snad chodi, ted nevim, jestli jsem to nekdy zkousel.
Na Win NT 4.0 a asi i starsi byl Disk Keeper (nebo jak se to). Novy defrag z Windows se mu podezrele podoba, znovu se ale jedna o vykuchanou verzi. Kdo nemel na opravdovy Disk Keeper, mohl si stahnout Disk Keeper Lite gratos. Jen se nesmelo sahnout na swap file, protoze vytvorenim noweho swapu po defragmentaci clovek skoncil se swap file v nekolika tisicich fragmentu. Coz ale nebyla chyba Disk Keeperu, ale Win NT, ktere si ho tak "inteligentne" zalozily. Dospely Disk Keeper za penize umel tusim defragmentovat i swap file.
O defragu se zminujete vy, nikoliv ja. Pokud tedy chcete obhajovat jeho cinnost, neni nutne ho obhajovat prede mnou, ja jeho cinnost nikterak nenapadam. Proc na NTFS a jinych, lepsich nez FAT souborovych systemech jsou diry mezi soubory vim. Nenapadam dokonce ani NTFS, dokonce ho i pouzivam od doby NT 4.0, kdy jste si mohl na Internetu od rady lidi precit leda to, ze je to smejd a FAT je lepsi. Na FATu mam akorat bootdisk, abych mohl snadno editovat boot.ini, kdyby doslo k pruseru.
Opakuji znovu, ze pouze konstatuji, ze defragmentaci vznika deravy, ci jeste deravejsi disk. Cinim tak proto, ze "Windowsak (dokonca Vistak)" vytyka "chybu" fragmentace volneho mista Linuxu, zjevne bez znalosti pricin. Upozornuji tedy na stejny problem ve Windows a odesilam ho, aby si stezoval v Redmontu, protoze jeho nejlepsi system trpi stejne hroznymi problemy, jako ten nemozny Linux. Je to nyni jasne? :-)
P.S.: O me nervy se nebojte, lide, jako "Windowsak (dokonca Vistak)" me nerozciluji, ale rad si rypnu.
BTW, defrag na NTFS obsahuji Windows od verze W2k. Na W2k mel ale mensi problem: umel defragmentovat pouze disky s default allocation unit. Pokud to tedy neopravil nejaky SP, coz je mozne. V XP to snad chodi, ted nevim, jestli jsem to nekdy zkousel.
Na Win NT 4.0 a asi i starsi byl Disk Keeper (nebo jak se to). Novy defrag z Windows se mu podezrele podoba, znovu se ale jedna o vykuchanou verzi. Kdo nemel na opravdovy Disk Keeper, mohl si stahnout Disk Keeper Lite gratos. Jen se nesmelo sahnout na swap file, protoze vytvorenim noweho swapu po defragmentaci clovek skoncil se swap file v nekolika tisicich fragmentu. Coz ale nebyla chyba Disk Keeperu, ale Win NT, ktere si ho tak "inteligentne" zalozily. Dospely Disk Keeper za penize umel tusim defragmentovat i swap file.
Lael Ophir (neregistrovaný)
2. 7. 2008 18:16
Nový
Re: bla bla
celé vlákno
Defragmentace od Executive Software byla k dispozici už pro NT 3.51. NT 4.0 měly defrag API, ale aplikace v nich nebyla (DiskKeeper Lite byl zdarma). Windows 2000 a vyšší obsahují i front end.
Na swap není důvod sahat. Na začátku se založí souvislý, a od té doby se nejvýše občas zvětší (pokud dojde paměť), a pak zase zmenší na původní velikost, takže případná fragmentace při tomto procesu nehraje roli. Pokud chcete swap zrušit a znovu založit, na malém a plném disku se vyplatí nejprve zrušit swap, poté defragmentovat, a až nakonec založit nový swap.
Editovat boot.ini můžete i z Recovery Console, nepotřebujete na to FAT.
Na swap není důvod sahat. Na začátku se založí souvislý, a od té doby se nejvýše občas zvětší (pokud dojde paměť), a pak zase zmenší na původní velikost, takže případná fragmentace při tomto procesu nehraje roli. Pokud chcete swap zrušit a znovu založit, na malém a plném disku se vyplatí nejprve zrušit swap, poté defragmentovat, a až nakonec založit nový swap.
Editovat boot.ini můžete i z Recovery Console, nepotřebujete na to FAT.
JardaP (neregistrovaný)
3. 7. 2008 2:04
Nový
Re: bla bla
celé vlákno
Nekdy clovek se swapem hybat musi. Kdyz treba vymotuju didk, na kterem byl swap, nekam ho dat musim. Na NT 4.0 defrag pred zalozenim swapu moc nepomohla, protoze Windows si ho pak nacpaly na disk tak, ze byl rozhazeny do nekolika set/tisic fragmentu. Vyplnila se snad kazda sebemensi mezirka od pocatku disku. Zmenilo-li se na tom neco po NT 4.0, nevim.
Dekuji, ale radsi zustanu u maleho boot disky s FATem. Tohle totiz tezko selze, zejmena kdyz se tam skoro nikdy nezapisuje. Staci mi pak DOS disketa s VC. Recovery konzoli jsem jeste ani nevidel. Jednou nesla nainstalovat, protoze se jednalo o CD pred W XP SP 1 a rvalo to, ze nelze nainstalovat, protoze system (s SP2) je novejsi a stand alone instalaci pro SP2 Microsoft nikde neposkytuje. Podruhe to rvalo, ze na disku neni misto. Microsoft totiz defaultne predpoklada, ze kazdy ma na disku jeden oddil a tak se ani nenamaha v knizecce, co je u CD, specifikovat nejaka doporuceni o velikosti boot oddilu.
BTW, recovery console na NT 4.0 nebyla a zalozenim boot partition jako NTFS si clovek tak akorat zadelal na problemy. Vymontovavat disk a cpat ho do jineho stroje jen proto, abych zeditoval boot.ini me opravdu nebavi. A na co jsem si zvykl, to pouzivam i na pozdejsich Windows. Ma to sve vyhody.
Dekuji, ale radsi zustanu u maleho boot disky s FATem. Tohle totiz tezko selze, zejmena kdyz se tam skoro nikdy nezapisuje. Staci mi pak DOS disketa s VC. Recovery konzoli jsem jeste ani nevidel. Jednou nesla nainstalovat, protoze se jednalo o CD pred W XP SP 1 a rvalo to, ze nelze nainstalovat, protoze system (s SP2) je novejsi a stand alone instalaci pro SP2 Microsoft nikde neposkytuje. Podruhe to rvalo, ze na disku neni misto. Microsoft totiz defaultne predpoklada, ze kazdy ma na disku jeden oddil a tak se ani nenamaha v knizecce, co je u CD, specifikovat nejaka doporuceni o velikosti boot oddilu.
BTW, recovery console na NT 4.0 nebyla a zalozenim boot partition jako NTFS si clovek tak akorat zadelal na problemy. Vymontovavat disk a cpat ho do jineho stroje jen proto, abych zeditoval boot.ini me opravdu nebavi. A na co jsem si zvykl, to pouzivam i na pozdejsich Windows. Ma to sve vyhody.
Lael Ophir (neregistrovaný)
4. 7. 2008 15:19
Nový
Re: bla bla
celé vlákno
Samozřejmě někdy se swapem musíte hýbat. Pak je nejlepší defragmentovat, a potom swap založit. Jak NT 4 zakládaly swap, to opravdu nevím. Berte ale v úvahu, že fragmenty větší než 64MB podle testů prakticky nemají vliv na výkon. Navíc můžete použít pagedefrag, který je k downloadu na stránkách MS (dříve na stránkách sysinternals.com).
Recovery konzoli není třeba instalovat. Stačí zabootovat z instalačního média Windows 2000 či vyšších, a říci, že chcete recovery konzoli. V NT4 jste zase měl možnost dát na disketu zavaděč a boot.ini (to jde asi i v pozdějších verzích). Minimální velikost disku (a tedy i partition) je psaná v System Requirements, ovšem s Recovery konzolí nemá nic společného.
FAT je oproti NTFS pomalejší, nemá žurnál, je náchylný na ztráty dat při poškození jediného sektoru, a nepodporuje ACL na souborech. Mít Windows na FAT bylo v době NT 4 nesmyslné, a dnes je to o to více mimo. Dovedu ale pochopit, že zvyk je železná košile. To je treba duvod, proc sem pisete bez diakritiky, i kdyz se hacky a carky naucily davno uz i unixy.
Recovery konzoli není třeba instalovat. Stačí zabootovat z instalačního média Windows 2000 či vyšších, a říci, že chcete recovery konzoli. V NT4 jste zase měl možnost dát na disketu zavaděč a boot.ini (to jde asi i v pozdějších verzích). Minimální velikost disku (a tedy i partition) je psaná v System Requirements, ovšem s Recovery konzolí nemá nic společného.
FAT je oproti NTFS pomalejší, nemá žurnál, je náchylný na ztráty dat při poškození jediného sektoru, a nepodporuje ACL na souborech. Mít Windows na FAT bylo v době NT 4 nesmyslné, a dnes je to o to více mimo. Dovedu ale pochopit, že zvyk je železná košile. To je treba duvod, proc sem pisete bez diakritiky, i kdyz se hacky a carky naucily davno uz i unixy.
shadowmaster (neregistrovaný)
2. 7. 2008 16:52
Nový
RE: Jeden z vývojářů ext4 začal používat vlastní souborový systém
celé vlákno
zase jeden zavadejici nadpis.... (jak kdyby vymyslel jiny FS nez ext4) :D
