Véndeme particiones

A menudo me he preguntado por qué hay tanta pasión por particionar unidades, especialmente en sistemas operativos Unixy (/ usr, / var, et al). Esto no parece ser un tema común con las instalaciones de Windows.

Parece que la partición aumenta enormemente la probabilidad de llenar una partición mientras que otras tienen una gran cantidad de espacio libre. Obviamente, esto puede evitarse mediante un diseño y planificación cuidadosos, pero las cosas pueden cambiar. He experimentado esto en máquinas muchas veces, principalmente en las configuradas por otros, o por la configuración de instalación predeterminada del sistema operativo en cuestión.

Otro argumento que he escuchado es que simplifica la copia de seguridad. ¿Cómo simplifica la copia de seguridad? También he oído que mejora la fiabilidad. De nuevo, como?

Casi el 100% de los problemas que he encontrado con el almacenamiento en disco son fallas físicas del disco. ¿Se podría argumentar que la partición puede acelerar potencialmente la falla del hardware, debido a la agitación de un disco al mover o copiar datos de una partición a otra en el mismo disco?

No estoy tratando de mover el bote demasiado, solo me gustaría ver una justificación para una práctica administrativa antigua.

• Fsck más rápido. Digamos que su sistema falla, por alguna razón y cuando se reinicia necesita ejecutar un fsck. Con una partición realmente grande que fsck puede durar para siempre y nada en el sistema funcionará hasta que se complete el fsck de todo el sistema. Si particiona el sistema de modo que la partición raíz sea bastante pequeña, entonces puede ser capaz de activar el sistema y ejecutar algunos de los servicios básicos mientras espera que se complete el fsck de los volúmenes más grandes.
  • si su sistema tiene unidades pequeñas, o solo hay un servicio en el sistema, entonces esto puede no importar realmente.
  • Con los sistemas de archivos registrados, esto puede no importar la mayor parte del tiempo, pero ocasionalmente incluso con un sistema de archivos registrado tiene que ejecutar un fsck completo.
• Seguridad mejorada porque puede montar un fs de solo lectura.
  • Por ejemplo, nadie debería necesitar escribir / usr durante el uso normal. Entonces, ¿por qué no simplemente montar el sistema de archivos para que sea de solo lectura? Tener sistemas de archivos de solo lectura cuando no es necesario escribirlos evitará algunos ataques de script kiddy, y puede evitar que destruyas cosas cuando no quieres decir también.
  • Esto puede dificultar el mantenimiento del sistema, ya que necesitará volver a montarlo como lectura-escritura cuando necesite aplicar actualizaciones.
• Rendimiento mejorado, funcionalidad para un servicio / uso específico.
  • Algunos sistemas de archivos son más apropiados para servicios / aplicaciones específicos, o le permiten configurar el sistema de archivos para que funcione mejor en algunos casos. Quizás tenga un sistema de archivos con muchos archivos pequeños y necesite más inodos. O tal vez necesite almacenar grandes archivos de gran tamaño, imágenes de disco virtual.

No creo que configurar muchas particiones sea algo que deba hacer para cada sistema. Personalmente, en la mayoría de Linux mis servidores acabo de configurar una gran partición. Dado que la mayoría de mis sistemas tienen unidades más pequeñas y tienen un solo propósito y cumplen algún rol de infraestructura (dns, dhcp, firewall, enrutador, etc.). En mis servidores de archivos, configuro particiones para separar los datos del sistema.

¿Se podría argumentar que la partición puede acelerar potencialmente la falla del hardware, debido a la agitación de un disco al mover o copiar datos de una partición a otra en el mismo disco?

Dudo mucho que un sistema bien particionado tenga una mayor probabilidad de falla.

Una razón para mantener / home / seperate es que puede reinstalar el sistema operativo y nunca preocuparse por perder los datos del usuario. Más allá de eso, hay mucha seguridad para montar todo, ya sea solo lectura o no ejecución. Si los usuarios no pueden ejecutar código en cualquier lugar donde puedan escribir código, es un vector de ataque menos.

