| Autor | Zpráva | ||
|---|---|---|---|
| Nox Profil |
#1 · Zasláno: 28. 7. 2008, 18:55:45
Zdravím,
velký bratr Google mlčí, takže.... Windows (alespoň XP) udává u parametrů souboru(ů)/složky(ek) dva parametry - jeden je "Velikost" a druhý je "Velikost na disku", přičemž někdy je větší jeden, někdy druhý. Když jsem teď zjišťoval velikost php souborů, tak "Velikost na disku" byla dokonce víc jak 3x větší než "Velikost" Nevěděl by někdo odkaz nebo neosvětlil stručně rozdíl? Díky moc! |
||
| blackjoker Profil |
#2 · Zasláno: 28. 7. 2008, 19:39:13 · Upravil/a: blackjoker
velikost na disku nějak souvisí s rozložením zátěže, redundancí dat atd.
Teda myslim článek jsem nenašel tak to radči neber moc vážně |
||
| Joker Profil |
#3 · Zasláno: 28. 7. 2008, 19:39:40
Nox
Je to prosté: Každý souborový systém má takzvané alokační jednotky (bloky, clustery). Cluster je základní jednotka, která se nedá dál dělit- na jeden cluster se nedá uložit více než jeden soubor a souboru je přidělen celý cluster i v případě, že tolik místa nepotřebuje (data souboru pokrývají méně). Tzn. pokud máte na disku velikost clusteru třeba 32kB, i soubor obsahující jediný bajt bude zabírat na disku 32kB místa. Soubor o velikosti 1kB bude na disku taky zabírat 32kB, soubor o velikosti 30kB taky, soubor o velikosti 33kB bude na disku zabírat 64kB, a tak dále. |
||
| Nox Profil |
#4 · Zasláno: 28. 7. 2008, 19:45:05
Joker
Díky moc! Už je to jasné ... a tím asi taky proč může defragmentace zvýšit volný prostor na disku |
||
| sicario Profil |
#5 · Zasláno: 28. 7. 2008, 19:49:42
Rekl bych ze to jednak souvisi s velikosti clusteru v danem souborovem systemu a pak s automatickou kompresi "starych" souboru.
Cluster ma pevnou delku X bajtu. Pokud ma soubor velikost napr. 0.5X, na disku stejne zabere X bajtu. A k te automaticke kompresi - tady je to i s obrazky. |
||
| Tomasds Profil |
#6 · Zasláno: 28. 7. 2008, 19:50:40
Nox
S tím souvisí mj. i to, že kopírování deseti tisíc 1kB souborů trvá podstatně déle, než kopírování jednoho 10MB souboru. Ohledně volného prostoru bych tak optimistický nebyl. Jestli mám soubor rozhozený v 5000 clusterech na disku nebo ve štrůdlu za sebou, velikost zabraného prostoru nijak neovlivní. |
||
| Nox Profil |
#7 · Zasláno: 28. 7. 2008, 19:53:43
Tomasds
Pravda... co se dá dělat... |
||
| Joker Profil |
#8 · Zasláno: 28. 7. 2008, 21:10:28
Tomasds
S tím souvisí mj. i to, že kopírování deseti tisíc 1kB souborů trvá podstatně déle, než kopírování jednoho 10MB souboru. To není jen tou velikostí, ale i tím, že kopírování souboru není jen zkopírování jeho dat, ale ten soubor se na cílovém disku musí taky vytvořit, zkopírovat informace o souboru (atributy, oprávnění,...) a podobně. A to je taky rozdíl, jestli se to dělá desettisíckrát, nebo jednou. Ohledně volného prostoru bych tak optimistický nebyl. Jestli mám soubor rozhozený v 5000 clusterech na disku nebo ve štrůdlu za sebou, velikost zabraného prostoru nijak neovlivní. Taky bych řekl, že defragmentace jako taková asi místo neuvolní. Ale samozřejmě ovlivní rychlost práce s diskem. |
||
| Nox Profil |
#9 · Zasláno: 28. 7. 2008, 21:21:15
Jasné....nevim, jak mě to napadlo
Díky všem |
||
| bukaj Profil |
#10 · Zasláno: 28. 7. 2008, 21:31:57
Joker
na jeden cluster se nedá uložit více než jeden soubor a souboru je přidělen celý cluster i v případě, že tolik místa nepotřebuje Některé souborové systémy (jmenovitě např. ReiserFS) dokáží používat tzv. „tail-packing“. Neboli pokud jeden blok není využit celý, dokáží do jeho zbytku ještě přibalit část, či myslím, že i dokokonce celý soubor, a právě toto řeší problémy malých souborů jako jsou např. zdrojové kódy. Bohužel Windows, pokud vím, podporuje jen pár souborových systémů (NTFS, FAT, jestli něco víc, nevím), které tail-packing nepodporují. Na některé věci by se to opravdu hodilo. |
||
|
Časová prodleva: 17 let
|
|||
0