MC: pořadí kopírování souborů

[j]

Vážně kopírování více souborů probíhá asynchronně popř. ve více threadech se všemi současně, aby si to OS zoptimalizoval? Protože jinak se uvedeného efektu optimalizace seekování dosáhnout nedá. Ono je nějakému userspace programu houby do toho, kde je co alokované.

Sak zdrojaky mas, tak se podivej ... a jirsaka neber vazne, ten se bez manualu nezvladne vysrat. Kdyz si od kernelu vyzadas seznam souboru, tak ti ho preda v jakym ze poradi? No presne v tom, jak sou na disku zapsany zasebou. A presne v tomhle poradi je mc kopiruje. (samo, na nekterych FS - specielne tech co umi snapy -  tohle nemusi az tak odpovidat fyzickymu rozlozeni na disku, ale prevazne to sedi dobre)

Samo, dalsi layer je disk samotnej, ten si muze req poprehazovat jeste ve vlastni rezii => pokud mu kernel nahrne seznam sektoru ktery chce cist, tak si to disk jeste interne muze prehazet tak, aby to vyhovelo jemu (predevsim pak proto, ze ani kernel musi vubec tusit, jaky je fyzicky usporadani disku).

[Reklama]

[ByCzech]

Sak zdrojaky mas, tak se podivej ... a jirsaka neber vazne, ten se bez manualu nezvladne vysrat. Kdyz si od kernelu vyzadas seznam souboru, tak ti ho preda v jakym ze poradi? No presne v tom, jak sou na disku zapsany zasebou. A presne v tomhle poradi je mc kopiruje. (samo, na nekterych FS - specielne tech co umi snapy -  tohle nemusi az tak odpovidat fyzickymu rozlozeni na disku, ale prevazne to sedi dobre)

Samo, dalsi layer je disk samotnej, ten si muze req poprehazovat jeste ve vlastni rezii => pokud mu kernel nahrne seznam sektoru ktery chce cist, tak si to disk jeste interne muze prehazet tak, aby to vyhovelo jemu (predevsim pak proto, ze ani kernel musi vubec tusit, jaky je fyzicky usporadani disku).

Samozřejmě do hry vstupují optimalizační technologie FW disku, či NCQ (TCQ) ap., ale program dostane data v tom pořadí v jakém si je objednal. To že třeba jiný proces dostal data dříve díky, přestože si je objednal později na věci nic nemění. MC není multithreadový, aby mohlo k takovým věcem docházet.

[Lael.Ophir]

a jirsaka neber vazne, ten se bez manualu nezvladne vysrat. Kdyz si od kernelu vyzadas seznam souboru, tak ti ho preda v jakym ze poradi? No presne v tom, jak sou na disku zapsany zasebou.

No to jsou zase moudra, a nemůže chybět jazyk dítěte z ghetta. Pořadí souborů v adresáři nekoresponduje s layoutem souborů na disku. Řada FS (NTFS, ReiserFS) implementuje adresář jako B-tree, red-black tree nebo jiný strom, takže seznam souborů vrací vždy v abecedním pořadí.

U jiných FS (například FAT a tuším ext2) záleží na pořadí vytvoření názvů v adresáři, s tím že se znovu-používají místa v adresáři po zrušených souborech. Fyzické umístění souboru na disku určuje alokátor, a s pořadím souborů v adresáři má v nejlepším případě velmi volný vztah. Pokud na FS naroste fragmentace, tak se ten vztah vytrácí úplně. Soubory (na běžných FS) právě díky fragmentaci (souborů i volného místa) nebývají uložené ani souvisle, ani jeden za druhým. To všechno by profesionál v oblasti IT měl vědět, a navíc by to měl vědět i každý absolvent informatiky.

[j]

Hele luliku, to tu nemusis vypislovat ze fs z dilny M$ stojej zahovno, to vsichni vime. Problemy s fragmentaci sem jinde nez na widlich nikdy neresil.

[Lael.Ophir]

Hele luliku, to tu nemusis vypislovat ze fs z dilny M$ stojej zahovno, to vsichni vime. Problemy s fragmentaci sem jinde nez na widlich nikdy neresil.

