¿GPT o MBR?

Question

Soy nuevo en Linux. Estoy planeando instalar Squeeze en un disco duro de 2 TB de la siguiente manera:

• / - 10gb
• intercambio
• El espacio restante contendrá /home, alrededor de 1,9 TB, espero. Intentaré usarlo como lvm para agregar mi antiguo disco de 1 TB más adelante.

Mi pregunta es: ¿tengo que usar GPT? o MBR estará bien

Si GPT necesitara este esquema, ¿es bueno?

• /arranque - 150mb
• / - 10gb
• intercambio
• /home (lvm con espacio restante)

La placa base es una ASRock G41 por cierto que creo que no es compatible con EFI.

Answer 1

¿GPT o MBR?

Como dijo @mgorven, cualquiera de los dos funcionará con 2 TB. He implementado docenas de etiquetas de discos MBR en discos 2T y funciona bien en ellos. Realmente es tu elección. Por ahora prefiero MBR, pero esto está a punto de cambiar.

UEFI y GPT

No necesita UEFI para escribir una etiqueta de disco GPT en un disco y, si es inteligente, posiblemente podría iniciar un disco con una etiqueta de disco GPT desde una ROM que no sea UEFI (se requiere una pizca de sal; no lo he hecho). hecho esto). ElArtículo de Wikipedia sobre GPTtiene alguna información indirecta sobre esto.

Zonas

Esto es a menudo ignorado por la gente, perohacedesempeñar un papel, y potencialmente enorme. No es un problema en el almacenamiento masivo no giratorio, pero ha sido un problema con los discos durante muchos años. Por razones que tienen que ver con la geometría y la física, el rendimiento del disco es mayor cerca del comienzo del disco. El rendimiento se divide en zonas y la velocidad disminuye a medida que se pasa de una zona a otra. Esto implica que debe mantener las particiones que requieren mayor velocidad cerca del comienzo del disco. Esta diferencia es bastante pronunciada en los primeros gigabytes de un disco.

Partición de disco para Unix

Quieres tener muchos sistemas de archivos porque (entre otras cosas):

• No estás poniendo todos tus huevos en una sola canasta. Si un sistema de archivos se daña, lo restaura desde la copia de seguridad y la vida vuelve a la normalidad. Sitodode sus sistemas de archivos se dañan, hay más tiempo de inactividad, más problemas y usted se enoja más.
• Cada sistema de archivos se puede ajustar de forma diferente por motivos de rendimiento. El sistema de archivos donde almacena su MailDir puede tener cientos de miles de archivos pequeños en unos pocos directorios. El sistema de archivos donde guardas los archivos de vídeo tiene docenas de archivos enormes. Puedes optimizar.
• Puede reservar espacio en el sistema de archivos y permitir que un determinado usuario lo use cuando otros no pueden. Root suele reservar el 5% del espacio de un sistema de archivos. Con múltiples sistemas de archivos, puede modificar esto (por ejemplo, los sistemas de archivos de cola de correo pueden tener el espacio asignado al usuario de correo).
• Está simplificando su política de respaldo, haciendo que un sistema de archivos se ajuste a un medio de respaldo. Esto depende de su política y software de respaldo.
• Con sistemas de archivos separados, por ejemplo /home, puede tener múltiples sistemas operativos *nix en una computadora y compartir sus archivos entre ellos, sin tener que hacer piruetas.
• Puedes resolver las limitaciones del sistema. Por ejemplo, en el pasado, algunos discos no podían arrancar desde bloques de disco demasiado alejados del comienzo del disco, por lo que crearíamos un /bootsistema de archivos lo suficientemente pequeño como para ocupar los primeros bloques del disco.
• Puede optimizar la velocidad. Coloque los sistemas de archivos críticos en las zonas de disco más rápidas.
• Velocidad de arranque: fsckejecutar un sistema de archivos de 20G es más rápido que fsckejecutar un sistema de archivos de 1900G. La selección astuta de los períodos de control puede garantizar la distribución de las fscktiradas.

Quizás no quieras tener demasiados sistemas de archivos porque:

• Estás cuantificando el espacio en disco. Si necesita almacenar 100G en el disco, es posible que tenga 200G libres en total, pero ninguna partición con suficiente espacio libre en el disco.
• Está limitado por las capacidades de la etiqueta de su disco. Muchos Unices solo pueden contener 8 particiones/porciones en una etiqueta de disco, y una de ellas está reservada. MBR no está muy limitado a este respecto y GPT permitirá 128 particiones, que es mucho más de lo que necesita.
• Demasiados sistemas de archivos pueden ser una molestia para crear y administrar.
• Tus necesidades de almacenamiento de archivos no son tan variadas.

Esquemas del sistema de archivos

Cada uno tiene su favorito. Solía ​​​​tener una hoja de cálculo para calcularlos, pero la mayoría de las veces uso una hoja de papel y uno de esos instrumentos de escritura antiguos (qué pintoresco). Realizo varias iteraciones hasta que estoy satisfecho y envío el esquema de partición a la computadora. Es más rápido de esta manera. En la mayoría de los servidores basados ​​en Debian, mantengo separados los siguientes sistemas de archivos:

• /(raíz)
• /boot
• /usr
• /var
• /usr/local
• /tmp
• /home
• sistema de archivos de repuesto

