Quanto disco físico o SLES 9 pode suportar? Existem limitações?

Question 1

Suposição educada

Justificação

SLES 9 écerca de uma década agora, portanto, não suportará sistemas de arquivos tão grandes quanto as distros Linux modernas podem, ou tantos volumes quanto os kernels modernos podem. O kernel mais recente suportado no SLES 9 é o 2.6.5.

Você também está se limitando artificialmente ao usar um sistema operacional de 32 bits: sistemas de arquivos maiores exigem mais RAM para serem gerenciados. Uma regra prática conservadora é 1GiBporTiB. Como o Linux de 32 bits normalmente é limitado a 4 GiB[1], você está forçando-o a usar um Linux de 32 bits para gerenciar mais de 4 TiB. Cheguei a 16 TiB e consegui [2], mas na verdade não estou recomendando isso. Uma história de terror comum é que fsckapós uma queda de energia não seja concluída devido à falta de RAM, evitando assim que o sistema de arquivos seja remontado.

O sistema de arquivos mais capaz que vem integrado no SLES 9 éJFS. Seu limite de tamanho de volume está nopetabytes, portanto efetivamente ilimitado.

SLES 9 também suportaReiserFS, que tem um limite de tamanho de volume de 16 TiB. Esta é uma boa combinação para o seu sistema de 32 bits, pelos motivos de limite de RAM acima.

Também há um limite no número de /dev/sdcaminhos de dispositivos no kernel do Linux. Ele mudou algumas vezes ao longo da vida do Linux, em valores comuns de potência de 2. O limite para o SLES 9 é provavelmente de 256 volumes, com base nolimite documentadopara RHEL 3 e 4, que são aproximadamente contemporâneos do SLES 9.[3]

O limite de armazenamento é o limite de tamanho do volume vezes o número máximo de volumes. Meu número de 4 PiB acima é baseado em um tamanho de volume máximo de 16 TiB × 256 volumes.

Você não vai atingir o limite

É uma quantidade enorme de armazenamento, não importa como você o organize. O número real acaba não sendo muito importante por razões práticas. Simplesmente conectar discos suficientes a um único computador para atingir esse limite estimado será um grande desafio, especialmente considerando que os controladores de disco comuns compatíveis com o kernel 2.6.5 não suportamFormato Avançadodiscos, então você provavelmente não poderá usar discos maiores que 2 TB.

Isso significa que você precisa de milhares de discos físicos para atingir esse limite de 4 PiB.

Se você não atingir primeiro um limite de conectividade ou de tamanho de rack, encontrará algum outro limite prático antes de atingir o limite técnico absoluto.

Notas de rodapé:

PAEpermite até 64 GiB em um sistema de 32 bits, mas não sei se o kernel pode usar qualquer espaço além de 4 GiB para o cache do buffer.

Nenhuma fsckimplementação que eu conheça pode fazer uso do PAE, já que são necessários muitos truques especiais em aplicativos de espaço do usuário para fazer isso. Um número extremamente pequeno de programas fez uso real do PAE, nos últimos anos, quando era uma solução viável para o problema do limite de RAM. (Hoje, você usaria apenas um sistema operacional de 64 bits.)
A necessidade de RAM é função do número de arquivos e diretórios no disco e do número de acessos simultâneos que ele atende. A "regra de 1 GiB por TiB" é, portanto, uma espécie de regra de proxy.

Acredito que a única razão pela qual consegui 16 TiB em um kernel de 32 bits é que esses eram servidores de vídeo digital com poucos usuários simultâneos. Como os arquivos eram relativamente poucos e grandes, fscknão era necessário fazer malabarismos com um grande número de diretórios ou arquivosinodes, e não precisava manter muitas informações do sistema de arquivos na RAM para rastrear usuários simultâneos.

Um bom contraexemplo seria um servidor de e-mail, que pode servir milhares de usuários simultâneos, cada um querendo acesso a uma grande quantidade de arquivos pequenos, espalhados por milhares de diretórios.
Os kernels mais recentes aumentam o limite para 1.024, 4.096 ou 8.192 volumes.

Teoricamente, você pode chegar /dev/sdzzz....a 29 zs, o que equivale a aproximadamente 10 ⁴¹ volumes, mas outros limites práticos entrarão em ação primeiro.

Answer

Suposição educada

4PiB.

Justificação

SLES 9 écerca de uma década agora, portanto, não suportará sistemas de arquivos tão grandes quanto as distros Linux modernas podem, ou tantos volumes quanto os kernels modernos podem. O kernel mais recente suportado no SLES 9 é o 2.6.5.

