Cómo distribuir el disco estratégicamente v2019

[karlggest]

Allá por 2011 escribí un pequeño artículo con el pretencioso nombre: "Cómo distribuir el disco estratégicamente", que pretendía poner énfasis en que se puede adaptar con relativa facilidad el reparto del espacio disponible en nuestros discos duros. Eso fue en 2011.

Pronto openSUSE (y SUSE detrás) adoptó btrfs como sistema de ficheros por defecto para la raíz. Entonces cambiaron un montón de cosas, dado que el sistema de fichero era bastante nuevo y tenía muchas limitaciones que se acababan convirtiendo en problemas. Uno no menor era la imposibilidad de determinar el espacio libre existente realmente en nuestra partición raíz.

También bajaron de precio sustancialmente los discos SSD, pero no lo suficiente como para competir con los HDD; esto hace que cada vez sea más habitual enfoques mixtos, con un SSD para el sistema y un HDD para nuestros datos y ficheros. La generalización de redes de conexión a InterNET de muy alta capacidad y de dispositivos móviles (tablets, smartphones, androidTV, etc.) nos ha empujado hacia el streaming, reduciendo notablemente nuestra demanda de espacio para ficheros multimedia, aunque al mismo tiempo consideraciones de privacidad y seguridad nos empujan a crear nubes domésticas o profesionales.

El objetivo de este documento no es dar respuestas a todas estas circunstancias, sino simplemente modernizar el artículo anterior para que sea útil en 2019. Al menos, hasta nueva orden.

En el hilo Cuestiones de Cómo distribuir el disco estratégicamente v2019 podéis añadir preguntas, dudas, críticas o cualquier cuestión respecto a este tutorial.

índice
0. El problema del espacio.
1. Estableciendo el uso.
2. La memoria y la swap

2.1 Añadir swap
2.2 ¿y usar varias swap?

3. Dividir el disco

3.1 Particiones: cuestiones generales
3.2 Volúmenes: cuestiones generales
3.3 Convivir con el enemigo: NTFS
3.4 Ejemplo práctico I: basado en particiones

3.4.1 De cuando el espacio está ocupado
3.4.2 De cuando el disco está vacio
3.4.3 ¿Particiones extendidas, primarias o lógicas?
3.4.4 tipos de Particionado
3.4.5 Particiones EFI
3.4.6 ext4, btrfs, zfs...?

3.5 Ejemplo práctico I: Multivolumen btrfs

3.5.1 Descripción del ejemplo
3.5.2 Implementación
Ventajas e Inconvenientes

4. Criptografía
5. Ejemplo práctico III: sistema con raíz cifrada

5.1 Antecedentes
5.2 Particionando el disco
5.3 Creando las particiones
5.4 Creando el volumen
5.5 Creando los volúmenes lógicos

6. La necesidad de crecer

6.1 Modificar particiones
6.2 Sistemas de Archivos
6.3 Sobre el Montaje de Dispositivos

6.3.1 Nombres de dispositivos
6.3.2 udev: añadiendo dinamismo
6.3.3 Y más allá...

6.4 El problema de añadir espacio
6.5 fdisk: introducción
6.6 Ejemplo Práctico IV: añadir espacio con una partición

(en curso)

[karlggest]

Axioma 1: todo espacio de disco tiende a llenarse; toda memoria libre tiende a llenarse.

Quizás lo primero que deberíamos hacer es establecer es un hecho: las preguntas que se hacen en relación al espacio que debe destinarse a cada partición en una instalación GNU/Linux es incompleta. Debería ser algo como: "para un uso determinado, ¿cuál es el modo de particionado más eficiente?". Así podemos enfrentar el problema más directamente. Empezaremos por cuestionarnos los usos y hábitos de los sistemas GNU/Linux, y en otra sección trataremos ampliamente la cuestión de la eficiencia y de qué estrategias podemos valernos.

En el documento usaré varios conceptos que he descrito en algunos temas que se pueden consultar en el foro, o en otros manuales, la wikipedia, etc. Llamaré la atención sobre varios:

* espacio de disco: es la cantidad de espacio que un disco, habitualmente un disco duro, tiene disponible para el sistema. Esta cantidad depende de la organización física del propio disco duro, pero también del tipo sistema de archivos que se utilice. A mayores, la creación de particiones lógicas también consume espacio, ya que en algún lado debe guardarse dicho particionado(1). Hay otras consideraciones menores que pueden observarse en algún documento técnico. En la wikipedia podéis ver informaciones sobre el funcionamiento y los diferentes tipos de discos duros. Los HDD son dispositivos mecánicos que constan de varios discos que van rotando mientras que los SSD son discos sólidos que no se mueven.