Všechny běžné FS trpí fragmentací. Jedním ze scénářů je paralelní zápis více souborů. FS samozřejmě neví jak budou velké. V takovém případě můžete naivně zapisovat obsah do prvního volného bloku, takže ze souborů vznikne fragmentovaná "ideální řezanka" už při zápisu. Tak primitivní alokátor samozřejmě žádný pokročilejší FS nemá. Jiná cesta je ukládat každý soubor tak aby se mu předem rezervovalo řekněme 50MB místa. Tím vznikne menší řezanka, soubory dokonce nebudou fragmentované pokud jsou menší než 50MB. Ale zase víc fragmentujete volné místo, a to se vám vymstí až se FS dostatečně zaplní, protože nenajdete dostatečně velké souvislé kusy místa. Obecně čím víc se zaplnění FS blíží ke 100%, tím vyšší bude fragmentace. A čím agresivněji jste nechával okolo souborů volné místo, abyste zabránil jejich fragmentaci, tím dřív ta fragmentace FS bude růst. Napsat dobrý alokátor holt není jednoduché.

Na klasických Unixech se defragmentovalo tak že jste provedl zálohu na pásku, smáznul FS, pak FS znovu vytvořil a provedl restore (pokud jste pásku přečetl). Dneska je to naštěstí lepší. Windows mají API pro online defrag od roku 1996, na Linuxu se online defrag postupně také začíná objevovat.

Mimochodem když píšete takové nesmysly, nemyslíte že byste se měl dovzdělat? Na první místě by to chtělo naučit se česky, ať nepůsobíte jako primitiv. To totiž nic žádná věc nezakryje. I kdybyste byl veleúspěšný v businessu, ale vyjadřoval se u toho jako dítě ghetta, tak si o vás lidé budou myslet že jste špína.
Druhá věc jsou pak znalosti IT. Nechcete si dát studium informatiky, nebo alespoň po večerech provádět samostudium? Univerzity mají dnes většinu materiálů online. Soudě podle vašich zdejších příspěvků by vám studium zatraceně hodně pomohlo.
Na dalším místě asi bude všeobecný rozhled. Jenže ten se získává dost těžko, takže tam vám moc neporadím.

[Reklama]

[ByCzech]

Hele luliku, to tu nemusis vypislovat ze fs z dilny M$ stojej zahovno, to vsichni vime. Problemy s fragmentaci sem jinde nez na widlich nikdy neresil.

Všechny běžné FS trpí fragmentací. Jedním ze scénářů je paralelní zápis více souborů. FS samozřejmě neví jak budou velké. V takovém případě můžete naivně zapisovat obsah do prvního volného bloku, takže ze souborů vznikne fragmentovaná "ideální řezanka" už při zápisu.

Vážně by bylo fajn, kdyby jste chování FS z díly Microsoftu nenavlékal na chování jiných FS, které jsou běžné v Linuxu.

Mé disky (/ a /home) po hodně dlouhém používání, paralelních zápisech, aktualizacích, mazání a novému nahrávání spousty dat, bez defragmentování (ext4):

Kód: [Vybrat]

<Fragmented files>                             now/best       size/ext
1. /var/log/wtmp.1                              26/1              4 KB
2. /var/log/wtmp                                15/1              4 KB
3. /var/log/clamav-unofficial-sigs.log          41/1              4 KB
4. /var/log/ConsoleKit/history.1                10/1              4 KB
5. /var/log/debug.1                              7/1              4 KB

 Total/best extents                             740057/738878
 Average size per extent                        75 KB
 Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/sda2) does not need defragmentation.
 Done.

a

Kód: [Vybrat]

<Fragmented files>                             now/best       size/ext
1. /home/jarda/.Skype/DataRv/offline-storage.data
                                                96/1              4 KB
2. /home/*censored*/.Skype/*censored*/chatsync/a3/a3753d88fe62e873.dat
                                                16/1              4 KB
3. /home/*censored*/.Skype/*censored*/chatsync/ff/ffc4dbedaa6ee36c.dat
                                                11/1              4 KB
4. /home/*censored*/.Skype/*censored*/chatsync/e0/e04921a91279e418.dat
                                                10/1              4 KB
5. /home/*censored*/.Skype/*censored*/chatsync/ea/ea920899646cf6c8.dat
                                                10/1              4 KB

 Total/best extents                             1128887/1108381
 Average size per extent                        1208 KB
 Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/sdb1) does not need defragmentation.
 Done.

Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.