Você também está se limitando artificialmente ao usar um sistema operacional de 32 bits: sistemas de arquivos maiores exigem mais RAM para serem gerenciados. Uma regra prática conservadora é 1GiBporTiB. Como o Linux de 32 bits normalmente é limitado a 4 GiB[1], você está forçando-o a usar um Linux de 32 bits para gerenciar mais de 4 TiB. Cheguei a 16 TiB e consegui [2], mas na verdade não estou recomendando isso. Uma história de terror comum é que fsckapós uma queda de energia não seja concluída devido à falta de RAM, evitando assim que o sistema de arquivos seja remontado.

O sistema de arquivos mais capaz que vem integrado no SLES 9 éJFS. Seu limite de tamanho de volume está nopetabytes, portanto efetivamente ilimitado.

SLES 9 também suportaReiserFS, que tem um limite de tamanho de volume de 16 TiB. Esta é uma boa combinação para o seu sistema de 32 bits, pelos motivos de limite de RAM acima.

Também há um limite no número de /dev/sdcaminhos de dispositivos no kernel do Linux. Ele mudou algumas vezes ao longo da vida do Linux, em valores comuns de potência de 2. O limite para o SLES 9 é provavelmente de 256 volumes, com base nolimite documentadopara RHEL 3 e 4, que são aproximadamente contemporâneos do SLES 9.[3]

O limite de armazenamento é o limite de tamanho do volume vezes o número máximo de volumes. Meu número de 4 PiB acima é baseado em um tamanho de volume máximo de 16 TiB × 256 volumes.

Você não vai atingir o limite

É uma quantidade enorme de armazenamento, não importa como você o organize. O número real acaba não sendo muito importante por razões práticas. Simplesmente conectar discos suficientes a um único computador para atingir esse limite estimado será um grande desafio, especialmente considerando que os controladores de disco comuns compatíveis com o kernel 2.6.5 não suportamFormato Avançadodiscos, então você provavelmente não poderá usar discos maiores que 2 TB.

Isso significa que você precisa de milhares de discos físicos para atingir esse limite de 4 PiB.

Se você não atingir primeiro um limite de conectividade ou de tamanho de rack, encontrará algum outro limite prático antes de atingir o limite técnico absoluto.

Notas de rodapé:

PAEpermite até 64 GiB em um sistema de 32 bits, mas não sei se o kernel pode usar qualquer espaço além de 4 GiB para o cache do buffer.

Nenhuma fsckimplementação que eu conheça pode fazer uso do PAE, já que são necessários muitos truques especiais em aplicativos de espaço do usuário para fazer isso. Um número extremamente pequeno de programas fez uso real do PAE, nos últimos anos, quando era uma solução viável para o problema do limite de RAM. (Hoje, você usaria apenas um sistema operacional de 64 bits.)
A necessidade de RAM é função do número de arquivos e diretórios no disco e do número de acessos simultâneos que ele atende. A "regra de 1 GiB por TiB" é, portanto, uma espécie de regra de proxy.

Acredito que a única razão pela qual consegui 16 TiB em um kernel de 32 bits é que esses eram servidores de vídeo digital com poucos usuários simultâneos. Como os arquivos eram relativamente poucos e grandes, fscknão era necessário fazer malabarismos com um grande número de diretórios ou arquivosinodes, e não precisava manter muitas informações do sistema de arquivos na RAM para rastrear usuários simultâneos.

Um bom contraexemplo seria um servidor de e-mail, que pode servir milhares de usuários simultâneos, cada um querendo acesso a uma grande quantidade de arquivos pequenos, espalhados por milhares de diretórios.
Os kernels mais recentes aumentam o limite para 1.024, 4.096 ou 8.192 volumes.

Teoricamente, você pode chegar /dev/sdzzz....a 29 zs, o que equivale a aproximadamente 10 ⁴¹ volumes, mas outros limites práticos entrarão em ação primeiro.

Question 2

Não há limite para o meu conhecimento e se o limite existir você provavelmente não o alcançará. Depois de girar por todos os sd[az], as unidades serão rotuladas de sdaa a sdazz e assim por diante. Portanto, se houver um limite, é o número de unidades que o esquema pode rotular dentro do comprimento máximo do caminho do arquivo (os UUIDs podem mudar, não tenho certeza).

Isso cobre apenas IDE, SCSI, SATA e similares. Acredito que USB e outros terão limites diferentes.

Answer

Não há limite para o meu conhecimento e se o limite existir você provavelmente não o alcançará. Depois de girar por todos os sd[az], as unidades serão rotuladas de sdaa a sdazz e assim por diante. Portanto, se houver um limite, é o número de unidades que o esquema pode rotular dentro do comprimento máximo do caminho do arquivo (os UUIDs podem mudar, não tenho certeza).

Isso cobre apenas IDE, SCSI, SATA e similares. Acredito que USB e outros terão limites diferentes.

Quanto disco físico o SLES 9 pode suportar? Existem limitações?

Responder1

Suposição educada

Justificação

Você não vai atingir o limite

Responder2

informação relacionada