¿Cómo migrar Window$ 10 desde un disco rígido a un SSD usando Ubuntu?

¡Trabajadores!

Nunca hemos de cejar en usar Software Libre, pues es esta una lucha que hemos de dar para vencer y hacer grande a la Patria.

La oligarquía plantea el uso de Software Privativo, y bajo esa bandera de ignominia, presenta un sistema operativo encadenados bajo el oprobio de una Acuerdo de Licencia de Usuario Final, que nos impide copiar, modificar, alterar o redistribuir el software. Un programa de estas características no sólo es inútil, sino completamente dañino para la humanidad. No contempla la Justicia Social ni respeta a la Comunidad Organizada.

Pero el Justicialismo nunca ha sido sectario ni dogmático. Si bien debemos abstenernos de utilizar tales sistemas operativos, bien podremos usar Software Libre para ayudar en nuestra Comunidad a quien necesita usarlo. Esto es así pues el software libre está ampliamente capacitado para satisfacer todo tipo de necesidades informáticas.

En este caso en particular me han preguntado cómo puedo migrar una instalación de Window$ 10 provista en un disco de 1TB instalado ya en una computadora portátil hacia un SSD de 250GB, a fin de aumentar la velocidad de ejecución de tal portátil.

Esto que parece sencillo en realidad no lo es tanto. Sería muy simple si contásemos con disco destino de la misma capacidad que el disco de origen, pues en tal caso podría hacerse un "clonado"espejo" entre ellos con HDD Clone o Clonezilla. Sin embargo, un disco SSD de 1 TB escapa a las posibilidades presupuestarias de la masa trabajadora. Por tal motivo habremos de ingeniarnos para clonar sólo lo necesario del disco origen de 1 TB (que cuenta de fábrica con múltiples particiones, C: y D:, mas varias particiones de sistema), a un disco de estado sólido (SSD) de 250GB.

Como requerimiento sine qua non hemos de saber que sólo clonar las particiones "a lo vikingo" tampoco sirve: se hace necesario clonar también la tabla de partición del disco imprescindiblemente para que el sistema operativo pueda arrancar. Esta tabla es la llamada MBR o Master Boot Record en el caso de Window$). También hemos de saber que pueden existir otros esquemas de instalación distintos al empleado normalmente Window$ (MBR), tal como el MBR/GPT, que utiliza una tabla de particiones cuatro veces más grande y es el esquema favorecido por Linux y otros sistemas operativos abiertos. En tal caso el procedimiento de clonado será ligeramente diferente, y os indicaré las salvedades para cada caso.

Vean señores, para este cometido necesitaremos idealmente de un sistema informático al que podamos conectar ambos discos a la vez para las tareas de clonado. Asimismo, necesitamos contar con algunas aplicaciones y utilidades. En el caso de contar con un sistema GNU con Linux para estos menesteres, podremos instalar las aplicaciones necesarias abriendo una terminal con Ctrl+Alt+T e ingresando el siguiente comando de organización:

sudo apt install clonezilla fdisk

Clonezilla puede ejecutarse también desde un Live CD oficial, lo cual puede ser útil si no contamos con otro sistema operativo u equipo.

Si el disco está particionado siguiendo el esquema tradicional de Windows 10, el MBR (Master Boot Record) desde la UEFI, debemos clonar todas las particiones que hacen al sistema. Estas son la partición Windows RE (“recuperación”), la partición EFI System, la partición Reserved Microsoft ("reservada") y la partición de datos Basic de Microsoft que contiene al sistema operativo Windows (típicamente nomenclada como unidad C:). En este caso tradicional, el esquema de particionado que nos indicará fdisk bajo disklabel será "DOS". Tengamos en cuenta que en muchos equipos portátiles se agregan particiones adicionales que contienen instaladores de programas o controladores de dispositivos.

En las capturas de pantalla a continuación podremos analizar el esquema de partición de Windows 10, en caso de un estilo MBR, y un esquema GPT realizado desde la UEFI.

Esquema de partición MBR desde la utilidad Administración de Disco (Windows 10):

 Fig.1 Revisando el esquema de particionado MBR

En el caso del esquema de particionado GPT favorecido por los sistemas Linux, el sistema tendrá una tabla de alocación distinta. En tal caso la utilidad de línea de comandos fdisk informará que el tipo de disklabel como "GPT".  Desde Administración de Disco de Windows se indicará así:

