Velikost volného místa v závislosti na nastavení mkfs.ext3

24.7.2008 11:32 | Přečteno: 2158× | | poslední úprava: 24.7.2008 11:35

Mnoho lidí žehrá na statické alokování inodů v systému souborů ext3. Tvrdí, že inodů je buď málo a dojdou, nebo mnoho a zabírají místo. Pojďme to změřit.

Pro toto měření jsem vyhradil 40GB (LV) oddíl na disku. V dalším textu budu používat předpony jednotek: k=1024B, M=1048576B, G=1073741824B, nechce se mi psat MiB apod.

Default (8kB/inode; 4kB/block)

Standardní nastavení e2fsprogs v CentOS 5.2. Dle wiki je maximální velikost souboru 2TB a FS 8TB.

mkfs.ext3 -m 0 ... 

1k blocks	used	available
41284928	180240	41104688
Inodes	Iused	Ifree
5242880	11	5242869

Mnoho souborů (1k/1k)

Nastavení poskytující nejvíce volných inod (=souborů). Trochu déle se vytváří a kontroluje, což může být někdy nevýhoda. Podle vývojářů však vysoký počet bloků FS nevadí a nesnižuje jeho výkon. Podle wikipedie má takové nastavení limit 16GB/soubor 2TB/FS.

mkfs.ext3 -m 0 -i 1024 -b 1024 ... 

1k blocks	used	available
36687021	37520	36649501
Inodes	Iused	Ifree
41943040	11	41943029

Velké soubory (-T largefile 1MB/inode; 4kB/block)

Nastavení pro velké soubory (>1MB), vytváří se rychle.

mkfs.ext3 -m 0 -T largefile ...

1k blocks	used	available
41935168	180240	41754928
Inodes	Iused	Ifree
40960	11	40949

Ještě větší soubory (-T largefile4 4MB/inode; 4kB/block)

Nastavení pro obrovské soubory (>4MB), vytváří se bleskurychle.

mkfs.ext3 -m 0 -T largefile4 ...

1k blocks	used	available
41939008	180240	41758768
Inodes	Iused	Ifree
10240	11	10229

Závěr

Procento volného místa v následující tabulce jsem vztahoval k defaultnímu nastavení mkfs.ext3. Je patrné, že snížením počtu inodů mnoho místa nezískáme, naopak přijdeme o možnost zápisu dalších souborů (místo ztracené neúplnými bloky je stejné jako u defaultu). Naopak v případě extrémního počtu inodů přijdeme o přibližně 10% místa, slack-space se naopak sníží na minimum (toto měření není součástí tohoto testu).

kB/nodes	Volné místo kB (GB)	%
4	41104688 (39.20)	100.0
1	36649501 (34.95)	89.2
1024	41754928 (39.82)	101.6
4096	41758768 (39.82)	101.6

       

Komentáře

[gnome-hater]

Hmm, zajímavé. Díky za test. Ještě by to chtělo změřit na ext4 s těma extentama či jak se tomu říká :)

[Heron]

Ok, nahodím VMWARE a jestli se mi podaří do CentOSu dostat ext4, tak to sem pastnu.

[gnome-hater]

Díky, klidně bych se do toho pustil sám, ale mé disky praskají ve švech :)

[Heron]

Také toho místa nemám nejvíce

Než se pustím do kompilace kernelu, neznáš nějaké distro (easy to install), které ext4 už umí?

[gnome-hater]

Tak to budeš muset jít za někým jiným, jádro vždycky kompiluju sám. Asi to nikde moc nebude, ještě to není moc vychytaný, stabilizovaný a tak. Ale tipuju fedoru, ta je docela bleeding-edge, určitě ti bude šmakovat:)

[Heron]

Hmm, ve system rescue (posledni beta) mela byt podpora, ale mkfs.ext4 neni. Takze tuto snahu prozatim odkladam.

[Heron]

Aha, tak to není mkfs.ext4, ale mkfs.ext3 -E test_fs

[progdan]

AFAIK Sabayon Linux ma podporu EXT4

[michich]

