[devel] inode > 2^32 на 32-битных системах

[Vitaly Lipatov]

Добрый день!

Начну с того, что у нас в компании используются как 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, при 
использовании других библиотек, предполагаю, нужно изменить и 
соответствующую функцию в ядре.

Прошу совета, мнений, помощи.

Здесь некоторые подробности (то же самое другими словами и пример 
патча)
http://wiki.etersoft.ru/Linux/ZeroInode

-- 
С уважением,
Виталий Липатов,
Etersoft