Las necesidades adicionales obtienen otros sistemas de archivos separados, como una partición separada para mis fotos (la política de respaldo es diferente), una partición separada para videos, etc. Los servidores de correo obtendrían una partición separada para el correo electrónico. Los servidores de bases de datos obtendrían particiones separadas para sus almacenes de datos y archivos de respaldo de bases de datos consistentes en el disco, etc. Pero el esquema básico es casi siempre éste.

También mantengo un sistema de archivos de repuesto al final del disco. Lo uso mkfsy lo uso como espacio temporal, a menudo montado bajo /disk1(convención de trabajo) o /disk/tmp(mi convención). Este sistema de archivos es útil si descubro una nueva necesidad (puedo eliminarlo y hacer crecer otro sistema de archivos, o simplemente reutilizarlo), o si simplemente necesito mucho espacio disponible.

Dimensionamiento

Depende en gran medida de para qué se utilizará la computadora. Puedes salirte con tamaños realmente pequeños para muchas cosas. Mi sugerencia sería usar LVM (siga leyendo) y asignar 10G a cada uno /usry /var( /usr/localmás pequeño si no planea compilar e instalar su propio software). Sigo /tmpsiendo pequeño, tal vez 1 o 2 G. Sin tener todos los sistemas de archivos grandes en el sistema de archivos raíz, eso también puede ser más bien pequeño: mi caja actual tiene una partición 2G y queda mucho espacio. El /bootsistema de archivos puede ser muy pequeño si no eres un desarrollador del kernel, o quedar excluido por completo. Las computadoras recientes y las versiones recientes de GRUB pueden manejar eso perfectamente. Si lo quieres, unos 200-300 megas estarán bien.

LVM

No he implementado un sistema que no sea LVM en mucho tiempo. La flexibilidad que obtiene vale la pena la corta curva de aprendizaje. Con LVM, tienes mucha, mucha más libertad para cambiar de opinión y tus sistemas de archivos pueden crecer contigo. Realmente lo recomiendo.

Un esquema de ejemplo

• Partición 1: espacio de intercambio (comienzo del disco)
• Partición 2: Volumen físico LVM con un grupo de volúmenes llamado 'fs' o algo así.
  • Volumen fs-root: ~2G.
  • Volumen fs-usr: ~10G.
  • Volumen fs-var: ~10G.
  • Volumen fs-local(abreviatura de /usr/local): ~5–10G.
  • Volumen fs-tmp: ~2G.
  • Volumen fs-home: el espacio restante menos quizás ~30G.
  • Volumen fs-spare: espacio libre: ~30G.

En un disco de 2T con un espacio de intercambio de 8G, su /homepartición sería 2000 - 8 - 2 - 10 - 10 - 10 - 2 - 30 = 1928G.

La partición 30G de repuesto será útil si necesita más espacio para uno o más de sus otros volúmenes. Es bastante fácil cambiar el tamaño de los volúmenes LVM (y los sistemas de archivos ext{2,3,4}.

Tenga en cuenta que no hay ningún archivo separado /booty que toda su infraestructura de arranque (kernel y initrd) sonadentroel LVM. Esto incomoda a algunas personas, pero yo nunca he tenido problemas con eso. GRUB puede ver perfectamente el interior de los volúmenes físicos LVM. Si te incomoda, haz una separación /bootde unos 200M. Conviértalo en la partición 2 (haciendo que la partición LVM PV sea 3) o en la partición 1 (empujando hacia abajo las otras dos).

Answer 2

MBR debería funcionar bien en una unidad de 2 TB, pero no en nada más grande. Realmente no importa si usas MBR o GPT, siempre y cuando todos los sistemas operativos que quieras usar lo admitan. El BIOS no tiene que admitir EFI para arrancar desde una unidad GPT.

Independientemente de si usa MBR o GPT, recomendaría usar LVM para administrar el espacio, porque es mucho más flexible y más fácil de cambiar en una etapa posterior.

Answer 3

Creo que estás pensando demasiado en esto. GPT vs MBR realmente solo importa si tiene la intención de instalar múltiples sistemas operativos o mover la unidad a otra computadora. Si puede salirse con la suya con MBR, entonces también puede seguir con él, especialmente si está usando LVM (que permite muchas de las características que le faltan a MBR).

En cuanto al tamaño de las particiones, aquí hay algunas buenas reglas generales:

• Las particiones pequeñas pueden resultar molestas, ya que nunca se sabe de antemano cuánto se utilizará realmente.
• Las particiones grandes pueden resultar molestas porque lleva mucho tiempo construirlas y comprobarlas. Además, el "desgaste" de los sistemas de archivos tiende a acumularse según el uso. Poner todo en una partición significa que esta acumulación ocurre más rápido. Por lo que valga la pena.

Answer 4

Los sistemas de archivos que resultan ser demasiado pequeños suelen ser un drama. 10 GB se pueden llenar fácilmente con archivos binarios y de registro. Tienes una gran cantidad de espacio en disco, ¿por qué te esfuerzas tanto por ahorrar espacio? Te arrepentirás en un rato. No asigne espacio en disco todo a la vez, deje espacio para mover los sistemas de archivos cuando sea necesario. Extender un sistema de archivos es fácil, reducirlo no lo es. Vea lo que LVM2 puede hacer por usted.http://tldp.org/HOWTO/LVM-HOWTO/index.html No tomes malas decisiones que te encierren en los años venideros.