* sistema de ficheros: organización jerárquica de la información en un sistema operativo. En los sistemas "Unix-like" hay una raíz de la que cuelgan diversas carpetas, entre ellas /home, /usr, etc., que a su vez contienen otras o archivos, y así sucesivamente formando una especie de árbol invertido. Podemos pensar que cada sistema de ficheros se corresponde con las ramas principales del sistema, y muchos de ellos no tienen siquiera por qué estar en el mismo dispositivo. De hecho, lo usual es tener al menos dos sistemas de ficheros en dispositivos separados: / y /home (habitualmente para un usuario doméstico esto significa que están en particiones distintas dentro del mismo disco duro)

* sistema de archivos: organización de los diversos archivos que componen el sistema, incluida su localización, posibles propiedades o permisos, etc. Para evitar ambigüedades, suelo hablar de tipo de sistema de archivos. Los más usuales son ext4, xfs y btrfs, junto con NTFS que se utiliza en sistemas Windows. Hace años diversos fabricantes nos devolvieron a la pesadilla de convivir con FAT (vfat), que hoy suele utilizarse en pendrives, cámaras digitales, etc. aunque hoy ya se utilizan otros sistemas como NFTS.

* tabla de particiones: fichero que contiene una tabla con el particionado del disco. En los PC tenemos dos tipos de tablas de particiones: el viejo estilo, a veces llamado "tabla de particiones MS-DOS" por haber sido popularizado por ese sistema operativo. Contiene un máximo de 4 particiones primarias, aunque es posible definir una de ellas como de "tipo extendido", lo cual nos permite crear varias particiones dentro de ella llamadas "lógicas"; y el sistema moderno llamado GPT, que permite disponer muchas particiones primarias.

(1) En el sistema tradicional de ficheros MS-DOS la tabla de particiones consta de 4 registros con unos pocos campos. En cada registro se guarda una de las particiones existentes y eso nos da un máximo de cuatro particiones. El sistema tradicional permite usar un tipo de partición especial denominado "extendida". En este tipo de partición, dentro de ella se pueden hacer divisiones similares a las particiones (llamadas particiones lógicas). Como la partición extendida se guarda en un registro que solo tiene sitio para almacenar dónde empieza y dónde acaba, la localización física de las particiones lógicas debe de guardarse dentro de la partición extendida.

[karlggest]

Axioma 2: Si todo lo que tienes en la mano es un martillo, cualquier cosa que veas parecerá un clavo.

Todos comenzamos nuestra singladura en un sistema nuevo asumiendo que nuestras necesidades son más o menos las mismas que las de todos los demás; si acaso, podemos pretender que, puesto que somos nuevos, quizás tengamos más dificultades para comprender ciertas cosas que usuarios más veteranos den por sentadas, y casi con total seguridad pretendamos consejos claros y concretos.

Generalmente, tales usuarios más veteranos nos dirán que la mejor configuración de nuestro sistema dependerá del uso que le vayamos a dar. Es posible que en algunos foros quien escribe eso tenga una experiencia fructífera con un viejo Pentium en el que usa vim para desarrollar aplicaciones, tiene un gestor de correos, quizás un navegador y poco más. O puede que nos lo diga alguien que dispone de un potente equipo para disfrutar de los últimos juegos ¡no olvides una buena gráfica!!, pareciera gritar aun cuando no lo ponga por escrito.

Y es que necesitamos tener una idea de qué vamos a hacer con nuestro equipo antes de buscar una receta para usar. Un usuario de aplicaciones CAD puede necesitar mucho espacio para ellas; un usuario que simplemente se conecte a internet -si acaso, LibreOffice para los adjuntos que nos mandan por correo- puede arreglárselas con 1 GiB. De forma similar, resolver ecuaciones diferenciales o compilar puede exigir cantidades ingentes de memoria, que puede que sólo podamos alcanzar mediante una buena swap; sin embargo, las aplicaciones precisas para hacer esos cálculos necesitarían muy poco espacio!!

Es buena idea dedicar unos minutos a pensar en qué aplicaciones se quiere usar, o al menos en qué tipos: suites ofimáticas, navegadores, aplicaciones multimedia. Esta reflexión nos puede indicar no sólo una idea del espacio necesario para instalar lo que necesitamos, sinó también cuánta memoria necesitamos y como combinar RAM y swap para cubrir nuestras necesidades.