Fig.2 Revisando el esquema de particionado MBR

Esta guía asume que ambos discos (el HDD viejo y el SSD más pequeños) están conectados físicamente al sistema a través de sus conectores SATA normalizados, y que el Sistema operativo Windows está instalado con un esquema de particionado MBR, el tradicional de Windows.


Paso 1: Achicar la partición C: del Sistema operativo Windows 10
Tengamos en cuenta que en este caso la partición C: del disco rígido es más grande que el tamaño total del SSD destino, y por lo tanto necesitaremos reducir su tamaño para que quepa en el SSD. Los cálculos para este paso son simples:

Las suma de las particiones Windows RE + Recuperación + Partición EFI + c: de Windows debe ser menor o igual que el total del tamaño del SSD reportado por la utilidad fdisk.

1. Para achicar la partición C: desde Windows, vamos a Inicio / Ejecutar... ejecutamos la aplicación diskmgmt.msc o directamente abrimos la utilidad Administración de Disco de Windows. La usaremos para reducir el tamaño del volumen (“Shrink Volume”) C: (asumiendo que Window$ está instalado al comienzo del disco en la segunda partición, a continuación de la partición Reservado de Sistema, y que tiene la letra de unidad C: asignada). Reducimos el tamaño al mínimo posible.

Fig.3 Reduciendo el tamaño de la partición C:

Si no deseamos o no podemos utilizar el Administrador de Discos de Window$ para esto, podríamos usar un LiveCD de Ubuntu y utilizar la aplicación Sistema / Administración / Gparted para achicar el tamaño de la partición C: al mínimo posible.

2. Luego de haber reducido el tamaño de la partición C:, apagamos la portátil y conectamos ambos discos al equipo con Sistema Linux que usaremos para clonar; también podríamos arrancar dicho equipo usando el Live CD de Clonezilla o Parted Magic). En él podremos entramos a la interfaz de línea de comandos, que usaremos para revisar las tablas de particiones y tamaños de ambos discos. Para ello usamos los siguientes Comandos de Organización:

fdisk -l /dev/sda
fdisk -l /dev/sdb

Fig.4 Revisando el tamaño de la tabla de Particiones

Tengamos en cuenta que la nomenclatura y orden de los discos puede variar entre Windows y Linux y de acuerdo a la configuración BIOS/UEFI del sistema. La nomenclatura que asumimos en los ejemplos es que el disco sda es el disco de 1TB, sdb es el SSD de 250GB, etc. Debemos seleccionar el disco con la máxima atención de manera de no terminar clonando un disco equivocado y destruir todos los datos.

Para saber cual es el disco de origen correcto (el HDD en este caso) y el disco de destino correcto (el SSD), usamos el tamaño y la tabla de particiones reportadas por el comando fdisk. Fdisk debería devolvernos que el SSD debería ser mas pequeño en tamaño que el disco HDD, y si es nuevo, no debería tener creada ninguna tabla de partición por defecto.

Si usamos el disco de Clonezilla para revisar esto ingresamos los comandos:

su -
fdisk -l /dev/sda
fdisk -l /dev/sdb

si usamos Ubuntu en cambio podremos usar:


sudo fdisk -l /dev/sda
sudo fdisk -l /dev/sdb

...y en caso de un disco con esquema GPT, la partición del HDD se informaría  como se indica abajo,

 Fig.5 Revisando el tipo de particionado (“Disklabel”)

Paso 2: Clonar los Discos usando Clonezilla
3. A continucion, clonaremos únicamente la MBR del disco rígido origen (“Master Boot Record”, la tabla de inicio maestro, compuesto por un sanguchito de 512KB integrado por una feta que es el arrancador de etapa 1 mas otra feta formada por la tabla de particiones del disco), copiándola al SSD destino. Para ello usamos uno de los comandos siguientes (asumiendo que sda representa al disco rígido de 1 TB de origen donde está el Windows OS y sdb es el disco SSD destino de 250GB):

sudo dd if=/dev/sda of=/dev/sdb bs=512 count=1


o también:


sfdisk -d /dev/sda | sfdisk -f /dev/sdb

Fig.6 Clonando la MBR de un disco usando Clonezilla

