Dotaz: 702GB se nevešlo na 1TB disk

[Jirka]

Zdravím všechny,
přetahuju data z ntfs partition na jednom disku na ext2 na druhém a výsledek byl dost nepříjemné překvapení.
Parametry ext2 oddílu:
velikost bloku 4096, 4 inody na blok, inodů obsazeno asi 1%.
Soubory jsou směs od filmů až po hromady malinkých souborů v adresářích. Netuší někdo, jak je tohle možný, jak se tomuhle příště vyhnout, případně jaký (léty prověřený) souborový systém použít, aby byl minimálně stejně efektivní, jako to slavný ntfs?
díky.

---

---

Odpovědi

[Kit]

Zkus ReiserFS a případně si zapni tail packing.

[kyytaM]

Vypni si rezervaciu kapacity pre roota. http://www.microhowto.info/howto/reduce_the_space_reserved_for_root_on_an_ext2_ext3_or_ext4_filesystem.html

[Jirka]

tím to není, kopíroval jsem to pod rootem. Zmenšit velikost bloku? pokud bych dal velikost 1024, je pak nějaká šance tam nacpat soubor větší než 16GB, pokud by to jednou bylo potřeba?

[Jirka]

Ty 4 inody na blok byla asi blbost. Udělal jsem několik benchmarků různých souborových systémů v 1GB loopback partišně, celkem zajímavý výsledky:

                        |  prázdný  |nahrán 100M soubor+src jádra|nahrán 900MB soubor|     
                        |volné místo| volné místo |obsazené inode|    volné místo    |
                        |           |             |              |                   |
EXT2 1k bloky, 4k/inode |   960M    |    370M     |     16%      |        2.2M       |
EXT2 4k bloky, 4k/inode |   960M    |    303M     |     16%      |        6.6M       |
EXT2 4k bloky, 16k/inode|   1008M   |    351M     |     61%      |       54.6M       |
EXT2 2k bloky, 16k/inode|   1008M   |    391M     |     61%      |       46.9M       |
Reiser3 default         |   1024M   |    438M     |     ---      |       91.0M       |
JFS                     |   1020M   |    400M     |      5%      |      120.0M       |

Takže to vyhrává JFS, který se mi kdysi osvědčil kvůli neskutečný blbuvzdornosti

[nyan]

4 inody na blok, nebo 4 inody na block group ? protoze 4 inody na block nemaji smysl. Kazdy soubor zabere minimalne 1 blok a 1 inode, tudiz nema smysl mit vetsi pocet inode nez pocet bloku (neboli >1 inode per block).

Navic kazdej inode zabere 128 (nebo vic) bytu, ktere jsou alokovany trvale.

Jinak, proc ne ext4 ? ext2 neumi extenty tudiz velke soubory (filmy apod) budou ukladany velmi neefektivne.

[Tomáš Bžatek]

Nebyly nektere casti komprimovane nebo hardlinkovane? (NTFS by to melo umet)

[Jirka]

Nejspíš to bylo příliš velkým množstvím inodů, velkými bloky a množstvím malých souborů.
Teď už je to pasé, přetahoval jsem data na druhej disk, abych v tom prvním mohl změnit oddíly a přeformátovat. Tak jsem potřeboval vědět, jaký filesystém použít, aby tam bylo co nejvíc místa se soubory různých velikostí a množství. Už je tam JFS. Udělal jsem ještě pár pokusů, na celý čáře by to vyhrál FAT32

[jadd]

tím to není, kopíroval jsem to pod rootem. Zmenšit velikost bloku? pokud bych dal velikost 1024, je pak nějaká šance tam nacpat soubor větší než 16GB, pokud by to jednou bylo potřeba?

16GB, ..FAT? asi jiná priorita..

[Šangala]

Týjo, FAT na 1TB to je fičák, navíc když na M$ dovolí vytvořit jen max 32GB.

[Jirka]

A co exFAT? Né že bych to chtěl používat, ale na 1TB disku 1TB volnýho místa, kterej fs tohle umí?

[mimi.vx]

jj a co jineho tento patentove chraneny FS umi ?

[Šangala]

Jak jsem uvedl na M$ lze vytvořit max 32GB.
A kde by se to místo vzalo? Že by si meta-informace zapisoval do cloudu :), navíc velikost alokační jednotky bude asi 128KiB, takže s malými soubory to bude rychle ubývat…

[Jirka]

Já jen, že jsem to zkoušel s 1GB virtuálním oddílem a po nahrání 100MB velkýho souboru a rozbalených zdrojáků jádra (cca 400MB) tam zbylo ze všech filesystémů nejvíc místa. Ne o moc, ale vyhrál to.
samozřejmě, tenhle fs je dobrej tak na flashdisk, nedovedu si představit tu kontrolu disku po blbým vypnutí u 650GB oddílu

[Šangala]

Nu dobrá :), ono by se to asi začalo měnit jak by se postupně přidávalo, možná kdyby se to srovnalo se xfs bylo by to spravedlivější (záleží na tom, kolik má fs před-alokované).

[lertimir]

Moje výsledky na velkoobjemových discích jsou:

df -T -t xfs 
Filesystem     Type  1K-blocks       Used Available Use% Mounted on
/dev/sdf1      xfs  1953382400 1623031540 330350860  84% /mnt/zaloha_1
/dev/sdb3      xfs  2705696768 2159806208 545890560  80% /mnt/afx
:~ # du -s -x /mnt/afx
2159602984      /mnt/afx
:~ # du -x /mnt/afx | wc -l
29695
:~ # du -x /mnt/zaloha_1 | wc -l
6635
:~ # du -s -x  /mnt/zaloha_1 
1622944084      /mnt/zaloha_1
:~ # 

A myslím, že du vypisuje součet skutečných velikostí souborů a df (used) vypisuje obsazené místo ve filesystému. Takže na mém xfs jsou ztráty pod promile.

[Jirka]

XFS moc neznám, nezkoušel jsem.
Možná by se toho mohl chytit někdo "od fochu" a udělat pořádný srovnání všech možných a nemožných fs, tentokrát ne na téma rychlost, ale úspornost při ukládání různých druhů a velikostí dat. Né každej potřebuje ze svýho PC/notesu obsloužit tisíce požadavků za vteřinu.

[Šangala]

Jde o to, že některé FS toho mají předa-alokováno více (ext4) a některé méně a alokují až za chodu (xfs) a například u btrfs se něčeho rozumného předem dopočítat je „ne-jednoduché“, takže nejvyšší vypovídající hodnotu má údaj „kolik se tam toho na konec vešlo“ na daném typu dat.
V rámci hraní si mám nachystaný i test, který bude něco podobného zjišťovat.