Importante!!! tanto para el espacio de disco como para el de RAM, poco espacio libre puede ralentizar el sistema, y quedarse sin él significa que el sistema caerá.

Aquí algunos ejemplos del espacio de disco ocupado por algunas aplicaciones, teniendo en cuenta que puede variar entre versiones. Hay que tener en cuenta que sólo se hace referencia a los paquetes que componen tal aplicación: muchas librerías compartidas podrían ser necesarias y habría que sumarlas. Por ejemplo, para usar kcalc al menos hay que tener QT y ciertas librerías de KDE, y, naturalmente, algún sistema gráfico.

Téngase también en cuenta que en total una instalación estándar, esto es, después de concluir la instalación, debería ocupar unos 4,5 GiB. Con códecs multimedia y los pequeños ajustes típicos, debería sumar menos de, aproximadamente, 5 GiB.

En la sección 3 añadiré un inciso sobre los archivos temporales. El ejemplo más obvio es copiar un CD para grabarlo en otro usando la misma grabadora. En este caso, necesitaremos alberbar la imagen temporal del CD en algún lugar. Más obvia se hará esta necesidad si pensamos que pueda que queramos probar que el CD ha sido grabado correctamente, o si por cualquier motivo queremos hacer más copias del CD. También es preciso disponer espacio para modificar archivos de configuración, naturalmente. Si tienes el 100% de la raíz ocupada, no podrás, por ejemplo, añadir una línea a un archivo de configuración que necesites modificar. La conclusión de esto es que necesitas tener disponible el espacio que ocupan físicamente las aplicaciones y el espacio necesario para que funcionen.

En cuanto al espacio necesario en RAM, puede ser muy variable en función del uso. Por ejemplo, mientras escribía esto mismo en 2011 mi Firefox hacía uso de unos 100 MiB; hoy me requiere unos 700 MiB. Sin embargo, si abres unos cuantos vídeos en distintas pestañas, puedes necesitar 1GiB e incluso más, en función del tamaño de cada vídeo. Calcular la cantidad de memoria adecuada para un sistema dado es algo que cuesta aún cuando se tenga mucha experiencia en dicho sistema.

[karlggest]

Axioma 3: No sirve de nada usar una agenda para acordarse de las cosas, si después no recuerdas que usas una agenda para recordar las cosas.

La memoria es uno de los elementos más importantes de un sistema, ya que afecta directamente al rendimiento del equipo. A modo de ejemplo, puedes pensar que una memoria RAM es 100 veces más rápida que un disco duro. Un vistazo a la wikipedia puede dotarte de contexto(1)

En rigor, un sistema operativo trata con procesos(2). Un proceso no es más que una colección de instrucciones que forma parte de un programa y una información accesoria para que el sistema operativo de turno sepa qué hacer con él. Entre esa información, figura la localización en memoria de los datos con los que deba de trabajar. Otra información puede ser por ejemplo el usuario de dicho proceso, la lista de recursos que necesita, etc.

La Memoria Virtual es un mecanismo que permite extender la memoria principal (RAM) de un computador. En el hilo Micro Manual de Linux I: gestión de memoria en Linux se describen brevemente los principales aspectos del uso de memoria principal. A efectos de este documento, lo importante es el concepto de swap como un espacio de disco utilizado para extender la memoria principal del sistema y que el computador debe disponer de una memoria total suficiente para ejecutar los procesos que necesite ejecutar, disponiendo de los datos que necesiten tales procesos en la propia memoria. El funcionamiento se puede describir así:

1. el sistema operativo carga en memoria el proceso a ejecutar.
2. cuando le corresponde ejecutarse, el proceso busca los datos en memoria.
3. si encuentra los datos, se ejecuta el proceso.
4. si no encuentra los datos en memoria, los busca en la memoria virtual.
5. si hay espacio en memoria, se cargan los datos y se ejecuta el punto 3.
6. si no hay espacio en memoria, el sistema operativo debe de descargar algún proceso para hacer sitio.
7. si consigue espacio suficiente, ejecuta el punto 3.
8. si no consigue hacer espacio, falla.

