Řešení 1:
Abych odpověděl na původní otázku, i když je pro tazatele pravděpodobně pozdě - ano, zvýšení EXT2/3 na LVM2 také zvýší limit inodů.
Právě měl oddíl o velikosti 1G s limitem 65k inodů. Po
lvextend -L+1G /dev/vg/var
umount /var
resize2fs /dev/vg/var
mount /var
... můj limit inodů je nyní 128 k.
Řešení 2:
muž mke2fs
Uvidíte -N pro počet inodů
Můžete jej tedy specifikovat při formátování nového oddílu. To teď moc nepomáhá, co?
tune2fs, který ladí souborový systém, nezdá se, že by měl způsob, jak přidat další inody.
Ale možná to dělá ext3 nebo 4 a někdo další ví...?
Nyní tedy máte možnost:zálohovat, přeformátovat oddíl, obnovit.
Řešení 3:
Pokud jste věděli, že malé soubory zaberou místo na disku, měli jste místo EXT2/3/4 (předpokládám, že používáte) použít FS s dynamickou alokací inodů, jako je ReiserFS nebo jakýkoli nový moderní FS (XFS, JFS). , to jsi neřekl).
Migrace souborového systému je ve vaší situaci pravděpodobně dobrou volbou.
Řešení 4:
Jako mezník připojte nový souborový systém a cp/rm/ln-s tam přidejte část vaší hierarchie fs. Nyní máte několik náhradních inodů! Nemůžete mv soubory mezi dvěma fses, takže si dejte pozor na věci, které to potřebují, ale pro mnoho aplikací to může být transparentní.
Pak podle Paulovy rady vytvořte nový fs a migrujte na něj.
Řešení 5:
Ext4 trpí stejným problémem, pokud vytvoříte malý oddíl a máte spoustu malých souborů, dojdou vám inody, a pokud máte flex_bg ve funkcích, které nemůžete použít tune2fs ke zvýšení inodů.
Osobně bych šel s ext4 přes jakoukoli verzi rieserfs, při formátování proveďte následující:
mkfs.ext4 -I 512 /dev/foo
tune2fs -i0 -c0 -o journal_data_writeback /dev/foo
Formátování tímto způsobem vám poskytne 33160 inodů na 512M zaváděcím oddílu.
Říkám to jako někdo, kdo roky používal reiserfs, podpora jádra není tak dobrá jako ext* a souborový systém se časem fragmentuje a zpomaluje.