En el caso de contar con un estilo de particionado GPT, el accionar es ligeramente diferente, pues no tenemos una MBR ensanguchada de 512 bytes como en el caso anterior sino una MBR/GPT cuatro veces más grande, de 2048 bytes. En tal caso, el comando sería:

sudo dd if=/dev/sda of=/dev/sdb bs=2048 count=1

También podríamos usar la utilidad sgdisk especializada para este menester. Tengamos en cuenta que si copiamos la tabla de partición desde sda a sdb debemos invertir el orden indicado al usar sgdisk, pues su sintaxis es sgdisk -R discodestino discoorigen. El comando entonces sería:

sgdisk -R /dev/sdb /dev/sda

Después de clonar la MBR/GPT, ejecutamos fdisk con el modificador -l para realizar una verificación, a fin de asegurarnos que la tabla de particionado coincida en ambos discos:

sudo fdisk -l /dev/sda
sudo fdisk -l /dev/sdb

Fig.7 Verificando la Tabla de Particionado

4. Llegados hasta aquí, ambas unidades deberían contar con una tabla de partición exactamente clónica, que define cómo está estructurado el disco. En el disco destino debemos ahora borrar todas las particiones que vienen después de la partición Windows, de manera de comenzar con una tabla de particiones limpia que tenga las entradas necesarias sólo para reservada de sistema y Windows.

Tampoco clonaremos la partición de datos D: del disco HDD, sino que clonaremos sólo las primeras dos particiones del disco rígido origen al SSD destino para que pueda arrancar. Luego emplearemos el espacio libre no utilizado del SSD para extender la partición C: en el espacio sin utilizar que hubiese podido sobrar en el SSD.

Usamos la utilidad fdisk como se describe a continuación para hacer el borrado las particiones. En primer lugar ejecutaremos el comando para la unidad destino SSD (/dev/sdb en este caso), mostrar la tabla de particiones con p, luego presionamos d para comenzar a borrar las particiones y elegir el último número de la partición desde la interfaz de comandos (en este caso, es la tercera partición). En este caso el comando sería:

sudo fdisk /dev/sdb

Fig.8 Borrando la tabla de particiones:

En caso de que nuestro disco tenga más de una partición a continuación de la partición Windows, debemos asegurarnos de borrarlas a todas. Luego de haber removido todas las particiones innecesarias, presionamos p nuevamente para que el sistema nos liste nuevamente la tabla de particiones actualizada; ahora sólo deberían verse las particiones requeridas de Windows (Reservada y C:). Conforme nos aseguremos de ello, podremos presionar la tecla w para aplicar definitivamente estos cambios.

Fig.9 Confirmando los cambios de particionado

El mismo procedimiento también aplica para borrar los discos GPT, con la mención que podremos emplear la aplicación cgdisk que es intuitiva para operar y manipular el esquema de un disco. En tal caso no es necesario preocupemos de eliminar una tabla de particiones de respaldo localizada al final del disco GPT, pues cgdisk realizará convenientemente los cambios necesarios en ambas tablas de particiones y almacenará la nueva tabla de particiones MBR/GPT al principio y al final del disco automáticamente (como especifica el esquema GPT). El comando en tal caso sería:

cgdisk /dev/sdb

Fig.10 Borrar la partición GPT

Y el reporte de disco GPT final con la última partición de 4,9 GB eliminados.

Fig.11 Verificando la tabla de particiones GPT.

5. Ahora, con todo en su lugar, iniciamos la utilidad Clonezilla, seleccionamos el modo Dispositivo a Dispositivo (“device-device mode”), y ejecutamos el Asistente para Principiantes, y elegimos la opción Partición a Partición Local.
Podrán usar las capturas de pantalla siguientes como referencia:

Fig.12 Seleccionamos el Modo de Dispositivo de Clonezilla

Fig.13 Seleccionamos el Modo Sencillo de Clonezilla

Fig.14 Seleccionamos el clonado de Partición a Partición Local en Clonezilla

6. Seleccionamos la primera partición de la lista (sda1 – Reservada de Sistema) como origen, y luego presionamos Enter para continuar.

Fig.15 Seleccionando la Partición a clonar

7. A continuación, escogemos la partición de destino local, que será la primer partición del segundo disco, (/dev/sdb1) y presionamos Enter para continuar.