En este octavo punto, lo más habitual es que se pare el sistema. Así que tener RAM suficiente para ejecutar todos los procesos que deban ser ejecutados en cada momento dado es importante, como también lo es tener swap suficiente para poder mover los procesos entre RAM y disco cuando sea necesario: el sistema busca en memoria o en swap; si no tiene espacio en ninguno de los dos para cargar un proceso o sus datos, fallará igualmente.

Esta cuestión es, como se ve, tan importante que han corrido ríos de tinta sobre ella. GNU/Linux, sin embargo, proporciona a los usuarios experimentados recursos que pueden facilitar en gran medida la gestión de su sistema. En particular, puedes crear swaps en caliente y añadirlas al sistema cuando se requiera.

Esto no es mucho consuelo para un usuario sin experiencia en GNU/Linux, ya que sólo desplaza la cuestión. Uno podría, legítimamente, pensar "¿y cómo demonios sé yo cuándo necesito más swap?" Esto tiene una respuesta fácil que en principio puede no ser del agrado de tal usuario: experiencia.

¿Cómo se consigue experiencia? En este caso, lo suyo es disponer de memoria swap suficiente y monitorizar su uso de vez en cuando. Cuando ya llevamos unos meses trabajando con el sistema y tenemos una idea bien clara del uso que le damos, podremos hacer una estimación de nuestras necesidades.

Por ejemplo, si renderizamos una escena 3D o resolvemos ecuaciones complejas, o compilamos aplicaciones un poco grandes, con toda probabilidad necesitaremos bastante swap en dichos momentos. Así que, mientras hacemos dichas tareas, podemos observar el consumo de recursos (memoria y swap) e ir estableciendo unos límites. Por supuesto, la swap no sustituye a la RAM: si el uso de la swap es muy continuado y elevado, lo que necesitamos es aumentar la RAM disponible.

Hay muchas sugerencias para tratar de encontrar un buen tamaño para una swap al primer intento. Por ejemplo, la documentación de Red Hat de 2011 para rhel indicaba:

hasta 4 GB - al menos 2 GB
4 hasta 16 - al menos 4 GB
16 hasta 64 - al menos 8 GB
64 hasta 256 - al menos 16 GB

Pero no os dejéis llevar por los números, sean estas u otras recomendaciones. Yo en 2011 tenía un equipo con 1 GB RAM y una swap de 1,5... y la swap raramente llegaba al 15%... ¡lo que necesitaba realmente, para que fuera más rápido, era más RAM!!!!!(3) Hoy los equipos más habituales a la venta tienen un mínimo de 8 GiB que para la mayoría de usuarios serán suficientes y no requieren usar swap.


No puedo menos que recalcar que el término memoria virtual a veces es un pelín engañoso: la swap no actúa como una extensión de la memoria principal, como se dice en muchos lugares; en su lugar, la swap es más bien una suerte de "memoria intermedia". El procesador no puede, en ningún caso, acceder directamente a la swap: lo que necesite utilizarse, ha de ser copiado necesariamente a la memoria principal. En la swap se guardan, eso sí, los procesos y datos ya de la misma forma que estarían almacenados en memoria. Esto significa que usar swap en GNU/Linux significa intercambiar páginas entre la memoria principal y la memoria virtual, donde cada página contiene un proceso o una parte de él.

(1) https://es.wikipedia.org/wiki/Memori...m%C3%A1tica%29
(2) https://es.wikipedia.org/wiki/Proces...m%C3%A1tica%29
(3) A menos que necesites hibernar el sistema, que por definición se hará en la partición swap y habrá entonces de contener al menos todo el contenido de la memoria RAM.

[karlggest]

Si necesitamos incrementar la swap disponible de forma muy puntual, lo sensato es añadir un dispositivo swap en ese momento en lugar de tener una swap de tamaño mucho mayor del necesario. Crear una swap es sencillo. En openSUSE puedes usar el gestor de particiones de YAST, o cualquier otro gestor de particiones al uso. También puedes usar la línea de comandos para esto.

En la web podemos encontrar cómo se hace esto con comandos. Hay dos casos posibles: usar partición o usar un archivo de intercambio.

En esta web, por ejemplo se explica cómo se hace. En esta web se explica cómo se crean con ánimo de mantenerlas en el sistema. Naturalmente, si lo que pretendemos es, como dije más arriba, usarla puntualmente, lo que tenemos que hacer es no añadir la línea en /etc/fstab para que se monte en el arranque (punto 5).

¿Y si no necesitamos ya esa swap? para desmontarla, basta con usar el comando swapoff. Siguiendo el ejemplo de dicha web:

