¿Cuánto disco físico puede manejar SLES 9? ¿Hay alguna limitación?

Question

Creo que existe una limitación en cuanto a cuántos discos puede manejar una máquina SLES 9. (32 bits). No puedo encontrar el número a través de Google.

Mi pregunta: ¿Alguien puede decirnos con referencia cuál es este número?

Answer 1

Estimación fundamentada

4pib.

Justificación

SLES 9 esalrededor de una década ahora, por lo que no admitirá sistemas de archivos tan grandes como las distribuciones modernas de Linux, ni tantos volúmenes como los kernels modernos. El kernel más reciente admitido en SLES 9 es 2.6.5.

También te estás limitando artificialmente al usar un sistema operativo de 32 bits: los sistemas de archivos más grandes requieren más RAM para administrar. Una regla general conservadora es 1GibraltarporTiB. Dado que Linux de 32 bits normalmente está limitado a 4 GiB[1], lo estás presionando para que use un Linux de 32 bits para administrar más de 4 TiB. Llegué hasta 16 TiB y me salí con la mía[2], pero en realidad no lo recomiendo. Una historia de terror común es que fsckdespués de un corte de energía no se complete debido a la falta de RAM, lo que impide que se vuelva a montar el sistema de archivos.

El sistema de archivos más capaz que viene integrado en SLES 9 esJFS. Su límite de tamaño de volumen ha aumentado en elpetabytes, por lo tanto efectivamente ilimitado.

SLES 9 también es compatibleReiserFS, que tiene un límite de tamaño de volumen de 16 TiB. Esta es una buena opción para su sistema de 32 bits, por las razones de límite de RAM mencionadas anteriormente.

También hay un límite en la cantidad de /dev/sdrutas de dispositivos en el kernel de Linux. Ha cambiado varias veces a lo largo de la vida de Linux, en valores comunes de potencia de 2. El límite para SLES 9 es probablemente 256 volúmenes, según ellímite documentadopara RHEL 3 y 4, que son aproximadamente contemporáneos de SLES 9.[3]

El límite de almacenamiento es el límite de tamaño del volumen multiplicado por el número máximo de volúmenes. Mi número de 4 PiB anterior se basa en un tamaño de volumen máximo de 16 TiB × 256 volúmenes.

No vas a llegar al límite

Eso es muchísimo espacio de almacenamiento, no importa cómo lo organices. El número real termina por no ser muy importante por razones prácticas. Simplemente conectar suficientes discos a una sola computadora para alcanzar este límite adivinado será todo un desafío, especialmente considerando que los controladores de disco comunes compatibles con el kernel 2.6.5 no son compatibles con los modernos.Formato avanzadodiscos, por lo que probablemente no pueda utilizar discos de más de 2 TB.

Eso significa que necesita miles de discos físicos para alcanzar este límite de 4 PiB.

Si no se topa primero con un límite de conectividad o de tamaño de rack, se encontrará con algún otro límite práctico antes de alcanzar el límite técnico absoluto.

---

Notas a pie de página:

1. PAEpermite hasta 64 GiB en un sistema de 32 bits, pero no sé si el kernel puede usar el espacio más allá de 4 GiB para el caché del búfer.

   Ninguna fsckimplementación que yo conozca puede hacer uso de PAE tampoco, ya que se necesitan muchos trucos especiales en las aplicaciones de espacio de usuario para hacerlo. Un número extremadamente pequeño de programas alguna vez hizo uso real de PAE, en los años pasados, cuando era una solución viable al problema del límite de RAM. (Hoy en día, solo usarías un sistema operativo de 64 bits).

2. La necesidad de RAM es función de la cantidad de archivos y directorios en el disco, y de la cantidad de accesos simultáneos que atiende. La "regla de 1 GiB por TiB" es, por tanto, una especie de regla de proxy.

   Creo que la única razón por la que me salí con la mía con 16 TiB en un kernel de 32 bits es que se trataba de servidores de vídeo digital con pocos usuarios simultáneos. Dado que los archivos eran relativamente pocos y grandes, fsckno era necesario hacer malabarismos con una gran cantidad de directorios o archivos.inodosy no necesitaba mantener mucha información del sistema de archivos en la RAM para realizar un seguimiento de los usuarios simultáneos.

   Un buen contraejemplo sería un servidor de correo electrónico, que puede servir a miles de usuarios simultáneos, cada uno de los cuales desea acceder a una gran cantidad de archivos pequeños, dispersos en miles de directorios.

3. Los núcleos más nuevos elevan el límite a 1.024, 4.096 u 8.192 volúmenes.

   Teóricamente, puedes llegar hasta /dev/sdzzz....29 zs, lo que equivale aproximadamente a 10 ⁴¹ volúmenes, pero primero entrarán en juego otros límites prácticos.

Answer 2

No hay límite para mi conocimiento y si el límite existe no es probable que lo alcances. Después de rotar todos los sd[az], las unidades se etiquetarán desde sdaa hasta sdazz y así sucesivamente. Entonces, si hay un límite, es la cantidad de unidades que el esquema puede etiquetar dentro de la longitud máxima de la ruta del archivo (los UUID pueden cambiar, no estoy seguro).

Eso sólo cubre IDE, SCSI, SATA y similares. Creo que USB y otros tendrán límites diferentes.