[lojza]

neslo by to obejit treba nejak takhle:

Kód: [Vybrat]

tar cf - * | ( cd /target; tar xfp -)

[Lael.Ophir]

Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.

To záleží na tom jak s FS pracujete. Když tam budete mít MySQL databázi (dá-li se tomu říkat databáze) s modelem soubor per tabulka, a budete do těch tabulek cpát spoustu dat, tak se to samozřejmě fragmentovat bude. Podobně pokud budete mít denně 1GB logů a budou se rolovat, tak se budou fragmentovat. Nebo pokud bude stroj použitý jako file server kde klienti vytvářejí a mění soubory v mnoha sessions. Nebo když si na úrovni FS transparentně zkomprimujete větší množství souborů. Nebo když budete často synchronizovat nějaký větší projekt se source control systémem a budete ho buildovat, a zároveň na FS zapisovat něco jiného. Plus se fragmentace bude zhoršovat jak se zaplnění disku bude blížit 100%, a to tím hůř, čím vyšší fragmentaci volného místa způsobil alokátor tím že se snažil zabránit fragmentaci souborů. Dalším problémem může být delayed allocator, který sice dokáže do jisté míry snížit fragmentaci, ale za cenu ztráty dat při odpojení FS natvrdo (výpadek proudu, kernel panic apod.)

Pokud máte systém na kterém se data minimálně "hýbají", tak vás fragmentace fakt nemusí trápit. Jenže ne každý při práci (resp. "práci") vystačí s xtermem, browserem a mp3 playerem

[JardaA]

Na klasických Unixech se defragmentovalo tak že jste provedl zálohu na pásku, smáznul FS, pak FS znovu vytvořil a provedl restore (pokud jste pásku přečetl). Dneska je to naštěstí lepší. Windows mají API pro online defrag od roku 1996, na Linuxu se online defrag postupně také začíná objevovat.

Takhle se dělalo odjakživa, vzpomínám si třeba na EC1030 :-). 

[j]

Všechny běžné FS trpí fragmentací. Jedním ze scénářů je paralelní zápis více souborů. FS samozřejmě neví jak budou velké. ....

Mno vidis luliku, treba se widle i nekdy v daleky budoucnosti naucej pro soubor alokovat prostor predem ... kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou, to jen na widlich se to naprosto pravidelne dostava do stadia, kdy je nejlepsi vsechno presunout, partysnu preformatovat a presunou zpet, protoze defragmentace by trvala par dnu a pouzivat se to neda.

Mam tady vedle sebe notes ... zajimavy cece, sou na nem widle ... bootovalo to asi 10 minut ... a po defragmentaci,  ktera bezela celej den (a tudiz to dotycnej celej den nemoh pouzivat), to zvladne teda asi za 5 ...

Pak tu mam par tuxu, nejak vlastne ani nevim, jak to defragmentovat, nikdy sem to nemel potrebu resit. Ale viz vejs, fragmentace je naprosto smesna, takze i kdybych to resil, na vykon to bude mit vliv presne 0. A to ty systemy bezej nasobne dyl nez ten notes vubec existuje.

Apropos, kdy ze M$ doda ten uzasny uber databazovy filesystem? A to samo nemuzes tusit, ze databaze si vyrobi soubor klidne nasobne vetsi, nez kolik dat aktualne ma, ze ... a ze dokonce existujou databaze, ktery si resej zcela vlastni FS (respektive FS vubec neresi).

[Lael.Ophir]

No jo, Jeronýmku. Vy to víte vždycky nejlépe... nebo si to alespoň myslíte

Mno vidis luliku, treba se widle i nekdy v daleky budoucnosti naucej pro soubor alokovat prostor predem ... kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou, to jen na widlich se to naprosto pravidelne dostava do stadia, kdy je nejlepsi vsechno presunout, partysnu preformatovat a presunou zpet, protoze defragmentace by trvala par dnu a pouzivat se to neda.

Už jsem psal, že delayed alocation vede ke ztrátě dat v případě že FS není čistě unmountován (nebo syncnut). Ale co že vaši uživatelé přijdou o data - ať si zvykají na Linux