swapoff /tmp/swap

La partición swap es siempre preferible al archivo swap, pero tiene el lógico inconveniente de que necesitas tener espacio para crearla; el archivo, sin embargo, puedes crearlo en cualquier punto del sistema de ficheros. GNU/Linux por defecto usa partición, mientras que Windows por defecto usa archivo, si bien ambos sistemas pueden utilizar ambas técnicas.

[karlggest]

Hay varios motivos para usar varias swap, además del caso de necesitar añadir una swap de forma puntual:

1. Disponer de varios discos duros: es posible que sea más eficiente tener los distintos sistemas de ficheros repartidos por todos los discos, ya que el tiempo medio para encontrar algo en varios discos es menor que en uno, ya que puedes hacer varias cosas a la vez en lugar de hacerlas de una en una. El rendimiento real de hacer esto es cierto que es discutible.

2. Si tenemos un sistema basado en particiones, es posible que queramos usar dos swaps. Si tengo 3 GiB de RAM, por ejemplo, puedo crear una swap de 1,5 GiB por un lado y otra de 1,5 GiB al final del disco. Si, efectivamente, con el tiempo observo que es suficiente con la primera, será sencillo eliminar la última y extender la partición anterior para aprovechar ese espacio.

[karlggest]

Axioma 4: No es buena idea mezclar tocino y velocidad.

La mayoría de los sistemas domésticos dividen el disco destinado a GNU/Linux en tres partes: una raíz (núcleo, aplicaciones y demás), una swap y una parte para los datos de los usuarios. Algunos instaladores de algunas distribuciones incluso pueden no preguntar e instalarse en el primer hueco, mientras que la mayoría de ellos permitirán optar entre hacer un diseño a medida o permitir que el instalador haga una sugerencia, por ejemplo aplicando reglas como el Principio de Pareto (conocida como regla 80/20) u otras reglas similares.

La razón para esta división es bien simple.

• no es demasiado complicada: es sencillo indicarle al instalador que trate de garantizar que el espacio para la raíz será suficiente para contener todos los paquetes instalados, y a partir de ahí aplicar la regla 80/20, por ejemplo, para distribuir la raíz y /home, y para la swap es sencillo aplicar reglas tales como "hasta 4GiB, el doble de RAM y nunca más de 2 GiB de swap; para más de 4 GiB de RAM, para cada GiB de más a la swap le sumamos 1".
• es bastante útil: mantener /home separado permite utilizar la misma partición para otros sistemas GNU/Linux que tengamos instalados, permite que la reinstalación del sistema no afecte a nuestros datos y configuraciones personales, etc.

No es la mejor configuración del sistema posible, pero es lo bastante simple para ser la más adecuada en la mayoría de casos. Añadir más particiones implica un mayor desperdicio de espacio, además de ser más laborioso estimar cuánto ha de destinarse a cada una; usar menos particiones tiene las desventajas de que si reinstalamos el sistema perderemos nuestros datos (o no podremos compartir /home con otros sistemas), y no usar swap tiene el problema de que nuestra RAM puede no ser suficiente en momentos puntuales.

He dicho que tal configuración no era necesariamente la mejor configuración posible, así que tratemos de profundizar más en la jerarquía de ficheros de GNU/Linux(1).

¡Aviso!!!!: ¡la inmensa mayoría de usuarios domésticos GNU/Linux son bastante felices ignorando esta cuestión!!!

Muchos sistemas de ficheros (/home, /var, /usr, /tmp, /boot,...) pueden estar situados en dispositivos distintos de la raíz, incluso en discos externos o remotos. Otros sistemas de ficheros, de hecho, ya lo están por su naturaleza: /srv o /proc, por poner dos ejemplos muy distintos.

Un sistema de ficheros que puede ser útil que esté separado de los demás es /opt. En dicho sistema de ficheros se deben de alojar las aplicaciones de terceros. Razones históricas hacen que por ejemplo KDE 3 se instalase ahí bajo openSUSE. En una instalación estándar es posible, pero no necesario, que /opt aloje algún software.

Igual que en la sección anterior cuando mencionaba el uso de dos swaps, si tenemos una partición /opt que al final no usamos podremos reintegrarla al sistema con facilidad. Otra razón, mucho más importante, es que mucho de ese software podemos haberlo descargado ya en formato binario en lugar de instalarlo desde algún paquete: en caso de reinstalar el sistema, o de que instalemos otro GNU/Linux, podremos montar (sin formatear) /opt en el sistema conservando las aplicaciones que allí tengamos. Aunque, para esto, hay que cerciorarse de que el sistema no haya instalado nada allí, por ejemplo, alguna aplicación del mentado KDE 3.

