Не может найти lib, который обеспечивает libneon.so.25

Образованное предположение

4 PiB.

Обоснование

SLES 9 уже около десяти лет, поэтому он не будет поддерживать файловые системы такого размера, как могут современные дистрибутивы Linux, или столько томов, сколько могут современные ядра. Новейшее поддерживаемое ядро в SLES 9 - 2.6.5.

Вы также искусственно ограничиваете себя, используя 32-битную ОС: более крупные файловые системы требуют больше оперативной памяти для управления. Консервативное эмпирическое правило - 1 GiB на TiB. Так как 32-битный Linux ограничен 4 гигабайтами обычно[1], вы подталкиваете его к использованию 32-битного Linux для управления более чем 4 тибайтами. Я зашел на 16 TiB и ушел от этого[2], но на самом деле я этого не рекомендую. Обычная ужасная история для fsck после отключения электричества не завершается из-за нехватки оперативной памяти, что не позволяет перемонтировать файловую систему.

Самой мощной файловой системой, встроенной в SLES 9, является JFS. Ограничение на размер тома в петабайт, таким образом, фактически неограниченное.

SLES 9 также поддерживает ReiserFS, которая имеет ограничение на размер тома в 16 ТБ. Это хорошо подходит для вашей 32-битной системы, по причинам ограничения оперативной памяти, приведенным выше.

Также существует ограничение на количество путей устройств /dev/sd в ядре Linux. Он изменялся несколько раз за время жизни Linux, в общих значениях power-of-2. Ограничение для SLES 9, вероятно, составляет 256 томов, исходя из -документированного ограничения для RHEL 3 и 4, которые примерно совпадают с SLES 9.[3]

Ограничением для хранилища является ограничение на размер тома, умноженное на максимальное количество томов. Мое приведенное выше число 4 PiB основано на максимальном размере тома 16 TiB × 256 томов.

You're Not Going to Hit the Limit

That's a awful lot of storage, whatever whatever you organization it. Фактическое количество заканчивается не очень важным по практическим соображениям. Простое подключение достаточного количества дисков к одному компьютеру для достижения этого угаданного предела будет довольно сложной задачей, особенно учитывая, что обычные дисковые контроллеры, совместимые с ядром 2.6.5, не будут поддерживать современные диски Advanced Format, так что вы, вероятно, не сможете использовать диски размером больше 2 ТБ.

Это означает, что вам нужны тысячи физических дисков, чтобы преодолеть этот предел в 4 ПБ.

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

Сноски:

1. PAE позволяет использовать до 64 гигабайт на 32-битной системе, но я не знаю, что ядро может использовать для буферного кэша любое пространство за пределами 4 гигабайт.

   Нет fsck реализации, о которой я знаю, может использовать и PAE, так как для этого требуется много специальных хитростей в пользовательских приложениях. Чрезвычайно мало программ когда-либо реально использовали PAE, в прошлые годы, когда это было жизнеспособным решением проблемы лимита оперативной памяти. (Сегодня можно было бы просто использовать 64-битную ОС.)

2. Потребность в оперативной памяти - это функция количества файлов и каталогов на диске, а также количество одновременных обращений к нему. Таким образом, "правило 1 Гб на Тб" является своего рода прокси-правилом.

   Я считаю, что единственная причина, по которой мне сошло с рук 16 Тб на 32-битном ядре - это то, что это были цифровые видеосерверы с небольшим количеством одновременных пользователей. Так как файлов было относительно мало и много, то fsck не нужно было жонглировать огромным количеством каталогов или файлов inodes, и не нужно было хранить много информации о файловой системе в оперативной памяти для отслеживания одновременных пользователей.

   Хорошим counterexample был бы почтовый сервер, который мог бы обслуживать тысячи одновременных пользователей, каждый из которых хотел бы иметь доступ к большому количеству маленьких файлов, разбросанных по тысячам каталогов.

3. Новые ядра увеличивают лимит до 1024, 4096 или 8192 томов.

   Теоретически можно получить до /dev/sdzz.... с 29 zs, что составляет примерно 10⁴¹ томов, но другие практические лимиты вступят в игру первыми.