ext4 inode size?

уменьшу размер inode до 1024 байт

Ты упоролся? Там по умолчанию всегда 256. Менять это значение не нужно.

*block* size нужен тебе.

Там это где?

Тормознул, глянул на значение bytes-per inode. Про него и хочу спросить, т.е. оно влияет на то количество inode которое будет создано.

Про него и хочу спросить, т.е. оно влияет на то количество inode которое будет создано.

       -i bytes-per-inode
              Specify  the  bytes/inode  ratio.   mke2fs  creates an inode for
              every bytes-per-inode bytes of space on the  disk.   The  larger
              the  bytes-per-inode  ratio,  the  fewer inodes will be created.
              This value generally shouldn't be smaller than the blocksize  of
              the  filesystem,  since  in  that case more inodes would be made
              than can ever be used.  Be warned that it  is  not  possible  to
              expand the number of inodes on a filesystem after it is created,
              so be careful deciding the correct value for this parameter.

Это из мана. А вот размер иноды я бы не трогал без чёткого понимания того что это действительно очень нужно.

По умолчанию на inode выделяется 16384 байт. Почему не 4096 например, это же позволить увеличить максимальное количество файлов.

Да, я читал, но не могу понять почему по умолчанию 16 Кбайт, не логичнее ли сделать 4096, как дефолтный размер блока. Уменьшение количества байтов повлияет на что то еще?

Почему не 4096 например, это же позволить увеличить максимальное количество файлов.

Потому что и по умолчанию много для большинства случаев. Можешь менять значение по своему усмотрению, исходя из потребностей. Вместо -i можно использовать -N, чтобы не напрягаться расчётами.

не логичнее ли сделать 4096, как дефолтный размер блока.

Чтобы из каждых 931 Gb (один терабайт) ≈28 Gb терять под таблицу inode?

А, ошибся, не 28, а 56.

почему по умолчанию 16 Кбайт

У df есть ключик -i который покажет тебе сколько свободных инодов. Ты сейчас хочешь увеличить их кол-во ещё в 4 раза. Зачем?

Уменьшение количества байтов повлияет на что то еще?

Иноды отожрут больше места.

Вообще, мы движимся к динамическому выделению инод и тогда всё будет не нужно.

Вообще, мы движимся к динамическому выделению инод и тогда всё будет не нужно.

Речь об ext4? Пруф?

Каким образом вышла такая цифра?

Да я видел, осталось 43%, при том что хлама в /var как всегда.

Вообще, мы движимся к динамическому выделению инод и тогда всё будет не нужно.

reiser вроде как закопали, btrfs клюкодромит, если запилят в ext то будет неплохо.

Из опыта. Можешь сам попробовать, анонимус разрешает.

Анонимус всегда крут. Но все таки, сколько занимают inod-ы?

Речь об ext4? Пруф?

Омг, гуглёж показал что на это забили. Думаю, дело в том что Теодор Тсо хочет чтобы ext4 по структуре данных была совместима с ext3.

Да я видел, осталось 43%

этого мало? Мне сложно придумать сценарий когда не хватало бы инод. На ум приходит только почтовый сервер с кучей почты в формате «каждое письмо - отдельный файл».

Я так же видел проблемы с исчерпанием инод на хостах где софтины не подчищали за собой временные файлы. Может это твой случай?

Частично, это кеш плюс логи. Хотя сейчас и так забито почти на максимум.

Это только если они будут использованы, да?

reiser вроде как закопали

Как закопали? В чём это выражается?

Нет, таблица статична. Независимо от способа её инициализации, это место будет занято изначально.

Чем спрашивать, давно мог бы поэкспериментировать.

Так в том и дело что проэкспериментировал, df показывает что занято намного меньше чем должно быть.

Кэш чего? Оно действительно имеет смысл или лежит мёртвым грузом?

Хотя сейчас и так забито почти на максимум.

В смысле свободное место? Ну тогда неочем беспокоиться.

При чём тут df, бестолочь? Размер таблицы вычитается из размера ФС, а не из свободного места. Ты бы ещё размер журнала через df вычислял, петросян :)

Например тем, что убирают поддержку в установщике того же дебиана, хотя можно подгрузить через экспертный режим, но это как бы намекает. 4 рейзер до сих пор не всунули в ядро, хотя оно уже должно быть более-менее стабильно.

4 рейзер до сих пор не всунули в ядро, хотя оно уже должно быть более-менее стабильно.

Reiser4 - глючное и тормозное УГ

4 рейзер до сих пор не всунули в ядро, хотя оно уже должно быть более-менее стабильно.

Оно намного мертвее, чем reiserfs 3.6.

убирают поддержку в установщике того же дебиана

Разработка заморожена, это да. Но это не означает, что ей нельзя пользоваться.

Кстати, есть намёки на развитие 3.6 в 3.7, с поддержкой фич несовместимости, à la ext4.

А размер журнала я через ls -h смотрел. Тебе лишь бы поржать. Спасибо за инфу, дорогой Анон.

Кэш динамического веба, имеет конечно, но логи все равно больше занимают. В любом случае альтернативы ext4 пока не вижу.

логи все равно больше занимают

брр, у тебя миллион файлов логов? Одна инода = один файл.

Да, куча. Вот хочу нормально все раскинуть по контейнерам если честно, будет спокойнее.

Да, куча

Опиши задачу которую решают логи. У меня есть подозрения что вы делаете что-то неправильно.

Эти логи возникли в результате костыльного решения, в тестинге. Под /var выделил 20, так как файлы были милиразмерные совсем, я тормознул, думал что там как в xfs динамически будет выделятся. Буду теперь заранее считать....

Эти логи возникли в результате костыльного решения

А если с этого начать решать проблему? Проблема в том что ни одна ФС (по крайней мере на hdd) быстро работать с кучей файлов не может (я проверял). Это проявляется, например, когда надо сделать find /var, или прогнать rsync или сделать бэкапы.

А что за логи-то? Как они обрабатываются? Может проще их в базу загнать?

Да логи простейшие, по отбору запросов на статический контент, которые потом прогонялись скриптом. Конечно нормальные люди сразу засунули бы в базу, но это было так для поиграться вначале. Со скоростью конечно труба (относительно), даже в десяточке.

Для маленьких файлов лучше рейзера нету вроде, а вот судьба рейзера не ясна. А вообще сейчас мода пошла ssd везде пихать.

Так засунуть их в базу это же пара строк в коде, не? Можно даже не в базу, можно в файл который ротировать через logrotate. Этим вообще двух зайцев убьёте: уменьшение фрагментации, болеее быстра обработка, не надо find-ом делать поиск.

Единственное, я не помню что там на счёт многопоточной записи в файл. Возможно, понадобится блокировка. В общем, см. man write()

На счет многопоточной буду смотреть, спасибо.

Кстати вот назрел вопрос, если например в той же xfs иноды выделяются динамически, то резервируется ли для них какой-то кусок на диске. Или они будут отжирать место при увеличении кол-ва файлов?

Не знаю, но я бы не стал резервировать место т.к. это превращяется в статическую аллокацию.

Я бы выделял место из свободного пространства. Если места больше нет то и файлов не запишешь, даже если есть иноды.

При желании можно поковырять сырцы xfs, но эту задачку я оставлю для пытливого читателя :)

Нашёл у себя такую вкладку: http://oss.sgi.com/archives/xfs/2004-06/msg00071.html

Иноды в xfs выделяются блоками по 64 штуки. Теоретически возможна ситуация, когда место есть, но иноды выделить невозможно из-за требований к выравниванию. Где-то в документации было упоминание о реально возникших ошибках такого рода при >85% занятого места, но вероятность такого исхода очень мала.

Спасибо, вот еще в мане на счет размеров:

This specifies the maximum percentage of space in the filesystem that can be allocated to inodes. The default value is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% for filesystems over 50TB.

Спасибо.

ты ман читал? вот то, что тебе надо:

      -I inode-size
              Specify  the size of each inode in bytes.  mke2fs creates 256-byte inodes by default.  In kernels after 2.6.10 and
              some earlier vendor kernels it is possible to utilize inodes larger than 128 bytes to  store  extended  attributes
              for  improved  performance.   The  inode-size  value  must be a power of 2 larger or equal to 128.  The larger the
              inode-size the more space the inode table will consume, and this reduces the usable space in  the  filesystem  and
              can  also  negatively  impact  performance.  Extended attributes stored in large inodes are not visible with older
              kernels, and such filesystems will not be mountable with 2.4 kernels at all.  It is not possible  to  change  this
              value after the filesystem is created.

Тормознул, глянул на значение bytes-per inode. Про него и хочу спросить, т.е. оно влияет на то количество inode которое будет создано.

если хочешь много мелких файлов - ставь меньше.