En redes de computadores es útil que /usr y /usr/local estén en dispositivos distintos: así, /usr estará disponible para todas las máquinas de la red, mientras que /usr/local solo lo estaría para la propia máquina. También en redes de computadores es posible que no queramos tener un /home separado, ya que el administrador de la red puede proveernos de acceso mediante LDAP o esquemas parecidos. El resultado en la práctica es que /home se monta por nfs en otro disco de otra máquina para tener centralizadas las carpetas de los distintos usuarios en un mismo lugar, permitiendo que cualquier usuario del sistema se conecte desde cualquier máquina.

Un caso especial es /boot. Hoy no existen muchos motivos interesantes para montar una partición específica para /boot, pero lo cierto es que hay varias situaciones donde es imprescindible. La primera de ellas es cuando se quiere cifrar la raíz: grub necesita cargar el kernel en una partición no cifrada; otra razón relacionada es que se quiera disponer de /boot en un dispositivo distinto para evitar que alguien pueda arrancar nuestra máquina en caso de robo o estravío... particularmente en casos donde pueda haber espionaje industrial; otra razón para separar /boot, y quizás más importante que las anteriores, es la limitación impuesta por la BIOS de algunas máquinas de hace algunos años, donde el sistema no puede estar instalado más allá de un límite; para resolver esto, basta con crear una partición /boot en algún lugar del principio del disco, dentro de esos límites.

/var es un sistema de ficheros muy importante en servidores. Allí se almacenan los registros -sobre todo de error-, las bases de datos, la cola de impresora... He visto algunos problemas de espacio sufridos por usuario que de repente se encontraban con que determinada aplicación generaba unos registros enormes que no borraba con la suficiente frecuencia, consumiendo muuucho espacio.

Hace años, en el laboratorio de libre acceso de una Escuela Universitaria de Informática uno de los administradores tuvo la brillante idea de añadir cuotas de disco para los usuarios, lo cual es una buena cosa, en principio... y es que tiene el mismo problema que la estimación de espacio para aplicaciones: ¿cuál es el espacio mínimo? ¿cuál es la probabilidad de que algún usuario legítimamente necesite más, y qué puede hacerse para garantizarse? Desde luego, estimar necesidades exageradas para todos los usuarios no tiene sentido: para eso es más eficiente no poner cuotas.

Bien, nuestro querido administrador escogió la política del "espacio medio". Así, si tenemos unos cuantos documentos de procesador de textos, algo de código fuente y un par de hojas de cálculo, nuestro espacio puede medirse en varios MiB. Así, el administrador puso una cuota de unos cuantos MiB para todos los usuarios para todo el uso del sistema. Quiero decir, la cuota afectaba al espacio que el usuario podía usar en total en el sistema, no sólo era un límite de disco disponible.

Las matemáticas son inflexibles. Quizás por eso algunos las odien, pues desnuda las carencias de nuestro pensamiento. Cuando quieres imprimir un trabajo de un procesador de textos como el MS-Word, necesitas varios MiB para que el sistema pueda generar las páginas que finalmente serán enviadas a impresión. Si tienes 4 MiB de cuota, y 2 están ocupados por archivos, sólo podrás usar 2 para la cola de impresión!!! Esto, para una impresora láser, no es mucho precisamente. En el caso de esa aula, la impresión estaba limitada a unas 4 o 5 páginas cada vez.

GNU/Linux tiene la cola de impresión en /var. Si imprimimos muchos documentos muy grandes debemos asegurarnos de que /var tiene el suficiente espacio libre mientras sea necesaria la cola. Por supuesto, toda vez que la impresión finalice no será necesario dicho espacio.