Fedora by to měla umět. Anacondě musíš dát myslím parametr "ext4", aby ti možnost instalace na ext4 nabízela.

[Heron]

Ok, takže ji nechám stáhnout a někdy (== neurčito ) se na to vrhnu, dík.

[myself]

Nechcem rypat, ale je naozaj potrebne to testovat? Neda sa to vypocitat?

[Käyttäjä 11133]

Heron je fyzik, on nevěří teoriím pokud si je neověří experimentem

[Petr]

Pokud je to tak mohl by mu někdo vysvětlit že jaderný výbuch je vlastně naprosto nezajímavý a jakýkoliv zájem o něj je nežádoucí?

[Heron]

LOL

No především si myslím, že tento experiment je méně náročnější na čas než studovat on disk format u ext3

[myself]

To uznavam. V mojej situacii (plny disk) by som vsak takyto experiment asi neuskutocnil :)

[alblaho]

Já bývám největší řvoun, když přijde na tu alokaci inodů. Dokonce s oblibou používám přívlastek feudální, protože design extX mi feudalismus asociuje (FAT je asi doba kamenná).

Nicméně díky za testy a musím uznat, že výchozí nastavení je asi hodně rozumné. Hele, nemohl bys ten disk zformátovat na ReiserFS a ukázat volné místo? Tvůj výchozí formát ext3 zabírá 800 MiB.

[Heron]

Restartoval jsem k vůli tobě server, tak si toho važ

Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/mapper/VGraid-test
          reiserfs    41941756     32840  41908916   1% /mnt/t

reiser: 41908916
ext3:   41104688

101.956% Takže trochu lepší než largefile4, pochopitelně s možností umístění více souborů.

[alblaho]

Jí si toho vážím, fakt díky.

Závěr je ten, že ext4 nebude taková mrdka, jak jsem si myslel.

Já jsem na reiserFS přešel z Ext3 kvůli rychlosti. Ale jsem si vědom, že ext3 jde zrychlit zapnutím nějakých těch dir_index. ReiserFS je ale rychlý už ve výchozím nastavení, není třeba s ničím laborovat. Myslím, že u ext4 budou ty indexy adresářů zaplé rovnou.

[Heron]

To spíše změnou žurnálovacího modu na writeback (to používá i reiser), ext3 má standardně ordered.

[michich]

Od nějaké verze e2fsprogs je dir_index defaultně pro ext3 zapnutý.

[Heron]

Takže ext4

default

Ve Fedoře9 je std 4k bloky a 16k/inodu. Což dává na 40GiBi disku 2621440 souborů (nic moc).

Místo je 41104688kiBi

1k/1k

mkfs.ext3 -m 0 -L test -i 1024 -b 1024 -E test_fs /dev/VGtest/test

Teď pozor:

Available=31406621 1k blocks

Tj o 10GB (25%) méně !!!

Tak jsem snížil počet inod a zkusil, zda náhodou nevytváří inody dynamicky:

for i in $(seq -w 1 10240); do echo "ahoj" > $i.txt; done
-bash: 10229.txt: No space left on device 

Takže nikoliv

Pokud ale použijeme 4k/4k (nebo -T news), místa je dost a 10mil souborů by mohlo postačovat.

[alblaho]

Dělat bloky jen 1k mi přijde v dnešní době docela psycho - to by si žádná fatka nelajzla. 4k mi přijdou filozofický správné, protože tak velké bývají i stránky paměti.

Jedna inoda na dva bloky mi přijde taky OK, pokud se tedy nejedná o nějakou specialitu (mail server?).

[Heron]

FATka na disketách měla 512B/block (tam tomu říkali cluster). Umí to i NTFS. Ale ano, po jednom zážitku s 15mil soubory také dávám přednost DB, kde to jen jde. Někdo tu psal, že udělal MySQLFS přes Fuse. To by mohlo být zajímavé pro Maildiry a podobná zvěrstva.

[alblaho]

MySQL FS přes Fuse se mi zdá už trochu přes ruku. Kvůli databázi přímo na FS si Hans Reiser udělal RaiserFS - vždyť ten stromovitý layout je opsaný z databází.