Sin embargo, solo me molestaría con eso en una máquina pública, ya que la desventaja de quedarse sin espacio en disco en una partición pero tenerla en otra es una molestia grave. Hay maneras de solucionar esto, como hacer una incursión de software o ZFS donde debería poder cambiar el tamaño dinámicamente de particiones fácilmente, pero no tengo experiencia con ellas.

• Simplificando la copia de seguridad

Puede hacer copias de seguridad (a través de dumpfs o similares) de las cosas que desea, no de las que no desea. dump (1) es un mejor sistema de respaldo que tar (1).

• Llenar particiones

Ese es un argumento para la partición también. Los usuarios que llenan sus homedirs no destruyen el servidor, eliminan el servidor web, evitan que se produzcan registros, evitan que el root inicie sesión, etc.

También le permite mover de manera más transparente una sección de sus datos (por ejemplo, / home) a otro disco: cópielo, móntelo. Si está utilizando algo que permite instantáneas / instantáneas / lo que sea, incluso puede hacerlo en vivo.

Siempre me han enseñado a mantener / var en una partición separada, por lo que si obtiene un archivo de registro fuera de control, obstruirá una sola partición, no toda la unidad. Si está en el mismo espacio que el resto del sistema y llena el disco al 100%, puede bloquearse y hacer una restauración desagradable.