Fig.16 Seleccionando la partición de destino Local

8. En la ventana siguiente seleccionamos Skip check/repair file system (Saltar revisión/reparar sistema de archivos”) y presionamos Enter nuevamente para continuar.

Figh.17 Salteando la opción de revisar y reparar el sistema de archivos

9. Finalmente, presionamos Enter nuevmanete para continuar y respondemos Si (y) dos veces para aceptar las advertencias y comenzar el proceso de clonado.

Fig.18 Confirmar los cambios de Partición

Fig. 19 Comenzando el clonado en sí de la partición

10. Luego que el proceso de clonado de la primera partición finalice, seleccionamos entrar a la línea de comandos, ejecutamos clonezilla y repetimos los mismos pasos para las particiones siguientes (origen sda2 – destino sdb2, etc).

 Fig.20 Clonando la segunda Partición

11. Luego de haber clonado todas las particiones de Windows, apagamos el sistema y removemos el disco rígido origen del equipo y reinstalamos el SSD en la portátil, y la encendemos, ajustando la BIOS para indicar el el SSD sea la unidad de arranque primaria si fuese necesario.

Paso 3: Redimensionar la partición de WIndows

12. Ahora podremos ejecutar Gparted para revisar que las particiones hayan quedado bien y extender las partición de Windows.

Extender las particiones usando Gparted desde un Live DVD

Fig.21 Redimensionar la partición usando gParted.

Fig.22 Redimensionar el tamaño de la partición

Si no quisiéramos usar gparted, bien podremos también extender el tamaño de una partición usando el Administrador de Discos de Windows.

 Fig.23 Extendiendo la partición de Windows Partition

Fig.24 Seleccionando el Disco a extender

Esto es todo. Ahora la partición c: está extendida al máximo espacio del SSD y Window$ 10 ahora puede correr con la velocidad de un disco de estado sólido SSD. El disco rígido de 1TB ahora tiene toda la información intacta, y se emplea como respaldo.

Conclusión
Con Cloneszilla podremos escoger una imagen de las particiones y guardarlas en un disco externo o en una unidad de red. En este caso también debemos respaldar la MBR o MBR/GPT del disco con el siguiente comando, y grabar la imagen MBR en el mismo directorio donde están almacenadas las imágenes de Clonezilla:

Para respaldar la MBR a un archivo:

sudo dd if=/dev/sda of=/ruta/de/MBR.img bs=512 count=1

...o también:

sfdisk -d /dev/sda > =/ruta/al/backup/sda.MBR.txt

Para respaldar la MBR/GPT a un disco: 

sudo dd if=/dev/sda of=/ruta/al/backup/GPT.img bs=2048 count=1

...o también:

sgdisk --backup=/ruta/al/backup/sda.MBR.txt /dev/sda

En el caso de tener que restaurar el sistema Windows desde una localización de red, primero debemos restaurar el sector MBR o MBR/GPT usando el archivo de imagen almacenado previamente, a través del comando correspondiente:

Para restaurar la imagen MBR a partir de un archivo:

sudo dd if=/ruta/al/backup/MBR.img of=/dev/sda bs=512 count=1

...o también

sfdisk /dev/sda < =/ruta/al/backup/sda.MBR.txt

Para restaurar una imagen MBR/GPT por medio de un archivo de respaldo:

sudo dd if=/path/to/GPT.img of=/dev/sda bs=2048 count=1

...o también:

sgdisk - -load-backup=/ruta/al/backup/sda.MBR.txt /dev/sda

¿Cómo optimizo Ubuntu 14.04 para un SSD y un HDD?

Juan Perón planificó la acción de estado que habría de tener un Movimiento Nacional encarnado en el Pueblo, Como tal, nos enseña cómo trabajar de forma óptima en Ubuntu con un disco de estado sólido (SSD) y un disco convencional.

El Justicialismo ha otorgado siempre lo mejor al Pueblo. Si no lo hicimos antes, fue porque una Oligarquía Cipaya no hacía más que dominar las riendas del Estado en pos de un beneficio propio. Nuestra Doctrina, en cambio, privilegia beneficiar al Pueblo con una inacabable lluvia de beneficios sociales, culturales, y la consabida lluvia de Choris al Parquet.