Ad kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou - kupodivu na většina tuxích FS se data prakticky nehýbou, případně nebyly zaplněny ke 100%. Pokud používáte xterm, browser a mp3 player, protože pro tuxe prakticky nic jiného není, tak ten FS možná opravdu moc nezfragmentujete

Mam tady vedle sebe notes ... zajimavy cece, sou na nem widle ... bootovalo to asi 10 minut ... a po defragmentaci,  ktera bezela celej den (a tudiz to dotycnej celej den nemoh pouzivat), to zvladne teda asi za 5 ...

To jsou super pohádky. Moje Windows bootují dost pod půl minuty (obyčejně nevypínám desktop ani notebooky, protože ty notebooky neběží na Linuxu, takže umí usnout i se pak probudit), a když jsem kdysi naposledy spustil defragmentaci, jela bez problému na pozadí. Možná byste měl přemýšlet, co děláte špatně, když vám Windows bootují 10 minut. Ale vzhledem k perlám které z vás padají ve věcech správy systému se nedivím vůbec ničemu

Apropos, kdy ze M$ doda ten uzasny uber databazovy filesystem? A to samo nemuzes tusit, ze databaze si vyrobi soubor klidne nasobne vetsi, nez kolik dat aktualne ma, ze ... a ze dokonce existujou databaze, ktery si resej zcela vlastni FS (respektive FS vubec neresi).

Netuším kdy MS dodá SQL Server pro Linux, a je mi to celkem jedno, protože ho na Linuxu nebudu používat.
DB soubory samozřejmě mohou být větší než kolik je v nich dat. A samozřejmě MS SQL i Oracle umí používat RAW disky, což ale nemá moc vliv na výkon, pokud nepoužíváte nějaký úplně doprasený FS. Jako ukázku fragmentace FS jsem popisoval InnoDB v režimu File-Per-Table, a není mi úplně jasné, proč v téhle souvislosti píšete o DB souborech a RAW discích. Pozitivně hodnotím že jste ty termíny nejspíš alespoň někde slyšel, když o nich píšete.

[Lol Phirae]

Moje Windows bootují dost pod půl minuty

Měl by sis to konečně ujasnit. Posledně to bylo několik sekund včetně instalace aktualizací.

a když jsem kdysi naposledy spustil defragmentaci, jela bez problému na pozadí.

A hovno zdefragmentovala, protože aby to neběželo bezvýsledně několik dní, tak to umělci z Redmondu "optimalizovali" tak, že velké soubory (kde "velký" znamená >=64MiB) se vůbec nedefragmentují.

[ByCzech]

Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.

To záleží na tom jak s FS pracujete. Když tam budete mít MySQL databázi (dá-li se tomu říkat databáze) s modelem soubor per tabulka, a budete do těch tabulek cpát spoustu dat, tak se to samozřejmě fragmentovat bude.

Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.

[Lael.Ophir]

Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.

Fragmentace je funkční vlastností všech běžných FS. Mohlo by vám to dojít i z toho že jste sám postnul výstup z e4defrag, kde máte na jednom FS Total/best extents 740057/738878, tj. 1179 zbytečných fragmentů, a na druhém Total/best extents 1128887/1108381, tj. 20506 zbytečných fragmentů. Ale hlavně že vám to magicky nefragmentuje, protože Tux. Mimochodem tohle vám měli vysvětlit ve škole v modulu Operating System Concepts, případně jste si to měl nastudovat sám, pokud chcete dělat v IT a vědět co vlastně děláte.

[Lael.Ophir]

Měl by sis to konečně ujasnit. Posledně to bylo několik sekund včetně instalace aktualizací.

To jste si vymyslel, nebo máte zdroj?

A hovno zdefragmentovala, protože aby to neběželo bezvýsledně několik dní, tak to umělci z Redmondu "optimalizovali" tak, že velké soubory (kde "velký" znamená >=64MiB) se vůbec nedefragmentují.

Ale vždyť zase kecáte. Vestavěný defragmenter ignoruje fragmenty větší než 64MB, protože ty už se skládají z 16384+ souvislých clusterů (po 4kB), a jejich dopad na výkon je minimální. Zato jejich konsolidace vyžaduje spoustu (efektivně zbytečných) I/O operací. To že je soubor větší než 64MB neznamená že se nedefragmentuje. Běžte si to vyzkoušet, než budete zase psát takové nesmysly.