Todos los argumentos que Zoredache presenta son válidos; uno podría discutir un poco los detalles (tener una máquina funcionando más rápido para que pueda hacer otras cosas mientras fsck'ing otros sistemas de archivos no le hace mucho bien si la razón del sistema para existir en primer lugar está en esos otros sistemas de archivos) ; sin embargo, todos son un poco de justificación después del hecho.

En los días de la vieja escuela, no tenía sistemas de archivos en particiones separadas, los tenía en discos separados, porque los discos eran realmente pequeños. Piense 10MB. (1) Entonces tenía una pequeña partición, un disco / var, un disco / usr, un disco / tmp y un disco / home. Si necesitabas más espacio, compraste otro disco.

Luego, los discos "grandes" de 50 MB comenzaron a costar menos que el programa lunar, y de repente se hizo posible colocar un sistema completo en un disco con una cantidad utilizable de espacio de usuario.

Aún así, dado que los tamaños de disco son pequeños en comparación con lo que era posible que la computadora generara, aislar / var y / opt y / home para que llenar uno no derribara la computadora seguía siendo una buena idea.

Hoy, en una situación empresarial, no particiono los sistemas operativos. Los datos se particionan, especialmente si son generados por el usuario; pero con frecuencia eso se debe a que está en discos de alta velocidad y / o redundantes de algún tipo. Sin embargo, / var y / usr viven en la misma partición que /.

En un entorno hogareño, lo mismo - / home probablemente debería estar en un disco / matriz separado, para que uno pueda instalar / actualizar / romper / arreglar los sabores del sistema operativo que desee.

La razón de esto es porque no importa cuán grande adivine su / var o / usr o cualquier árbol que pueda obtener, o estará muy equivocado o ridículamente se comprometerá en exceso. Uno de mis antiguos colegas de la escuela jura jurar por la partición, y siempre me da pena cuando termina sentado en un sistema de 180 días en un sistema que he creado. Pero puedo contar con una mano durante toda mi carrera la cantidad de veces que algo se llenó y derribó el sistema, mientras que puedo contar con una mano la cantidad de veces en lo que va del año que he estado mirando un sistema donde alguien decidió / var nunca tendría que ser más de (digamos) 1 GB y me equivoqué, dejándome mirando un / var completo y miles de GB gratis en cualquier otra parte del sistema, todo lo cual podría haber estado en la luna para todos Lo bueno que me hacen.

En el mundo actual de los discos grandes, no veo que haya ninguna razón real para particionar el árbol del sistema operativo. Datos del usuario, sí. ¿Pero particiones separadas para / var y / usr y / var / spool, etc., etc.? No.

(1) = y sé que solo al elegir ese tamaño, ¿voy a ver a alguien en los comentarios diciendo 10MB? Lujo. Por qué nuestros discos eran simplemente ...

En respuesta a :

Parece que la partición aumenta enormemente la probabilidad de llenar una partición mientras que otras tienen una gran cantidad de espacio libre.

En una máquina Linux, se usa LVM (gestión de volumen lógico) para evitar esto. La mayoría de los sistemas de archivos permiten cambiar el tamaño (algunos incluso en línea). Creo diferentes particiones para diferentes usos y las formateo en diferentes sistemas de archivos (es decir: xfs para archivos de descarga grandes que puedo eliminar rápidamente). ¿Necesito más espacio? Monte una nueva unidad, mueva los datos a ella, luego móntela donde solía estar la información. Es completamente transparente para usuarios y aplicaciones.

Con LVM, puede agregar discos o particiones en el grupo de volúmenes, luego crear volúmenes lógicos en ese grupo. Si deja espacio libre en el grupo de volúmenes, puede aumentar las particiones que se están llenando. Si el sistema de archivos lo admite (ext3, ext4, reiserfs), puede reducir una partición que haya sobreasignado.

Por ejemplo: hacer una partición de arranque en / dev / sda1 hacer una segunda partición (sin formato) / dev / sda2

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

Cuando necesite más espacio en / descargas (mientras el sistema de archivos está montado):

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

Y ahora tiene una partición de descarga de 150GB. Similar para el hogar. De hecho, acabo de cambiar el tamaño de una "partición" ext4 lvm hoy. Por otro lado, los volúmenes lógicos no son realmente particiones y lo que dices de que las particiones son del tamaño incorrecto concuerda con mi experiencia personal (más problemas de lo que valen).

El esquema tradicional de particionamiento de Unix es definitivamente una práctica de la vieja escuela que no es tan útil como lo era antes. En el pasado, cuando el tiempo de actividad del sistema Unix se midió en años, y tenía docenas de cientos de usuarios inmóviles con shells, montar / usr como solo lectura era una forma útil de proteger el sistema. Ahora, volver a montar los sistemas de archivos para parchar parece más laborioso y no tan útil.

En mi universidad, en los viejos tiempos, los clústeres de Unix tenían sistemas de archivos de solo lectura con las herramientas estándar de Unix, y las aplicaciones complementarias estaban en / usr / local, que era un NFS y más tarde un sistema de archivos AFS. Parte de eso era conveniencia ... ¿quién quería recompilar software en una docena de cajas en el clúster cuando podía ejecutar aplicaciones en una red de alta velocidad de 4Mb o 10Mb? Hoy en día, con gestores de paquetes decentes y muchos discos baratos, no es tan importante.

Creo que los procesos de pensamiento comenzaron a cambiar para mí en las cajas Sun con Veritas Volume Manager en 1999, lo que redujo considerablemente el umbral de dolor para mover discos.

Hoy, cuando pienso en particionar, pienso en términos de protección de datos y rendimiento. Ejemplo ilustrativo:

• El nivel 1 SAN es muy rápido, muy disponible (5 9's), replicado y muy costoso. Las bases de datos de misión crítica o los registros de transacciones viven allí.
• El nivel 2 SAN es rápido, disponible (4 9's), costoso. Las aplicaciones o los datos de menor prioridad viven aquí.
• El nivel 3 SAN está disponible (4 9's), barato. Las cosas que no son sensibles al rendimiento viven allí.

Estas consideraciones también se aplican a Windows. Tenemos un servidor SCCM que gestiona alrededor de 40k clientes. La base de datos y los registros están en un disco mega-buck IBM DS8000. Los paquetes de software están en un Celerra de EMC con discos SATA grandes y lentos que cuestan un 60% menos por GB.

Entiendo que esta pregunta no es específica del sistema operativo, ¿verdad?

En Windows, tiendo a dar a todas mis máquinas la menor cantidad de particiones posible, pero no menos de dos: SISTEMA y DATOS. Si la máquina tiene dos discos físicos, uno (más pequeño) será SYSTEM, el otro DATA. Si solo hay un disco, lo divido en dos particiones.

La razón de esto es solo una: cuando necesito reinstalar la máquina (y habrá un momento así), no tengo que preocuparme por el contenido de la partición del SISTEMA: solo hago un formato completo y un Instalación limpia. Esto, por supuesto, significa que mis Documentos (y preferiblemente también el Escritorio) deben asignarse a una carpeta en DATA, pero eso es fácil de hacer, especialmente en Vista y versiones posteriores.

También intenté hacer más particiones (como JUEGOS, MÚSICA, PELÍCULAS, etc.) pero eso solo resultó en que algunos de ellos se desbordaran en otros, creando más desorden que orden.

(Suponiendo que haya un solo disco grande disponible), puse homey varparticioné por separado para controlar el problema "fuera de control [usuario | archivo de registro] llenando todo el espacio", y para permitir actualizaciones fáciles del sistema operativo sin tocar el hogar, pero dejo el descansar juntos

En hardware antiguo, en algún momento era necesario tener una bootpartición separada para asegurar que la imagen del núcleo fuera accesible para el cargador de arranque.

Usted menciona que un disco se llena mientras que el otro tiene espacio libre, esa es una de las razones por las que particiono, porque puedo asegurarme de que ciertas particiones no se llenen. Aunque, como solían administrarse las cuotas, tendría que asignar a todos los usuarios una cuota 0 en las otras particiones, solo para asegurarse de que no comenzaran a ocultar archivos si lograban encontrar un directorio que podría escribir a

En cuanto a simplificar la copia de seguridad: si sé cuál será el tamaño máximo de cada partición, puedo asegurarme de que sea un tamaño que se ajuste perfectamente a una sola cinta y que se pueda completar en un período de tiempo fijo.

En cuanto a la confiabilidad, lo único en lo que puedo pensar es en el monitoreo: puedo ver más fácilmente cuándo una partición determinada está creciendo más de lo que debería, y me da razones para investigarla.

... ahora, dicho todo esto, estamos lejos de los días en que cada usuario recibe su pequeña cuota de 20 MB en una máquina compartida. Algunos de los viejos hábitos no tienen sentido, pero cuando tienes un proceso enloquece y llena / var, que a su vez se llena / y las cosas se detienen, no es tan malo tener protección en las máquinas de producción .

Para el hogar, tengo particiones, pero es solo para facilitar la administración de los sistemas operativos instalados.

Personalmente solo uso particiones en las computadoras de mis hijos. Creo una partición grande para el sistema operativo y una pequeña para una imagen de la partición del sistema operativo, de modo que cuando la máquina se dispare, pueda restaurarla rápidamente desde la imagen.

En un entorno empresarial, nunca he escuchado un argumento convincente para la partición.

Todo con moderación es algo bueno: puede ser una buena herramienta para aislar problemas cuando hay una falla, como el llenado del disco o la corrupción del sistema de archivos.

No lo mezcle con fallas de hardware; estas deben manejarse mediante redundancia de hardware (RAID)

Dicho esto, los sistemas de archivos en la actualidad fallan con menos frecuencia, incluso hacen verificaciones de integridad en línea (como ZFS). Esperemos que fsck fuera de línea desaparezca en algún momento ...

Por otro lado, hacer esto en exceso solo significa más trabajo (para usted y su equipo) al final, solo hágalo con moderación y cuando tenga sentido ...