Entre las posibilidades nuevas que podemos festejar cada 17 de octubre se encuentra la de almacenar nuestros datos en los llamado Discos de Estado Sólido, o SSD, que corren con la velocidad de un Studebaker.

Los SSD poseen de disco sólo el nombre; son más bien memorias de tipo flash, capaces de escribirse y leerse con una performance óptima comparada con los discos rígidos de mecánica clásica. A diferencia de los complejos "platos" de los discos rígidos convencionales, los SSD carecen de partes móviles que lo enlentezcan, y por ello son mucho más veloces en lo que hace a su acceso no secuencial. El aumento de velocidad de lectura es tan apreciable, que notaremos que es típico para un equipo iniciar y arrancar su sistema operativo GNU con Linux en menos de lo que canta un gallo.

Tal es el aumento de desempeño en lectura, que hoy ya se convierte en la opción ideal para mejorar un sistema de computación, atendiendo de que el mismo tenga conexiones de discos SATA. Sin duda el SSD aumentará el desempeño de trabajo general más que cualquier otra mejora de microprocesador o memoria que le hagamos. Por ello, es la opción que - dado el costo en reducción de los dispositivo - recomiendo para todos los peronistas con equipos de escritorio que quieran mejorarlos sensiblemente.

Para que un SSD dé lo mejor de sí y nos proporcione años de buena performance sin errores, debemos hacernos prácticos en seguir ciertas conductas militantes. Algunas de ellas pueden replicarse también en los discos rígidos convencionales, y otras no.

a) Usar el disco SSD en modo AHCI.
Como primera medida siempre será útil configurar nuestra BIOS para que el controlador de discos ATA funcione preferentemente en la modalidad AHCI, salvo necesidad contraria.

Por defecto, los controladores de disco de los equipos actuales operan en el modo IDE, y eventualmente en el modo de "autorrespaldo redudante" o RAID (especialmente en servidores críticos).

La modalidad AHCI es la recomendada para los usos convencionales con discos modernos (SDD y HDD). Para modificar esta modalidad de operación, hemos de ser peronistas e ingresar a la rutina de configuración de la BIOS/UEFI) sistema (usualmente presionando varias veces la tecla Supr mientras se enciende el equipo). Una vez que se nos presente la pantalla de configuración de la BIOS, buscamos la opción Avanzados (Advanced Peripherals o Advanced Parameters), y en el apartado de Controlador de Disco o Modo SATA (Disk Controller Mode o SATA Mode) escogemos la opción AHCI. Conforme hayamos realizado este paso, salimos de la configuración del BIOS guardando los cambios realizados (Exit Saving Changes).

b) Reinstalar el sistema operativo particionando entre un disco SSD y en un HDD.
El paso anterior será suficiente si contamos con una única unidad de almacenamiento para nuestro GNU con Linux, y la misma es un disco de estado sólido.

Pero ello no es lo ideal, al menos en la situación actual, pues existen algunos inconvenientes que debemos prever, limitaciones que podemos querer tener en cuenta a la hora de planificar la instalación de nuestro Linux:

Una de ellas es que los sistemas de archivo actuales (los FAT o NTFS de algunos sistemas operativos privativos, o los EXT2, favorecidos por el sistema GNU) están pensados mas que nada teniendo en mente las características de los discos rígidos convencionales. Si bien los modelos recientes no sufren tanto este aducido problema y deberían permitirnos contar con almacenamiento al menos por unos 10 años de trabajo, la tecnología es relativamente reciente y no podemos asegurar un correcto funcionamiento. Todos sabemos que a Seguro se lo han llevado preso, y varias veces le dieron goma. En particular, debemos considerar que los SSD sufren un relativo desgaste al escribir la información en los racimos de memoria que componen su parte activa (no así en el proceso de lectura).

Afortunadamente, en un sistema GNU con Linux esto se ha previsto. En la actualidad suele darse el caso que ya contemos con un disco rígido convencional instalado en nuestro sistema, al que podremos darle un uso excelente y compensar el inconveniente descripto anteriormente.

Durante la instalación modificaremos la estructura de discos para presentar la opción menos riesgosa y más adecuada como opción de almacenamiento. Podremos practicar estrategias que privilegien el uso del SSD en funciones de sólo lectura, mientras que en disco rígido convencional se concentran la mayoría de las funciones de escritura de datos.

