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

[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

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

On Wed, Oct 23, 2013 at 05:56:45PM +0400, Vitaly Lipatov wrote:
[...]
> Прошу совета, мнений, помощи.

В феврале в glibc'шном списке рассылки упоминались еще некоторые идеи:
http://sourceware.org/ml/libc-alpha/2013-02/msg00575.html
http://sourceware.org/ml/libc-alpha/2013-02/msg00580.html


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Vitaly Lipatov]

Dmitry V. Levin писал 2013-10-23 18:29:
> On Wed, Oct 23, 2013 at 05:56:45PM +0400, Vitaly Lipatov wrote:
> [...]
>> Прошу совета, мнений, помощи.
>
> В феврале в glibc'шном списке рассылки упоминались еще некоторые 
> идеи:
> http://sourceware.org/ml/libc-alpha/2013-02/msg00575.html
> http://sourceware.org/ml/libc-alpha/2013-02/msg00580.html

Ни одна из которых не способна решить нашу проблему с rpm?
Как я понял, одно предложение заключалось в том, чтобы структуру stat 
заполнять, как получится, в любом случае, но при этом и код ошибки 
возвращать.

Второе предложение — заставить всех собираться со 
-D_FILE_OFFSET_BITS=64, применяя следующие меры:
1. Поставить его в параметры по умолчанию
2. Удалить из заголовочных файлов glibc описание 32-битной структуры и 
функции

Я бы смотрел на проблемы с точки зрения legacy-программ. Ну или хотя бы 
rpm, который сложно, и, наверное, незачем
было бы пересобирать с -D_FILE_OFFSET_BITS=64.

Этой проблемы они не решают.

Я просто подумал, что это надо обсуждать с разработчиками glibc, 
поэтому и пишу сюда :)

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

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On Fri, Oct 25, 2013 at 02:18:36PM +0400, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 2013-10-23 18:29:
> >On Wed, Oct 23, 2013 at 05:56:45PM +0400, Vitaly Lipatov wrote:
> >[...]
> >>Прошу совета, мнений, помощи.
> >
> >В феврале в glibc'шном списке рассылки 
> >упоминались еще некоторые идеи:
> >http://sourceware.org/ml/libc-alpha/2013-02/msg00575.html
> >http://sourceware.org/ml/libc-alpha/2013-02/msg00580.html
> 
> Ни одна из которых не способна решить 
> нашу проблему с rpm?

Наверное, смена умолчания у _FILE_OFFSET_BITS в перспективе могда бы
решить проблему, но по дороге придется неизвестно сколько всего чинить.

Для решения проблемы с rpm достаточно решить вопрос с fts в glibc:
http://sourceware.org/bugzilla/show_bug.cgi?id=11460

Или засунуть копию реализации fts из glibc/gnulib прямо в rpm,
как это сделал jbj в 2002 году.

> Я просто подумал, что это надо обсуждать 
> с разработчиками glibc, поэтому и пишу сюда 
> :)

Я могу рассказать, где можно встретить больше разработчиков glibc,
чем тут. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Vitaly Lipatov]

Dmitry V. Levin писал 2013-10-25 15:04:
> On Fri, Oct 25, 2013 at 02:18:36PM +0400, Vitaly Lipatov wrote:
>> Dmitry V. Levin писал 2013-10-23 18:29:
>> >On Wed, Oct 23, 2013 at 05:56:45PM +0400, Vitaly Lipatov wrote:
>> >[...]
>> >>Прошу совета, мнений, помощи.
>> >
>> >В феврале в glibc'шном списке рассылки
>> >упоминались еще некоторые идеи:
>> >http://sourceware.org/ml/libc-alpha/2013-02/msg00575.html
>> >http://sourceware.org/ml/libc-alpha/2013-02/msg00580.html
>>
>> Ни одна из которых не способна решить
>> нашу проблему с rpm?
>
> Наверное, смена умолчания у _FILE_OFFSET_BITS в перспективе могда бы
> решить проблему, но по дороге придется неизвестно сколько всего 
> чинить.
>
> Для решения проблемы с rpm достаточно решить вопрос с fts в glibc:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11460
Это была риторика, я не сомневаюсь, что конкретную проблему с 
конкретным rpm мы поборем.
Я о том, что предложенные там решения ничего не дают существующему 
коду.

И я так понимаю, что мало кому это важно, все счастливы на 64-битных 
системах.

> Я могу рассказать, где можно встретить больше разработчиков glibc,
> чем тут. :)
Посоветуйте, пожалуйста, где лучше продолжить обсуждение, чтобы это 
могло повлиять на код glibc.

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