Какой объем физического диска может обрабатывать SLES 9? Есть ли какие-либо ограничения?

Question 1

Обоснованная догадка

Оправдание

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

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

Самая мощная файловая система, встроенная в SLES 9, — этоJFS. Его предельный размер тома превышенпетабайты, таким образом, фактически неограниченно.

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

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

Предел хранения — это предельный размер тома, умноженный на максимальное количество томов. Мое число 4 ПиБ выше основано на максимальном размере тома 16 ТиБ × 256 томов.

Вы не достигнете предела

Это ужасно много места для хранения, независимо от того, как вы его организуете. Фактическое число оказывается не таким уж важным по практическим причинам. Просто подключить достаточно дисков к одному компьютеру, чтобы достичь этого предполагаемого предела, будет довольно сложной задачей, особенно учитывая, что распространенные контроллеры дисков, совместимые с ядром 2.6.5, не будут поддерживать современныеРасширенный форматдисков, поэтому вы, скорее всего, не сможете использовать диски объемом более 2 ТБ.

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

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

Сноски:

ПАЕпозволяет использовать до 64 ГиБ в 32-битной системе, но я не знаю, может ли ядро использовать пространство свыше 4 ГиБ для буферного кэша.

Ни одна fsckизвестная мне реализация не может использовать PAE, поскольку для этого требуется много специальных уловок в приложениях пользовательского пространства. Чрезвычайно малое количество программ когда-либо реально использовали PAE, в прошлые годы, когда это было жизнеспособным решением проблемы ограничения ОЗУ. (Сегодня вы бы просто использовали 64-битную ОС.)
Потребность в оперативной памяти зависит от количества файлов и каталогов на диске, а также от количества одновременных обращений, которые он обслуживает. Таким образом, «правило 1 GiB на TiB» является своего рода правилом прокси.

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

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

Теоретически, вы можете получить значение /dev/sdzzz....до 29 zс, что примерно равно ¹⁰⁴¹ объемам, но в первую очередь в игру вступят другие практические ограничения.

Answer

Обоснованная догадка

4ПиБ.

Оправдание

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

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

Самая мощная файловая система, встроенная в SLES 9, — этоJFS. Его предельный размер тома превышенпетабайты, таким образом, фактически неограниченно.

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

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

Предел хранения — это предельный размер тома, умноженный на максимальное количество томов. Мое число 4 ПиБ выше основано на максимальном размере тома 16 ТиБ × 256 томов.

Вы не достигнете предела

Это ужасно много места для хранения, независимо от того, как вы его организуете. Фактическое число оказывается не таким уж важным по практическим причинам. Просто подключить достаточно дисков к одному компьютеру, чтобы достичь этого предполагаемого предела, будет довольно сложной задачей, особенно учитывая, что распространенные контроллеры дисков, совместимые с ядром 2.6.5, не будут поддерживать современныеРасширенный форматдисков, поэтому вы, скорее всего, не сможете использовать диски объемом более 2 ТБ.

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

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

Сноски:

ПАЕпозволяет использовать до 64 ГиБ в 32-битной системе, но я не знаю, может ли ядро использовать пространство свыше 4 ГиБ для буферного кэша.

Ни одна fsckизвестная мне реализация не может использовать PAE, поскольку для этого требуется много специальных уловок в приложениях пользовательского пространства. Чрезвычайно малое количество программ когда-либо реально использовали PAE, в прошлые годы, когда это было жизнеспособным решением проблемы ограничения ОЗУ. (Сегодня вы бы просто использовали 64-битную ОС.)
Потребность в оперативной памяти зависит от количества файлов и каталогов на диске, а также от количества одновременных обращений, которые он обслуживает. Таким образом, «правило 1 GiB на TiB» является своего рода правилом прокси.

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

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

Теоретически, вы можете получить значение /dev/sdzzz....до 29 zс, что примерно равно ¹⁰⁴¹ объемам, но в первую очередь в игру вступят другие практические ограничения.

Question 2

Насколько мне известно, предела нет, а если он и существует, то вы вряд ли его достигнете. После ротации по всем sd[az] диски будут помечены как sdaa через sdazz и так далее. Так что если и есть предел, то это количество дисков, которые схема может пометить в пределах максимальной длины пути файла (UUID могут измениться, в этом я не уверен).

Это касается только IDE, SCSI, SATA и подобных. Я думаю, что USB и другие будут иметь другие ограничения.

Answer

Насколько мне известно, предела нет, а если он и существует, то вы вряд ли его достигнете. После ротации по всем sd[az] диски будут помечены как sdaa через sdazz и так далее. Так что если и есть предел, то это количество дисков, которые схема может пометить в пределах максимальной длины пути файла (UUID могут измениться, в этом я не уверен).

Это касается только IDE, SCSI, SATA и подобных. Я думаю, что USB и другие будут иметь другие ограничения.

Какой объем физического диска может обрабатывать SLES 9? Есть ли какие-либо ограничения?

решение1

Обоснованная догадка

Оправдание

Вы не достигнете предела

решение2

Связанный контент