¿Cómo hacemos esto? Los sistemas GNU con Linux disponen de la posibilidad de estructurar su árbol operativo en una única partición o en varias particiones diferentes, distribuidas a lo largo de uno o de múltiples discos de distintas velocidades. De esta forma contaremos con el directorio raíz ("/") del sistema operativo, la mayoría de los programas de ejecución y sus librerías directamente en el disco SSD (de lectura ultrarrápida).

En el otro disco convencional dejaremos los directorios de sistema /tmp, y /var (directorios usados "de fábrica" para almacenar archivos de uso temporal en sesión y aquellos que cambian repetidamente), así como la carpeta /home (alberga los contenidos del usuario, sus documentos, música, videos, etc). Estos datos no suelen ser leídos tan a menudo ni es crítica su lectura a gran velocidad, por lo que prácticamente no notaremos diferencia al leer datos desde aquí.

Indudablemente, un Conductor de GNU Linux experimentado no tendrá problemas para reestructurar esta configuración con posterioridad a la instalación del sistema, y al vuelo, armando las particiones con fdisk e indicando en qué unidades de disco y sus correspondientes particiones se almacenarán las carpetas del sistema operativo, todo ello mediante la edición del archivo /etc/fstab.

Sin embargo, en la vida sucede lo mismo que en la Política: no todos son Conductores. La Masa habrá de hacer esta planificación a la hora de instalar el sistema, en el paso de asignación de disco. Os explicaré de manera sencilla cómo hacerlo.

En lugar de instalar todo el sistema operativo (en este caso, Ubuntu 14.04LTS de 64 bits) en una única partición y en un único disco, durante la instalación deliberadamente escogeremos instalación personalizada, y lo dividiremos en dos: una parte para el SSD y otra para el disco rígido convencional.

En primer lugar utilizaremos el disco rígido de estado sólido. Debemos buscarlo de acuerdo a su marca y modelo, en la lista. En este ejemplo, se trata de un  dispositivo Kingston V300 nomenclado como /dev/sdd. Elegimos dicho disco, y presionamos el botón "Nueva Tabla de Partición", lo cual nos permitirá crear nuevas particiones en el disco vacío. Luego presionamos el botón "+" y sumaremos una partición completa (si es que queremos utilizar todo el SSD para el sistema Ubuntu).

Se abrirá un cuadro que nos permite elegir el tipo de partición. Debemos tildar Primaria. Podemos tildar "Al comienzo del espacio" para que comience desde el inicio de los sectores de trabajo del SSD. Técnicamente, durante la instalación debemos asignar mediante el desplegable que punto de montaje será la raíz del sistema operativo (indicada con "/"), y como formato le indicaremos "EXT4".

También deberíamos indicar que es la partición del SSD es la de arranque ("Boot") si no tuviésemos otros sistemas operativos. De esta manera, el instalador cargará en nuestro disco de estado sólido el arrancador de sistemas operativos, el GRUB.

Normalmente, la partición ocupará así todo el disco SSD. Allí se montará (instalará) la estructura raíz ("/") del sistema operativo, con las rutinas de arranque, el kernel, los directorios de operación con los binarios de los programas centrales y de las aplicaciones grandes, los controladores de dispositivo, las librerías, etc. La carga de estos datos en el SSD en lugar de un disco rígido convencional, aumentará unas diez veces el arranque y ejecución de lectura del sistema.

Como referencia, tengamos presente que Ubuntu 14.04 y un muy buen compendio programas, se puede instalar en 15 Gb de espacio para su unidad raíz, pero os recomiendo al menos unos 35 GB para estar tranquilos. Tengamos presente que si quisiéramos que quedase espacio disponible para otro sistema operativo en el SSD, debemos reducir el tamaño para que no ocupe el total del espacio disponible.

Acto seguido, hemos de configurar el disco rígido convencional (en este caso un batallado Western Digital de 320Gb), para que contenga cuatro particiones, que serán las que sufrirán mayores procesos de escritura.

Por el procedimiento anterior, realizaremos una primer partición que ocupará - por ejemplo - el 70% del disco, y ella montaremos la carpeta /home en formato EXT4 (aquí se almacenarán los datos propios de los usuarios del sistema, documentos, música, videos, archivos propios de configuración, correos electrónicos, etc). Adicionalmente crearemos dos particiones con el 10% del espacio cada una (también en formato EXT4). En ellas montaremos las carpetas de sistema /tmp (para los archivos temporales utilizados diariamente) y la carpeta /var. En el porcentaje restante podremos asignar una partición de intercambio (obligatoriamente en formato SWAP), la cual se usa en ciertos casos para suplir a la memoria RAM principal. La cantidad de espacio adecuado para la partición de intercambio SWAP será el del tamaño de nuestra memoria RAM.

Naturalmente este ejemplo es válido para un sistema en el que trabaja normalmente un usuario único. Podríamos querer variar las cantidades de espacio en disco destinado a las particiones exclusivas de /tmp y de /var si varios usuarios hiciesen con regularidad uso del sistema al unísono (a través de múltiples terminales, por ejemplo). Esto podremos variarlo posteriormente por medio del programa GParted.

No debemos dejar sin espacio a los directorios de sistema /tmp y la carpeta /var. Si estas fuesen muy pequeñas podrían ralentizar al sistema; es preferible asignar espacio de más y no encontrarnos con que falte disco después, pues nunca sabremos qué aplicación podríamos correr que requiera crear archivos temporales pesados, o necesidades especiales que requieran un gran movimiento de datos en estas particiones. En este caso he conformado una partición para /tmp de 16 Gb (tengamos en cuenta que esta se borra al cerrar el sistema). Luego continuamos la instalación de Ubuntu normalmente.

Una vez finalizada la instalación, podremos acceder al sistema de forma ultrarrápida. Ya podremos instalar el resto de las aplicaciones que querramos.

c) Eliminar la operación de reescritura de registro para el disco SSD


Otra forma adicional para optimizar nuestro sistema de discos en Linux consiste en desactivar la acción de escritura de registro de tiempo de acceso. Según la misma, el sistema operativo imprime a cada fichero un registro de hora y fecha en la cual fue leído por última vez. En el caso de un disco SSD y salvo una necesidad muy estricta en un equipo servidor, este estampado no es lo más deseable. Lo podremos desactivar fácilmente modificando el archivo de configurarción del sistema de disco /etc/fstab. Para ello abrimos dicho archivo desde la terminal con el editor de texto peronista, el Nano:

sudo nano /etc/fstab

Se abrirá el editor GNU Nano y nos mostrará el archivo.

Debemos buscar una línea que tenga la siguiente topología:

UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx / ext4 ,errors=remount-ro 0 1

Debemos agregar la variable noatime a todas las particiones de administrador (root) y a las de Linux que tengamos en el SSD (¡con excepción de la partición de intercambio o Swap!). La línea modificada debería quedar así:

UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx / ext4 noatime,errors=remount-ro 0 1

Una vez modificada, grabamos con Ctrl+o y salimos de Nano con Ctrl+x.

También conviene reiniciar los demonios:

sudo systemctl daemon-reload

d) Realizar el alineado de bloques de almacenamiento.

En Ubuntu 14.04 (y Mint 17.1) es necesaria la acción del comando TRIM para ajustar los bloques de archivo y asegurar el buen funcionamiento y performance. De lo contrario, el disco, a la larga, se tornará progresivamente en más lento y anquilosado.

La manera más simple es que el sistema realice la acción de ajuste de forma automática. En Ubuntu 14.04 y Mint 17 Ubuntu lo hace a través de un trabajo relegado a través del comando cron que lo realiza una vez a la semana.

Pero nada quita que podamos ejecutar la acción de TRIM de forma manual también. Presionamos Ctrl+Alt+T e ingresamos el siguiente comando

sudo fstrim -v /

Debemos ingresar nuestra contraseña de Conductor, y no se mostrará nada, ni siquiera puntos. El proceso puede tardar un par de minutos, esto es normal. Este comando es suficiente si tenemos sólo una partición de Ubuntu y una partición de intercambio en el SSD. Si tuviésemos las otras particiones en el SSD también, deberíamos indicar:

sudo fstrim -v /tmp 

sudo fstrim -v /var

...etc. Una vez completo el proceso de ajuste, podremos seguir usando el sistema, o asegurarnos, reiniciándolo con:

sudo reboot