Chyba v implementaci funkce ext4 dir_index který používáte na vašem cílovém souborovém systému.
Řešení:znovu vytvořte souborový systém bez dir_index. Nebo deaktivujte funkci pomocí tune2fs (je nutná určitá opatrnost, viz související odkaz Novell SuSE 10/11:Zakázat indexování H-stromu na souborovém systému ext3, který se sice týká ext3 může vyžadovat podobnou opatrnost.
(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)
- ext4:Záhadné chyby „Na zařízení nezbývá místo“ – chyby
ext4 má ve výchozím nastavení povolenou funkci nazvanou dir_index, která je docela náchylná na hašovací kolize.
......
ext4 má možnost hashovat názvy souborů svého obsahu. To zvyšuje výkon, ale má to „malý“ problém:ext4 nezvětší svůj hashtable, když se začne zaplňovat. Místo toho vrátí -ENOSPC nebo „na zařízení nezbývá místo“.
Návrhy lepších možností než ext4 pro ukládání velkého množství malých souborů:
Pokud používáte souborový systém jako úložiště objektů, možná se budete chtít podívat na použití souborového systému, který se na to specializuje, možná na úkor jiných vlastností. Rychlé vyhledávání Google nalezlo Ceph , který se zdá být open source a lze jej připojit jako souborový systém POSIX, ale také k němu přistupovat pomocí jiných API. Nevím, jestli se vyplatí používat na jednom hostiteli bez využití replikace.
Dalším systémem pro ukládání objektů je OpenStack's Swift . Jeho designová dokumentace říká, že ukládá každý objekt jako samostatný soubor s metadaty v xattrs. Tady je o tom článek. Jejich průvodce nasazením říká, že zjistili, že XFS poskytuje nejlepší výkon pro ukládání objektů. Takže i když pracovní zatížení není to, v čem je XFS nejlepší, bylo zjevně lepší než konkurenti, když RackSpace testoval věci. Swift možná upřednostňuje XFS, protože XFS má dobrou/rychlou podporu pro rozšířené atributy. Mohlo by se stát, že ext3/ext4 by fungovaly dobře na jednotlivých discích jako backend úložiště objektů, pokud by nebyla potřeba další metadata (nebo kdyby byla uložena v binárním souboru).
Swift provádí replikaci / vyrovnávání zatížení za vás a navrhuje, abyste mu dali souborové systémy vytvořené na nezpracovaných discích, ne RAID . Poukazuje na to, že jeho pracovní zátěž je v podstatě nejhorší případ pro RAID5 (což dává smysl, pokud mluvíme o pracovní zátěži se zápisy malých souborů. XFS je obvykle nezabalí úplně od hlavy k patě, takže získat zápisy v celém proužku a RAID5 musí provést nějaké čtení, aby aktualizoval paritní pruh. Dokumenty Swift také hovoří o použití 100 oddílů na jednotku. Předpokládám, že je to termín Swift a nemluví o vytvoření 100 různých souborových systémů XFS na každém SATA disk.
Spuštění samostatného XFS pro každý disk je ve skutečnosti obrovský rozdíl . Místo jednoho gigantického free-inode map, každý disk bude mít samostatný XFS se samostatnými seznamy volných míst. Také se vyhne penalizaci RAID5 za malé zápisy.
Pokud již máte svůj software postavený tak, aby používal souborový systém přímo jako úložiště objektů, místo abyste procházeli něčím, jako je Swift, abyste zvládli replikaci / vyvažování zátěže, můžete se alespoň vyhnout tomu, aby byly všechny soubory v jednom adresáři. (Neviděl jsem, že dokumenty Swift říkají, jak rozkládají své soubory do více adresářů, ale jsem si jistý, že ano.)
U téměř jakéhokoli normálního souborového systému pomůže použití struktury jako
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
Pravděpodobně je rozumné asi 10 000 položek, takže vzít dobře rozložené 4 znaky názvů objektů a použít je jako adresáře je snadné řešení. Nemusí to být moc dobře vyvážené. Lichý 100k adresář pravděpodobně nebude znatelný problém a stejně tak některé prázdné adresáře.
XFS není ideální pro velké množství malých souborů. Dělá, co může, ale je více optimalizovaný pro streamování zápisů větších souborů. Celkově je to ale velmi dobré pro běžné použití. Nemá ENOSPC na kolize v jeho indexování adresářů (AFAIK) a zvládne mít jeden adresář s miliony záznamů. (Ale stále je lepší použít alespoň jednoúrovňový strom.)
Dave Chinner měl nějaké připomínky k výkonu XFS s velkým počtem přidělených inodů, což vedlo k pomalému touch výkon. Nalezení volného inodu k přidělení začíná zabírat více času CPU, protože bitmapa volného inodu se fragmentuje. Všimněte si, že to není problém jednoho velkého adresáře vs. více adresářů, ale spíše problém mnoha použitých inodů v celém souborovém systému. Rozdělení souborů do více adresářů pomáhá s některými problémy, jako je ten, který se udusil ext4 v OP, ale ne problém celého disku se sledováním volného místa. Ve srovnání s obřím XFS na RAID5 tomu pomáhá Swift samostatný souborový systém-per-disk.
Nevím, jestli btrfs je v tom dobrý, ale myslím, že může být. Myslím, že Facebook zaměstnává svého hlavního vývojáře z nějakého důvodu. :P Některé benchmarky, které jsem viděl, například untarring zdrojového kódu linuxového jádra, ukazují, že btrfs funguje dobře.
Znám reiserfy byl pro tento případ optimalizován, ale už se jen stěží, pokud vůbec, udržuje. Opravdu nemohu doporučit jít s reiser4. Mohlo by být zajímavé experimentovat. Ale je to zdaleka nejméně perspektivní volba. Také jsem viděl zprávy o snížení výkonu na starém reiserFS a neexistuje žádný dobrý nástroj pro defragmentaci. (google filesystem millions of small files a podívejte se na některé ze stávajících odpovědí stackexchange.)
Pravděpodobně mi něco uniká, takže poslední doporučení:zeptejte se na to na serverfault! Kdybych si měl něco vybrat právě teď, řekl bych, že vyzkoušejte BTRFS, ale ujistěte se, že máte zálohy. (zejména pokud používáte vestavěnou vícediskovou redundanci BTRFS místo toho, abyste jej spouštěli nad RAID. Výkonnostní výhody mohou být velké, protože malé soubory jsou pro RAID5 špatnou zprávou, pokud se nejedná o zátěž převážně pro čtení.)
Pro tento problém níže je to, co jsem udělal, abych jej opravil (možná budete potřebovat přístup sudo pro níže uvedené kroky):
-
Využitý prostor Inodes byl 100%, což lze získat pomocí níže uvedeného příkazu
df -i /
Inody souborového systému IUsed IFree IUse% Připojeno na
/dev/xvda1 524288 524288 o 100% /
- Musíte uvolnit iNoted, a proto je potřeba najít soubory, které zde mají počet i uzlů pomocí níže uvedeného příkazu:
Zkuste zjistit, zda se nejedná o problém s inody s:
df -ih
Zkuste najít kořenové složky s velkým počtem inodů:
for i in /*; do echo $i; find $i |wc -l; done
Zkuste najít konkrétní složky:
for i in /src/*; do echo $i; find $i |wc -l; done
- nyní jsme vynulovali složku s velkým počtem souborů. Spusťte níže uvedené příkazy jeden po druhém, abyste se vyhnuli jakékoli chybě (v mém případě byla skutečná složka /var/spool/clientmqueue):
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +