Обсуждение:Linux/ZeroInode

Из письма в devel@lists.altlinux.org от 23.10.2013

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

За последний год выявилось следующее:
1. Файловая система glusterfs, разработчики которой заявляют, что она не работает на 32-битных системах, на самом деле работает.
2. Файловая система XFS при достижении определённого объёма начинает создавать файлы с inode >2^32 (поскольку inode там зависит от позиции данных на диске)
3. Функция stat (32-битная функция stat — для структуры с 32-битным st_ino) возвращает ошибку, если inode у файла слишком велик
4. Многие программы (особенно такие важные, как apt и rpm) собраны без поддержки _FILE_OFFSET_BITS=64 (AC_SYS_LARGEFILE в configure.am)
и не способны работать с файлами (работа с файлами почти всегда включает в себя вызов функции stat).

Не дождавшись исправления сборки rpm (rpmReadSignature failed при inode, выходящем за 32 бита https://bugzilla.altlinux.org/show_bug.cgi?id=29117)
я подумал, что большинству программ, вызывающих stat(), значение inode не очень-то интересно.

Собственно, я рассматриваю 3 варианта:
1. Обнулять st_ino, если значение туда не влезает. Возражающие программы следует пересобрать со stat64()
2. Заполнять st_ino максимальным значением (все единицы). Возражающие программы следует пересобрать со stat64()
3. Сжимать значение inode в 32-битное (squash). Это существующая практика, применяемая в cifs, nfs и fuse. Но возникает вопрос с последствиями коллизий.

При использовании glibc исправление касается только glibc, при использовании других библиотек, предполагаю, нужно изменить и соответствующую функцию в ядре.