Hay múltiples ejemplos del uso de cachés por determinados programas. Por ejemplo, Firefox guarda los vídeos que carga en una caché y k3b puede grabar CD/DVD guardar imágenes -por ejemplo, si usamos el mismo dispositivo para leer el DVD que queremos copiar que para grabarlo. Muchos programas permiten configurar donde se van a establecer estas cachés y en algunos casos se tiende a hacerlas en alguna carpeta de /home (el mentado Firefox tiene una carpeta específica para cachés en su carpeta de usuario (.mozilla/firefox/PERFIL/Cache). Es posible que para aprovechar más el espacio deban de revisarse algunas carpetas temporales o carpetas de cachés. /tmp es quizás el ejemplo más habitual.

Hay varias ventajas más en aumentar el grado de división del disco, pero lo cierto es que la mayoría de usuarios no encontarán diferencias apreciables que compensen la laboriosidad de crear un esquema de ese tipo.

(1) http://es.wikipedia.org/wiki/Jerarqu...ma_de_Ficheros
http://www.forosuse.org/forosuse/sho...stema+ficheros, sección 3.1

[karlggest]

Cada cosa en su sitio, y Linux en todo.

Grosso modo, una partición de disco es una división lógica dentro del mismo. Surgen por la necesidad de poder acceder a todo el contenido de un disco duro cuando estos se hacen más grandes que lo que sistemas operativos y computadores anteriores podían manejar. Pronto se aprovechó para adaptar el uso de particiones al sistema de ficheros de Unix, consiguiendo un uso de las particiones coherente: tanto /boot como /, /usr, /usr/local, /tmp, /var, /var/spool y /home se montan en particiones diferentes.

GNU/Linux fue diseñado bajo MS-DOS y por tanto está diseñado para ser compatible con MS-DOS y sus derivados. A la sazón, al tipo de tabla de particiones que usan los discos duros bajo GNU/Linux se le llama "de tipo MS-DOS".

tabla de particiones: en los PC/compatibles, es un espacio reservado al principio del disco donde se indica la situación física de hasta 4 particiones (llamadas primarias).

MBR (Master Boot Record): primer sector del disco que contiene el código del cargador de arranque y la tabla de particiones anterior de 4 entradas.

Para superar las limitaciones de esta tabla de 4 entradas, la "tabla de particiones tipo MS-DOS" permite que una de las entradas establezca los límites de lo que llama una partición extendida. En esta idea, tal partición contiene información de dónde empieza la partición lógica, la cual a su vez contiene la información de la siguiente, etc. Para diferenciar, se hace referenca a éstas como lógicas, frente a las primarias ya mencionadas.

Modernamente puede hacerse uso de un esquema de particionado alternativo: GPT (GUID Partition Table). A diferencia del sistema MS-DOS, GPT no distingue tipos de particiones: todas son particiones primarias.

Cuando adquieres un portátil más o menos moderno vendrá con una BIOS/UEFI moderna. Estos sistemas hacen uso de un tipo de particiones especiales para arrancar, en lugar del MBR como en el particionado tradicional a lo MS-DOS. Estas particiones se denominan "de tipo EFI". Es común confundir ambas cosas y mezclar un poco los conceptos de EFI y GPT. Lo cierto es que muchas BIOS de más de 10 años soportan el sistema de particionado GPT. Así que si tu equipo no soporta el arranque EFI aún es muy probable que puedas disfrutar de las ventajas del sistema de particionado GPT.

Partición activa: Ser activa es una propiedad de una partición que indica que puede arrancarse un sistema operativo desde ahí. Un cargador de arranque genérico se limita a cargar lo que haya en el primer sector de cualquier partición activa que encuentre. Éste tipo de arranque se denomina también "carga encadenada" (chainload). MS-DOS sólo permite una partición activa. En los sistemas con GPT, esta función la realizan las particiones EFI (sí, puede haber varias en un mismo disco). EFI es una adaptación curiosa del viejo estilo de arranque de Linux con partición /boot separada.


Referencias:
https://es.wikipedia.org/wiki/Partici%C3%B3n_de_disco#Particiones_extendidas_y_l .C3.B3gicas
https://es.wikipedia.org/wiki/Tabla_de_particiones_GUID

[karlggest]

- ¿Dónde guardo esto?
- Por favor, ¡no me interrumpa con vanalidades!

Los volúmenes lógicos surgen para superar muchas limitaciones de las particiones de disco. Una de las formas en las que intenta hacerlo es añadiendo una capa de abstracción. Esto es muy similar al funcionamiento de la jerarquía del sistema de ficheros de Unix.

Recordemos: en un sistema Unix tenemos una raíz de la que depende todo, de forma organizada: así, tenemos /media, que es el lugar donde se montan los dispositivos "media": pendrives, CD/DVD, etc.; /home puede estar en otra partición, o incluso en otro equipo,... lo que el usuario ve es un todo homogéneo, donde la información está organizada siguiendo unos criterios dados, mientras que en realidad el sistema es bastante heterogéneo como vemos.

En un sistema de volúmenes se indica qué dispositivos (particiones de discos) forman parte del volumen físico. A continuación, se divide el volumen en partes (volúmenes lógicos), pero es el gestor de volúmenes el que reparte los volúmenes lógicos por el volumen físico.

Una consecuencia interesante es que es muy sencillo adaptar los volúmenes lógicos: redimensionarlos, eliminarlos, añadirlos, acciones que incluso no necesitan interrumpir el sistema para nada (salvo reducir la partición), ni siquiera desmontarla.

Otro uso, más curioso e ilustrativo, es el de instantáneas. El gestor de volúmenes es capaz de definir un volumen lógico que vaya a ser una instantánea de otro en un instante justo dado. Así, uno puede copiar dicho volumen sin preocuparse de que el sistema en uso esté guardando cambios en dicho volumen: el sistema usará la instantánea para guardar temporalmente estos cambios y los reintegrará al volumen original cuando acabemos. Así, garantizamos la integridad de nuestra copia, sin que los usuarios del volumen se percaten siquiera.

volumen físico: un volumen físico es la correspondencia entre las particiones que forman el volumen y el volumen en sí. Se definen qué particiones de disco o qué discos forman parte del volumen.
grupo de volúmenes: son agrupaciones de uno o más volúmenes físicos.
volumen lógico: cada unidad del volumen que va a ser usada de forma diferenciada.

Los volúmenes hacen uso de su propia nomenclatura para manejar la información. Así en lugar de sectores y demás, trata de Extents. Los Extents físicos son pequeñas porciones de datos almacenados en un volumen físico. Los Extents lógicos son los datos que se mapearán a los extents físicos. Lo habitual es que un extent lógico sea mapeado a uno físico, pero algunas opciones -por ejemplo, mirroring- permiten mapearlos a varios extents físicos -en el caso del mirroring, cada extent lógico es mapeado a dos extents físicos.

Alguien que encuentre molesto aprender algún concepto sobre las particiones de disco -los volúmenes se construyen normalmente sobre particiones de disco- encontrará molesto afrontar volúmenes(1). Es lógico. Tienen muchas ventajas, pero para un usuario doméstico tales ventajas... bueno, no son tantas (2)

(1) El Mal habla de "volúmenes", no de particiones, en su gestor de discos.
(2) La principal es la reducción del tiempo medio de acceso cuando se trata de discos duros tradicionales: supuestamente, menor tamaño de partición implica que el área donde debemos posicionarnos para alcanzar un archivo, por ejemplo, será menor; siendo el área menor, podemos pensar que las búsquedas tenderán a ser más rápidas. Es buena idea repasar la geometría física de los discos duros (p. ej., como es habitual: http://es.wikipedia.org/wiki/Disco_duro)

[karlggest]

En su virtud, esconde El Mal en su interior

GNU/Linux puede utilizar particiones NTFS, tanto solo-lectura como en lectura/escritura. Lo cierto es que no permite manejar algunas características de NTFS como su sistema de ACL, pero rara vez esto será molesto para un usuario doméstico...

... pero sí lleva a hacer una consideración. No es buena idea tener Windows en una sola partición: los datos a compartir con otros sistemas (además de para protegerse en desastres) deben de estar aparte. Compartir los archivos del sistema, salvo que sea precisamente la idea -hay quien tiene un GNU/Linux para ayudarse en caso de desastre en Windows-.

Cómo montar una partición NTFS se explica en la web de openSUSE(1).

En caso de haber problemas, deben verificarse varias cosas:

* la propiedad y permisos de la carpeta donde se monta el dispositivo.
* los permisos establecidos en /etc/fstab cuando se monta el dispositivo. Por ejemplo, que entre las opciones no figure ro, o figure rw en su lugar

En el hilo Gestión Simple de Permisos (y II) puede encontrarse información sobre ambas posibilidades.

Pero hay vida más allá de NTFS. Windows soporta -mediante drivers de terceros- algunos sistemas de archivos nativos de GNU/Linux. En algunas ocasiones puede merecer la pena pensar si es mejor opción (en particular, porque es más fácil montar dispositivos). Por ejemplo, puede proporcionarse soporte solo-lectura para ext4 y lectura-escritura para ext3 o reiserfs(2)

(1) http://en.opensuse.org/SDB:NTFS
(2) http://en.wikipedia.org/wiki/Installable_File_System