просто используй райзер

dumpe2fs -h /dev/sda1

Отвечая на второй вопрос —

mke2fs -i X -b X

один inode создаётся на каждые N байт

на каждый файл/каталог

Filesystem volume name:   debian-root
Last mounted on:          /
Filesystem UUID:          44fc238a-ddbd-4301-b260-955a6f22539c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1966080
Block count:              7864320
Reserved block count:     157286
Free blocks:              5786157
Free inodes:              1736377
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Jul 19 08:25:52 2015
Last mount time:          Thu Aug 13 10:11:13 2015
Last write time:          Thu Aug 13 10:11:12 2015
Mount count:              90
Maximum mount count:      -1
Last checked:             Sun Jul 19 08:25:52 2015
Check interval:           0 (<none>)
Lifetime writes:          50 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       1049421
Default directory hash:   half_md4
Directory Hash Seed:      24d0c1ca-e506-489d-8595-1af81fa10472
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0002d3b2
Journal start:            20454

(Inode Count) x (Inode Size) = 1966080x256 байт = 480 мегабайт. Я что-то не так толкую, или всё очень плохо?

Ты посчитал, сколько места в файловой системе у тебя занимают иноды.

Blocks per group:         32768
Inodes per group:         8192

Block size:               4096

Тогда при умножении 16384 байт на кол-во айнодов, я получаю аккурат 30гигабайт (размер ФС). В таком случае, откуда могут возникнуть проблемы нехватки айнодов?

inode у тебя 256 байт.

Было бы странно, если получилось бы что-то иное.
Нехватка инодов возникает в том случае, когда средний размер файла меньше этого самого числа (т. е. 16384). При этом один файл не может занимать в файловой системе* места меньше, чем один блок (т. е. 4096).
А если создавать по иноде на блок, то их хватит с гарантией (ценой места, которое эти иноды будут занимать — в твоём случае почти два гигабайта вместо 480 мегабайт).

* Разумеется, речь в данном случае идёт об ext4.

Имеет значение именно средний размер файла, или же чисто кол-во мелких файлов?

М-да, тоже неприятно.

1 inode = 1 файл. Это всё, что тебе нужно знать. Если у тебя 1000 свободных inode, то ты не сможешь создать больше 1000 файлов, вне зависимости от их размера (даже если они будут занимать небольшую часть диска). То есть размер файла в данном случае вообще не имеет значения, количество inode регулирует только их максимальное количество.

Вспомни про FAT с её ограничением на размер корневого каталога, а также на количество файлов в каждом каталоге. Вот в ext4 также, но ограничено лишь общее количество файлов на диске. И размер ФС тут мало причём (за исключением того, что при дефолтных настройках форматирования размер корневого каталога в FAT и списка inode в ext4 выбирается как какой-то процент от размера диска, но это можно переопределить).

Все эти рассуждения про «средний размер файла» выше - полный бред, имеющий лишь теоретический смысл. Это всего лишь способ забить полностью одновременно и диск, и таблицу inode, что как цель сама по себе лишено практического смысла. В реальности у 95% пользователей место на диске кончится раньше, а у 5% раньше кончатся inode, однако последнее обычно случается в особых случаях (хранить сотни тысяч файлов на несколько килобайт - не самое часто занятие пользователей) и это заранее известно, поэтому при форматировании делают таблицу inode больше стандартного. И это совершенно нормально, нет ничего плохого в том, что место кончится сильно раньше inode (вот когда наоборот - это вызывает печаль, но такие случаи обычно заранее известны и можно применить специальные настройки).

А ещё есть ФС, где отсутствует максимальное количество inode, потому что их список хранится не в простой таблице, а в более сложных динамических структурах (всякие бинарные деревья и т. д.). Например, BTRFS.

btrfs

на btrfs такой шляпы нет

Только количество всех файлов. Их размер совершенно не важен в данном случае. У тебя есть N inode - ты можешь создать не более N файлов. Влезут ли они на диск - отдельный вопрос, который с максимальным количеством inode никак не пересекается.

Если ты чувствуешь, что на твоей задаче ты быстро потратишь все inode, - при форматировании задай большее их количество. Или переходи на BTRFS и другие ФС, у которых безлимитные inode. Однако среднестатистический пользователь с такими проблемами вряд ли столкнётся.

Имеет значение количество файлов, тут KivApple яснее меня высказался.
Я всего лишь имел в виду, что если у тебя средний размер файла меньше, чем (размер блока × отношение количества блоков к количеству инод), то при попытке забить такими файлами всю фс иноды кончатся раньше, чем место. Классический пример — создать небольшой раздел под портеж и отформатировать в ext4 с дефолтными параметрами.

Насчёт «полного бреда» ты всё же погорячился. Я лишь сказал, что нехватка инодов возникает в описанном случае, а не утверждал, будто описанные условия гарантируют эту самую нехватку.

Всё понял, спасибо. Правильно ли я понимаю, что если у меня нет значительного количества файлов размером < (размер фс)/(кол-во inode), то париться не о чем?

Я посмотрел выхлоп df и df -i для корня и хомяка. На корне места занято в 2.5 раза больше, чем inode (в процентах), на хомяке - различие в 6 раз.

ещё раз, количество файлов+количество каталогов==количество inode

Мне не понятно какую практическую ценность несёт такой расчёт. Подстраивать размер файлов какого-нибудь проекта под этот коэффициент, чтобы максимально эффективно использовать inode? Бессмысленно, потому что ФС это не БД и куда эффективнее иметь 1 многогигабайтный файл с какой-нибудь нормальной БД. Куда логичнее оценить полностью независимо суммарный размер файлов и их количество. Если первое получается слишком большим - покупаем HDD побольше. Если второе - указываем нужные опции форматирования. Но считать то коэффициент зачем. Чтобы на полностью забитом диске не осталось несколько свободных мегабайт в таблице inode?

Слушай, ещё вопрос. Я делаю в /home find -type f | wc -l, find -type d | wc -l и получаю 115878 файлов и каталогов в сумме. Потом я выполняю find | wc -l и получаю 155632. А результат вычитания free inodes из inodes count - вообще 149448. Не подскажешь, чем обусловлено несовпадение этих чисел? /home - отдельный раздел, в нём нет других точек монтирования.

ТС спросил:

Насколько я знаю, один inode создаётся на каждые N байт. Как бы посмотреть, чему равно это самое N?

Ну, я и помог с расчётами. Вопрос практической пользы — отдельно, и я сосгласен с тобой, что смысла в самом по себе этом числе особо нет.

Вспомни про FAT с её ограничением на размер корневого каталога,

это есть.

> а также на количество файлов в каждом каталоге.

а вот этого нет. Точнее, есть, конечно, но его достижение не имеет смысла : это надо весь диск забить каталогом с файлами нулевой длины.

Вот в ext4 также, но ограничено лишь общее количество файлов на диске.

Да нет, не также. Разница принципиальная.

Думаю, у вас в home файлы других типов (символьные ссылки, пайпы). Что выдаёт команда:

find '!' -type f -and '!' -type d | wc -l

Точного совпадения find | wc -l и df -i не должно быть, первые 11 инодов используются для системных целей: http://www.vidarholen.net/contents/junk/inodes.html Почему у вас эта разница больше 11 я не знаю может на ext4 иноды ещё куда резервируются.