Hace muy poco que he sustituído el disco duro por un SSD Crucial M4 de 128 GB. También he aumentado la RAM de mi Asus EeePC 1215n de 2 a 8 GB (2×4 GB), que son lo máximo soportado por el ordenador.
Sobretodo, cambiar del disco duro mecánico (500 GB, 5400 rpm, 8 MB de caché) al SSD me ha brindado un rendimiento muy superior; pero se puede mejorar aún más: en una entrada dedicada al EeePC 901, comenté algunos tips para optimizar el uso de un disco SSD, básicamente reduciendo las operaciones de I/O, así que aprovecho para repasar lo ya publicado e incluir otras mejoras. Hey! Además sirven para otras distros además de Ubuntu!
Modificar /etc/fstab
Comenzaremos por obligar al sistema a usar TRIM en lugar de los mecanismos de Garbage Collector. Necesitaremos un kernel superior al 2.6.33 y que la partición sea EXT4. Lo podemos consultar con:
$ uname -r
También nos debemos asegurar de que el disco soporta TRIM (sustituye /dev/sda por la unidad apropiada):
$ sudo hdparm -I /dev/sda | grep TRIM
Esto debería producir una salida similar a:
* Data Set Management TRIM supported
Si nuestro disco lo soporta, abrimos fstab:
$ sudo nano /etc/fstab
Y en la línea de montaje del SSD añadimos la opción «discard».
También podemos añadir la opción «noatime» para evitar que el SO guarde la fecha de último acceso a los archivos, ahorrándonos así bastantes lecturas/escrituras extra. Si tras activar esta opción algunos programas te dan problemas (por ejemplo, el cliente de correo Mutt) puede que te interese cambiarla a «relatime».
En mi caso la línea tiene finalmente esta pinta:
UUID=0affe34c-3df4-49c8-9a02-4d4530ea7430 / ext4 noatime,discard,errors=remount-ro 0 1
Otra buena idea es que las carpetas de archivos temporales no se almacenen en el disco duro sino en la RAM, así que al final del archivo añadimos las siguientes líneas:
# Archivos temporales en la RAM
none /tmp tmpfs size=5%,defaults 0 0
none /var/tmp tmpfs size=5%,defaults 0 0
A diferencia de lo que hacía en el post sobre el EeePC 901, no estoy montado /var/log como un directorio volátil por si quisiera que los logs fuesen persistentes para poder consultarlos en otra ocasión. Si no sueles revisar los logs de tu sistema o estos no te preocupan, también puedes incluir esta otra línea:
none /var/log tmpfs size=5%,defaults 0 0
No usar SWAP
En el SSD no quería utilizar SWAP así que además de no crear la partición correspondiente, obligué al sistema a que no utilizase ningún intercambio (fuese este una partición o un fichero de swap). Para esto, basta con editar el siguiente archivo:
$ sudo nano /etc/sysctl.conf
Y al final añadir:
# No usar swap
vm.swappiness=0
Si tienes una partición SWAP en el SSD pero no quieres eliminarla te recomiendo que hagas esta modificación. Si se trata de un fichero, desactivalo como se muestra al final del post sobre archivos swap. Sin embargo, si tu partición/archivo SWAP está en un disco mecánico o no existe, entonces no debes preocuparte.
Por otra parte, recuerda que en linux necesitas al menos tanto espacio de swap como memoria RAM tengas para poder hibernar el equipo. En mi caso no me compensa porque el sistema arranca como un tiro cuando uso el SSD pero es que además Ubuntu trae la hibernación desactivada por defecto a partir de 12.04. Otro motivo más para no usar swap.
Desactivar el journaling de ext4
Para realizar esto, necesitarás arrancar una versión Live de GNU/Linux (prácticamente cualquier distribución servirá). Una vez dentro del sistema live, salta a un terminal.
De nuevo, suponemos que el disco SSD esté identificado como /dev/sda y la partición sea sda1:
$ sudo tune2fs -O ^has_journal /dev/sda1
Después de desactivar el journaling, será buena idea repasar el sistema de archivos por si hubiese errores:
$ sudo e2fsck -f /dev/sda1
Cambiando el programador del disco
El programador de disco es un algoritmo que, dado un conjunto de operaciones a realizar en el disco duro, realiza los cambios con las menos lecturas/escrituras posibles para así ahorrar tiempo. En los discos mecánicos esto es muy importante porque el acceso a datos es bastante lento comparado con la memoria RAM. Con los discos SSD sin embargo, esto no es así ya que todos los datos se acceden con la misma rapidez y los tiempos son mucho mejores que en el caso de los discos tradicionales.
Tu programador actual lo puedes consultar así:
$ cat /sys/block/sda/queue/scheduler
El resultado será:
noop [deadline] cfq
Tu programador será el que se encuentre entre corchetes. En los links de abajo encontrarás más información, pero para un SSD la opción a priori más recomendable puede ser deadline. La razon de escoger este «scheduler» es que realiza cierta optimización, mientras que noop opera como una cola FIFO sin apenas reducir el número de operaciones de I/O; pero de todas formas puedes hacer pruebas…
Hay varias maneras de cambiar el programador. La más simple es editar la línea de GRUB que carga el kernel al arrancar el sistema operativo:
$ sudo nano /etc/default/grub
Ahí se encuentra la línea:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
Y podemos agregar la opción «elevator» con nuestro scheduler. Por ejemplo:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"
Después de guardar y cerrar el archivo, tendremos que actualizar nuestro grub:
$ sudo update-grub
—
Links:
Emilio Devesa 
Hola. gracias por el articulo
Mi caso tengo 6 gb de ram
La swap pienso ponerla en una particion en el disco duro mecanico, al igual que home
En el ssd solo /
He ido recopilando cosas para poner en tmpfs (esto de a continuacion es mezcla de foros/blogs etc)
none /tmp tmpfs nodev,nosuid,noatime,size=4000M,mode=1777 0 0
tmpfs /var/tmp tmpfs noexec,defaults,noatime 0 0
tmpfs /var/log tmpfs defaults,noatime 0 0
tmpfs /usr/tmp tmpfs defaults,noatime 0 0
tmpfs /var/mail tmpfs defaults,noatime 0 0
tmpfs /var/spool tmpfs defaults,noatime 0 0
tmpfs /var/log/apt tmpfs defaults,noatime 0 0
tmpfs /var/cache tmpfs defaults,noatime 0 0
tmpfs /var/cache/apt/archives/ tmpfs defaults,noatime 0 0
tmpfs /var/games tmpfs defaults,noatime 0 0
tmpfs /root/.thumbnails tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/mario/.thumbnails tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/john/.adobe tmpfs defaults,noatime 0 0
tmpfs /home/john/.cache tmpfs defaults,noatime 0 0
tmpfs /home/john/.macromedia tmpfs defaults,noatime 0 0
tmpfs /run (use mode=0755 instead of mode=1777)
¿Qué te parecen? ¿Alguno erroneo,sobra, falta?
Ademas he visto que tu pones none al principio de todas la lineas? Debo hacerlo y por que?
Tampoco tengo claro que tamaño darle en la opcion size
y si ese size deberia incluirlo en todas las lineas de tmpfs que te he puesto
Gracias
Me gustaMe gusta
Hola Carlitos, vayamos por partes:
Hay lineas que yo no pondría como tmpfs. Por ejemplo:
/var/spooles un directorio que no te interesa poner en la RAM, sobre todo si automatizas trabajos con «cron». Hay más info de lo que se guarda en ese directorio en este enlace:http://www.pathname.com/fhs/2.2/fhs-5.14.html
Por otra parte, no necesitas especificar subdirectorios si el directorio padre ya está montado como tmpfs. Es decir, si ya tienes:
tmpfs /var/log tmpfs defaults,noatime 0 0no necesitas:
tmpfs /var/log/apt tmpfs defaults,noatime 0 0porque es un subdirectorio del anterior (a no ser que quisieses establecer opciones especificas).
Un directorio sin mucha importancia es /var/games, que solo almacena las puntuaciones de los juegos de Gnome (minas, mahjongg, etc.); así que es buena idea ponerlo como tmpfs.
Sin embargo, de entre los últimos:
tmpfs /home/john/.adobe tmpfs defaults,noatime 0 0tmpfs /home/john/.cache tmpfs defaults,noatime 0 0
tmpfs /home/john/.macromedia tmpfs defaults,noatime 0 0
Parecen directorios donde se guardan preferencias de programas, archivos de caché, etc. Aquí es más dificil decidirse, y siendo conservador yo no los incluiría en tu archivo fstab.
En definitiva, si yo tuviese que editar tu fstab, lo dejaría así (algunas lineas ordenadas alfabeticamente por comodidad):
## Líneas relativas al sistematmpfs /run (use mode=0755 instead of mode=1777)
none /tmp tmpfs nodev,nosuid,noatime,size=400M,mode=1777 0 0
tmpfs /usr/tmp tmpfs defaults,noatime 0 0
tmpfs /var/cache tmpfs defaults,noatime 0 0
tmpfs /var/games tmpfs defaults,noatime 0 0
tmpfs /var/log tmpfs defaults,noatime 0 0
tmpfs /var/mail tmpfs defaults,noatime 0 0
tmpfs /var/tmp tmpfs noexec,defaults,noatime 0 0
## Líneas relativas a los usuarios
tmpfs /root/.thumbnails tmpfs defaults,noatime,mode=1777 0 0
tmpfs /home/mario/.thumbnails tmpfs defaults,noatime,mode=1777 0 0
En cuanto a poner
noneotmpfsen el primer campo de cada línea no deberías notar diferencia alguna. En teoría se debe indicar un tipo de dispositivo de bloques en el que se encuentra el objeto a montar. Por ejemplo, una línea muy común sería:/dev/sda0 / ext4 defaults 0 0Que viene a decir:
/dev/sda0: Del dispositivo A dame la particion 0/: Móntala como raíz del árbol de directoriosext4 defaults 0 0: El formato es ext4, móntalo con las opciones por defecto, no necesito que hagas volcados de su contenido en caso de problemas (primer 0) ni que hagas chequeos del sistema en cada inicio (segundo 0).Sobre el tamaño de los puntos de montaje tmpfs, ten en cuenta que estarás usando la RAM. Escoge un valor que te permita no desperdiciar demasiada memoria del sistema. En la mayoría de tus líneas, un 1% será suficiente; mientras que otras pueden necesitar algo más: un 5% para
/var/cacheestaría bien, por ejemplo.—
Actualizo: He corregido el valor de tamaño de /var/tmp que estaba en 4000M para ponerlo en unos más comedidos 400M. Ojo! Tienes 6 GB de RAM, es suficiente pero tampoco te pases con el tamaño de estos puntos de montaje!
—
Como la respuesta me ha quedado muy larga no he querido profundizar más, pero sigue preguntándome si necesitas más ayuda. Un saludo!
Me gustaMe gusta
OK, gracias por tomarte el tiempo para la respuesta y las explicaciones tan detalladas. Seguire tus consejos
Me gustaMe gusta
Hola de nuevo, Carlitos! Me alegra saber que te he podido ayudar y gracias a tí por comentar la entrada 🙂
Me gustaMe gusta
Saludos.. he seguido estes consejos, pero tengo una duda,…. pq es recomendable desactivar journaling??
Me gustaMe gusta
Hola Juan Antonio,
El journaling es una técnica que persigue dos objetivos:
– Aumentar la seguridad de que una operación de escritura se ha realizado correctamente
– Poder revertir los cambios
En el caso de los sistemas de ficheros, suele usarse para que los chequeos de disco sean más rápidos en caso de que, por ejemplo, apaguemos la máquina de forma brusca. La contrapartida es que para efectuar el journaling, se realizan muchas más escrituras y lecturas a disco.
Por eso, en términos generales, el journaling no es una técnica que al usuario común le compense si tienes en cuenta que perjudica a la durabilidad del SSD.
Tienes algo de información en la wikipedia:
https://es.wikipedia.org/wiki/Ext4#Journal_checksumming
https://es.wikipedia.org/wiki/Journaling
Espero que esto aclare tu duda, gracias por comentar 🙂
Me gustaMe gusta
Saludos.
He leído tu entrada después de haber hecho ya la instalación en SSD de Ubuntu 12.04 y, francamente, me ha parecido muy interesante, corto, conciso y completo, pero lo he leído tarde ya.
Tengo pinchados en placa el SSD de 128 GB (Samsung 840 PRO Basic) y un HDD de 500GB (WD Blue). En cuanto a RAM, tengo 8GB. Todo lo mueve un Core I5 2500.
La instalación comparte disco con Windows 7. He dejado la /home en el HDD, igual que la SWAP. Las optimizaciones que he hecho son:
-habilitar el modo AHCI en la BIOS.
-un fstrim diario (siguiendo estas instrucciones: http://www.atareao.es/ubuntu/linux-y-discos-duros-ssd/ )
-habilitar noop como planificador de disco
-añadir noatime al montaje del SSD
-bajar al 10% el porcentaje de SWAP
De momento no he hecho nada más. Estaba planteándome, incluso, en hacer una nueva instalación para que la /home se quede en el SSD, que seguramente será aún más rápido, o bien redimensionar particiones y hacerlo sin tener que reinstalar todo, pero no se bien como, no tengo claro como hacerlo, ni que tamaño debería tener un /home, teniendo en cuenta que los archivos se irían al HDD, naturalmente.
He estado barajando, también, la posibilidad de pasar a RAM los temporales, pero me da algo de yuyu. No sé, me preocupa que algo vaya mal, aunque no he leído ninguna referencia de nadie que haya tenido problemas. Asemás, supongo que puede revertirse simplemente borrando lo que hayamos añadido al respecto en el fstab, no?
Lo del journaling tampoco lo tengo claro del todo. Igual que con los temporales a RAM no soy capaz de valorar el riesgo que puede suponer, y algo debe tener, no? Me refiero a eso que comentas de posibles errores en el sistema de archivos.
Resumiendo, dudas:
-Cómo podría hacer, si es que se puede hacer, para pasar mi /home hasta el SSD y que tamaño debería darle si las carpetas de archivos (música, decargas, etc.) las muevo al HDD?
-Que riesgos puede conllevar el hecho de mover temporales a RAM? Pueden revertirse los cambios, como creo, simplemente borrando las lineas en cuestión del fstab, no?
-Que riesgos puede conllevar el hecho dedesactivar el journalig? Puede revertirse el cambio si hay problemas?
Te agradeceré mucho tu ayuda.
Me gustaMe gusta
Una cosa más, el planificador de disco no lo ajusté en el GRUB, sino en /etc/rc.local (siguiendo estas instrucciones: http://cjenkins.wordpress.com/2013/01/03/como-configurar-ubuntu-para-disco-de-estado-solido-ssd/ )
Lo comento por si la información fuese de interés para el caso que expongo.
Gracias otra vez
Me gustaMe gusta
Ambos métodos para cambiar el planificador (editar la línea de grub o incluirlo en rc.local) son equivalentes.
Gracias por el link!
Me gustaMe gusta
Y para terminar y dejar ya de ser pesadito, la última cosa que se me ocurre:
Aquí (http://foro.noticias3d.com/vbulletin/showthread.php?t=352706) he leído que se recomienda mover los archivos de actualizaciones descargadas a un directorio del SSD, lo cual parece tener lógica. En mi caso, en el HDD tengo sólo tres particiones: una de unos 60GB en NTFS para Windows (que Ubuntu monta al inicio), otra de unos 400GB en ext4 montada en /home y una tercera de 2GB para swap.
Supongo que para hacer esto, necesitaría una nueva partición y montarla al inicio, no? Y luego crear ahí dentro los directorios que fuera necesario…
Creo que con esto ya estará bien de preguntas… espero no haberme excedido mucho.
Gracias de nuevo.
Me gustaMe gusta
Supongo que te refieres al siguiente apartado del link, donde dice:
Al actualizar el sistema mediante apt-get, yum, pacman...etc. ésta baja los archivos al disco y luego los instala. Si por ejemplo tenemos programas como chromium-dev o paquetes de un git que se actualizan cada poco tiempo, o por ejemplo en actualizaciones como KDE entera que son más de 400 megas y no queremos que se vayan descargando al SSD podemos cambiar la ruta de descarga de estos paquetes.[...]
En distros derivadas de Debian tendremos que modificar el archivo /etc/apt/apt.conf (crear si no existe) y modificar/escribir esta línea dir::cache::archives “ruta”;
Basta con que indiques una ruta que ya esté en el HDD. Por ejemplo, una carpeta en tu /home actual.
dir::cache::archives “/home/emilio/.updates”;Fijate que he incluído un punto antes del nombre de la carpeta para que sea un directorio oculto. Así no me molestará cuando abra mi carpeta personal. Como el /home está en el HDD, las actualizaciones se irán descargando a ese directorio, sin pasar por el SSD.
Otra opción sería crear un punto de montaje en fstab para que se descarguen a la RAM:
none tmpfs /updates size=5%,defaults 0 0E incluir esa ruta en el archivo de configuración de apt.
Me gustaMe gusta
Hola!
Vayamos por partes, como Jack el Destripador 🙂
Las optimizaciones que has hecho son correctas para tu equipo. Si quieres toquetear las particiones, mi recomendación es que uses GParted desde un LiveCD. Este programa respeta los datos en disco, así que podrás hacer cambios sin necesidad de formatear, reinstalar, etc.
El tamaño apropiado para una partición /home depende de dos factores: el número de usuarios que vayan a usar el equipo (dentro de /home, cada uno tiene su directorio, por ejemplo /home/emilio) y la cantidad de datos que almacene cada uno. Ten en cuenta que en la carpeta personal de cada uno también se almacenan los archivos de configuración de cada usuario (por ejemplo, el archivo donde se almacenan detalles como qué fondo de pantalla usa, cual es su imagen de usuario, qué perfil de energía emplea, etc. etc.). Todo eso suma un poco más también, así que mi recomendación es que seas previsor en este punto.
Si en el SSD ya tienes W7 quizás vayas algo justito de espacio para poner ahí tu home, pero si tienes espacio y lo quieres hacer, se puede (no lo aclaro aquí porque es algo largo de más, pero vuelve a preguntarme).
No debería darte ningún problema pasar los temporales a la RAM, siempre y cuando edites el archivo /etc/fstab de forma correcta (por ejemplo, no asignar más espacio para /tmp de la cantidad de RAM que tengas, como es evidente). Si sigues los pasos de la entrada lo conseguirás sin ninguna dificultad, y en caso de que te encuentres algún problema, siempre puedes revertirlo editando de nuevo el archivo.
Las técnicas de journaling hacen muchas operaciones de escritura y lectura adiccionales para verificar si algo se grabó correctamente en el disco.
Imagina que estas trabajando y de repente tu equipo se bloquea/apaga/reinicia. Al encenderlo de nuevo, el sistema operativo hará algunas comprobaciones de disco. Si estás usando journaling, estas comprobaciones son mucho más rápidas. Yo creo que para el usuario común es algo prescindible, y eso alargará un poco más la vida de tu SSD (desgraciadamente no tengo información sobre cuanto más, porque es algo muy dificil de medir). Al igual que con lo anterior, el journaling se puede activar o desactivar. Simplemente sigue los pasos y quita el acento circunflejo, por ejemplo:
$ sudo tune2fs -O has_journal /dev/sda1Me gustaMe gusta
Que sorpresa!!!
No esperaba que me respondieras tan rápido. He estado leyendo tus respuestas y ya voy teniendo todo un poco más claro en el sentido de que, teniendo en cuenta que todas son operaciones reversibles, no pasa nada por probar. Si no hay mayores problemas nos ahorramos unas escrituras de más en el disco.
Igual lo que descartaría es pasar /home al SDD, por la cosa del espacio disponible. Aunque no creo que el equipo vaya a tener más de dos usuarios y la cuenta de invitado, como mucho, y el Windows, básicamente, está para juegos. Para cuestiones «irresolubles» en Linux me arreglaría con una máquina virtual, pero los juegos aún no tienen alternativa. No sé hasta que punto puede aumentar la velocidad de ejecución del sistema tener /home en el SSD, la verdad, pero el aumento de las velocidades de ejecución incluso así es tremendo (en Windows es donde más se nota, Ubuntu ya iba muy bien). Si cambiase de opinión te preguntaría, claro.
En relación a las descargas de actualizaciones, me queda la duda de lo que pasa con los ya descargados (el sistema lleva instalado dos semanas). ¿Se mueven a la nueva ubicación o se quedan donde se descargaron inicialente? Y en el caso de que no se movieran, ¿el sistema no se pondrá tonto si quisiéramos hacer un downgrade de alguna cosilla?
Gracias mil por responderme.
Me gustaMe gusta
Hola de nuevo!
Si pasas las descargas de actualizaciones a un directorio en RAM, las que ya se han descargado antes no se mueven. Si te gusta trastear un poco con la paquetería y actualizaciones mediante PPA, downgrades, etc. entonces yo las dejaría en un directorio del HDD, para que vayan quedando ahí guardadas por si de repente quieres restaurar una version anterior.
Gracias a tí por tus comentarios 🙂
Me gustaMe gusta
Gracias de nuevo.
Respecto al tema de las descargas de actualizaciones, no es que me guste trastear, ni mucho menos, munca hice un downgrade y no tengo intención de hacerlo salvo que en algún momento pueda necesitarlo. Básicamente es por aquello de que si los tienes y no los necesitas, que se le va a hacer, pero si los necesitas y no los tienes… La solución será pasarlos a un directorio en el HDD.
Aún no me he puesto a hacer los cambios, y posibemente tampoco será la próxima semana, porque tengo la agenda un poco sobrecargada. En cualto me ponga en faena te cunto como fué.
Además de estas cosillas, tengo algunas dudas sobre mi gráfica Nvidia, sus drivers privativos y el modo en que están funcionando desde las últimas actualizaciones (tanto de Ubuntu como de Nvidia), pero esta entrada no parece el sitio adecuado y no encontré en el blog un sitio donde encajen bien. ¿Podría preguntarte alguna cosa sobre este tema?
Mil gracias.
Me gustaMe gusta
Por supuesto!
Sobre las gráficas Nvidia, hay mucha info en este post:
https://emiliodevesa.wordpress.com/2013/03/11/nvidia-optimus-primus-linux-bumblebee/
Está escrito para hacer funcionar gráficos «Optimus» en Linux, pero hay muchos comentarios que también contienen información interesante; seguro que es un buen lugar para plantear otras dudas 🙂
Me gustaMe gusta
Mi equipo no lleva una optimus, es es de sobremesa y tiene una GTS 450 de 1 GB.
En cuanto pueda echo un vistazo en la entrada que me sugieres.
Muchísimas gracias.
Me gustaMe gusta
Pues bien, ya hoce las modificaciones que faltaban.
1º He pasado los temporales a RAM siguiendo tus indicaciones:
none /tmp tmpfs size=5%,defaults 0 0
none /var/tmp tmpfs size=5%,defaults 0 0
En principio todo parece haber ido bien.
2º He desactivado el journaling. El sistema sigue en pié, lo que pasa es que no sé interpretar lo que me devuelve el comando para comprobar errores, que es lo siguiente:
e2fsck 1.42 (29-Nov-2011)
e2fsck: Superbloque es inválido, intentando los bloques de respaldo…
e2fsck: Bad magic number in super-block mentres se tentaba abrir /dev/sda1
El superbloque podría no ser leido o no describe un sistema de ficheiros ext2 correcto.
Si el dispositivo es válido y en verdad contiene un sistema de ficheiros ext2 (y no uno
de intercambio, ufs o algo más), entonces el superbloque está corrompido
y podría intentarse ejecutar el e2fsck con un superbloque alternativo:
e2fsck -b 8193
Necesito un traductor para esto.
3º Intenté pasar las descargas de actualizaciones al HDD, pero no funcionó. Probé con dos carpetas distintas con nombres distintos, en ambos casos ocultas en mi directorio personal y al intentar actualizar me decía que estaba esperando a que terminase otro gestor de actualizaciones. Resultado, de momento borré la línea de /etc/apt/apt.conf y volvió a funcionar todo bien. Igual es q
Me gustaMe gusta
Perdón, es que lo envié sin querer…
…decía que igual es que se estaba todo reajustando y no di tiempo a que se movieran los archivos preexistentes, no sé. El caso es que, como daba error, borré la línea y todo de nuevo funcionando.
Gracias mil otra vez.
Me gustaMe gusta
Ejem, ejem!!!
Menuda chorradita te dije antes respecto del journaling. Efectivamente ejecuté el comando en la consola pero no tuve en cuenta que mi partición raíz de Ubuntu es sda3 (las dos primeras las ocupa Windows 7). Disculpa el despiste.
Dicho lo anterior, al escribir bien el nombre de la partición me dice lo siguiente:
e2fsck 1.42 (29-Nov-2011)
/dev/sda3 está montado.
WARNING!!! The filesystem is mounted. If you continue you ***WILL***
cause ***SEVERE*** filesystem damage.
¿De verdad quiere continuar??
Debo continuar o no? Lo que yo entiendo es que la cosa tiene cierto riesgo con la partición montada.
Graciassssssssss.
Me gustaMe gusta
Efectivamente no puedes hacerlo con la partición montada, así que deberías hacerlo utilizando un Live CD/USB de Ubuntu (o prácticamente cualquier otra distro). Arranca tu PC con el live usb, accede a una ventana de terminal y vuelve a ejecutar e2fsck.
Respecto a la carpeta de apt, parece que el proceso de actualización se estaba ejecutando en segundo plano. Tal vez funcione si lo vuelves a intentar. Cambia la linea y reinicia el ordenador.
Me gustaMe gusta
Saludos de nuevo Emilio.
Recuerdas cuando me comentabas lo siguinte:
«Si en el SSD ya tienes W7 quizás vayas algo justito de espacio para poner ahí tu home, pero si tienes espacio y lo quieres hacer, se puede (no lo aclaro aquí porque es algo largo de más, pero vuelve a preguntarme).»
Pues bien, estoy valorando hacerlo muy seriamente y te cuento por que. He notado que al hacer operaciones importantes de lectura y escritura en el HDD, es decir, del HDD al propio HDD (en concreto sucedió copiando una máquina virtual de unos 8GB), al sistema le cuesta muchísimo leer las configuraciones en /home y se atranca, has ta el punto de que Chrome, por ejemplo, no es capaz de abrir el correo electrónico e informa de que no se ha podido leer el perfil o algo así. Solo me ha pasado con archivos de gran tamaño, como estos, pero parece que el riesgo potencial de que se atranque el sistema está ahí.
Si como creo, se trata de que las operaciones de lectura y escritura dentro del mismo disco mecánico lo dejan medio inutilizado mientras estas operaciones no terminan, la solución sería que el /home y, por lo tanto, todas las configuraciones estuviesen en el SSD y el grueso de los archivos en una partición exclusiva del disco mecánico.
Me planteo dos opciones:
1ª Redimensionar particiones en el SSD y levarme ahí el home, para lo cual, teniendo en cuenta que hablamos de un sólo usuario, o como mucho dos con los archivos en otro lugar (más la cuenta de invitado), reservaría unos 20GB para / y otros tantos para /home. Para esto necesitaría ayuda, por supuesto.
2º Redimensionar la partición de Windows para dejar 40GB libres en el SSD y reinstalar todo con el / y /home en el SSD. Dado que ya tengo 3 particiones MBR me quedaría el sitio justo para una cuarta (a no ser que rehaga todo con particiones GPT). Naturalmente, los archivos se irían al HDD.
Que me aconsejas?
Saludos y gracias!!!
Me gustaMe gusta
Hola de nuevo!
Para redimensionar particiones, nada mejor que gparted, que las redimensiona sin perder datos. Como siempre, lo puedes instalar con:
$ sudo apt-get install gpartedaunque te recomiendo que lo hagas desde el Live CD de Ubuntu por dos motivos: ya viene instalada y te permitirá modificar la partición de Ubuntu si optas por hacerlo (desde el sistema instalado no, ya que me parece que se necesita desmontar la partición).
Es la segunda vez que en el blog sale el tema de mover un /home. Hace tiempo chiquishita me hizo una pregunta similar. En mi respuesta le proponía un link con instrucciones en español de la comunidad de ubuntu; pero tal vez sea el momento de que yo mismo aborde este tema. Quizás más adelante escriba una entrada sobre ello. Por ahora, procura seguir las instrucciones del enlace.
Un saludo!
Me gustaMe gusta
Sobre Gparted, era lo que tenía en mente, por supuesto. Con el acostumbro a dejar listas las particiones antes de cualquier instalación de Linux. Imagino que no habrá problemas con el Windows, lo digo por el tema de la fragmentación, básicamente porque no tengo idea de como les afecta a los SSD más allá de que no influye en el tiempo de acceso a los datos.
Sobre el movimiento de la partición imagino que todo será probarlo y, si no saliese bien, reinstalar y listo. Aunque el tutorial es algo antiguo, lo digo por los discos IDE, supongo que solo habría que cambiar hda por sda, no?
Muy agradecido, Emilio.
Me gustaMe gusta
Efectivamente, basta con que utilices el identificador adecuado. Si quieres asegurarte, basta con hacer:
$ sudo fdisk -lpara listar dispositivos y particiones, por si tu sistema les diese identificadores diferentes a lo que cabría esperar.
Por otra parte, Gparted es una herramienta que no destruye datos, sino que los mueve en caso de ser necesario, así que no te preocupes por la fragmentación en Windows, el propio particionador se encarga de mover lo que sea preciso.
Me gustaMe gusta
Para el método propuesto en la guía que aconsejaste a chiquishita yo tengo un problemilla, y es el problema gráfico del que te hablé en los comentarios a otra entrada sobre cuestiones gráficas (https://emiliodevesa.wordpress.com/2013/03/11/nvidia-optimus-primus-linux-bumblebee/). Me ha dado bastante yuyu hacer pruebas con esto, porque ya me cargué varias veces el grub tocando cosas resoluciones y confieso que me da algo de yuyu cargármelo de nuevo.
Pero mejor te cuento mis dudas en la entrrada correcta.
Me gustaMe gusta
Saludos Emilio.
He estado mirando la posibilidad de hacer el cambio de partición del /home desde un LiveCD y, francamente, veo muchos tutoriales para mover el directorio cuando se hace la instalación por defecto, es decir, cuando el /home es un directorio dentro de /.
Y leyendo sobre esto, vino a mi memoria un tutorial del blog Ubuntu-Guía en el que juanetebitel explica muy bien como usar el Gparted. Entre otras cosas cuenta como utilizar Gparted para hacer un backup de una partición, simplemente copiando y pegando de una partición X a otra vacía de igual o mayor tamaño (lo que no sé es si hablamos de tamaño de la partición o de la info que hay dentro de ella, es decir, que del tamaño ocupado).
Y digo yo, que a lo mejor es una tontería muy grande, haciendo eso mismo y luego modificando el punto de montaje en el fstab funcionaría?
Me gustaMe gusta
Hola,
Probablemente funcione bien sin mayores problemas. Desconozco si el procedimiento se puede hacer con Gparted o cómo se ha de llevar a cabo; pero sí que lo he hecho (con éxito) en más de una ocasión con partimage. más info en este link:
https://emiliodevesa.wordpress.com/2011/03/05/backup-del-disco-partimage/
Un saludo!
Me gustaMe gusta
Respecto de la comprobación del disco, lo consultaré en cuanto tenga un minuto. Imagino que saldrá todo bien.
Respecto de la carpeta de apt, cambiaré la línes y lo dejaré un tiempecito. Reiniciar había reiniciado ya en mis intentos, pero ejetuté el actualizador nada más arrancar el equipo y a lo mejor debería haber esperado un poquito.
Te contaré como va.
Agradecido estoy.
Me gustaMe gusta
He estado mirando algo sobre esto, y quizás te ayude el siguiente link:
http://abz89.wordpress.com/2010/02/11/change-an-apt-cache-folder-location/
Me gustaMe gusta
Por fin acabo de hacer la comprobación de la partición que recomiendas al desactivar el journaling ($ sudo e2fsck -f /dev/sda1) y me devuelve lo siguiente:
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: 262471/1607520 files (0.2% non-contiguous), 1828250/6426368 blocks
Supongo que todo estará en orden, no?
Gracias, me estás ayudando muchísimo.
Me gustaMe gusta
Sí, todo está correcto ahora. Como ves, e2fsck no ha informado de errores en la partición tras desactivar el journaling.
Me gustaMe gusta
He visto el link, pero tengo un problema…. a pesar de lo escurto del texto, no entiendo inglés… cuando yo estudiaba la antigua EGB (ya llovió muuuuucho ya) en mi colegio no se impartía inglés… y aún pasaron unos añitos hasta que empezó a impartirse desde que yo me fui.
Entiendo que no me habla de comandos literales para hacer un copy-paste, sino que hay partes que tendría que sustituír por lo que corresponda en mi caso. Si es así necesitaré ayuda.
Por otra parte, no sé si el tamaño de los archivos a descargar y las escrituras que ello supone justifican realmente que haga la modificación. En este punto necesito asesoramiento.
Graciassss
Me gustaMe gusta
Bien, si los adaptamos a tu caso para cambiar la ruta de forma permanente:
$ sudo mkdir .actualizaciones$ sudo mkdir .actualizaciones/partial
Tras eso, editamos el archivo como decíamos antes:
dir::cache::archives /home/usuario/.actualizacionesMuévelo al HDD si sueles instalar mucho software (por línea de comandos, desde el centro de software, … eso da igual) ya que además de los paquetes que instales irán llegando las actualizaciones. Esto también incluye a todo lo que instales mediante repositorios PPA. Mi recomendación desde luego es que lo hagas.
En primer lugar porque en ese directorio se descargan las actualizaciones y eso no va a afectar al rendimiento de tu sistema (porque este funciona desde el SSD) y en segundo lugar por ahorrarse escrituras y espacio en el SSD (sobre todo si por ejemplo te descargas algo grande o con muchas dependencias).
Me gustaMe gusta
Para certificar si lo entendí bien, ejecutaríamos en consola:
$ sudo mkdir .actualizaciones
Luego, también en consola, tal cual:
$ sudo mkdir .actualizaciones/partial
Luego, en consola, editamos el apt.conf, tipeando, por ejemplo:
$ sudo gedit /etc/apt/apt.conf
Añadimos la línea:
dir::cache::archives /home/usuario/.actualizaciones
Guardamos, cerramos, reiniciamos y ya estará?
Muchiiiiísimas.
Me gustaMe gusta
Ah! Y en el caso de que tuvieramos que deshacer lo hecho?
Gracias.
Me gustaMe gusta
Efectivamente, ese es el proceso.
Para deshacerlo, basta con borrar la línea que has añadido al archivo y borrar los directorios creados. Para esto último:
$ sudo rm -rf .actualizacionesMe gustaMe gusta
De acuerdo pues.
Si me queda algo de energía esta noche me pongo con ello y te cuento.
Muchísimas gracias.
Me gustaMe gusta
No ha funcionado. El asistente no se iniciaba y en el área de notificaciones aparecía un indicador rojo de error gordote.
Como curiosidad, aunque no sé si tiene relevancia, te comento que el propietario del directorio principal que se creó era el usuario root aunque estaba dentro de mi directorio persoal.
Para revertir los cambios borré la línea añadida y la carpeta.
El asistente para actualizaciones funciona de nuevo.
Probaré otra vez el primer método a ver lo que pasa, pero ya no será hoy, que mi cerebro ya no da para más.
Me gustaMe gusta
Ah! Y muchas gracias!
Me gustaMe gusta
Bien.
Ya puedo certificar que no me han funcionado ninguno de los dos métodos que hemos utilizado para mover los paquetes descargados al HDD.
Lo he probado en mi equipo y en una máquina virtual (obviamente, en este caso no hay HDD pero para el caso, el /home sería lo mismo, entiendo) y en ninguno de los dos ha funcionado, con los mismos síntomas en ambos casos.
Muchas gracias, en cualquier caso, porque aunque esta modificación no he podido hacerla, todo lo demás ha ido fantásticamente. Lástima no haber podido hacer este último cambio.
Seguiré buscando y en el caso de algún método me funcione lo comentaré en esta entrada.
Me gustaMe gusta
Lo prometido es deuda.
El otro día comenté que si encontraba un método que funcionase lo comentaría en la entrada. Lo cierto es que no lo encontré en la web, sino que me lo pasó un compañero de trabajo.
La cosa consiste en crear un enlace simbólico mediante un script. Lo podríamos hacer con Gedit, por ejemplo, escribiendo lo siguiente (los comentarios son de mi compañero, cada uno puede personalizarlos a su gusto):
#!/bin/bash
sudo mv /var/cache/apt/archives ~/
sudo mv ~/archives ~/.archives
sudo ln -s ~/.archives /var/cache/apt/archives
echo «Feito.»
Lo guardamos con el nombre que queramos y con la extensión .sh, para utilizarlo le damos antes permisos de ejecución haciendo clic derecho sobre el archivo, clicando en «Propiedades», seleccionando la pestaña «Permisos» y marcando la casilla «Permitir la ejecución del fichero como un programa». Ahora, ya con los permisos, al hacer doble clic sobre el archivo nos preguntará si deseamos ejecutarlo o mostrar sus contenidos; nosostros pulsaremos sobre «Ejecutar en una terminal», nos pedirá nuestra contraseña, la escribimos, pulsamos enter… et voilà.
Dicho lo anterior, para revertir el proceso, podemos hacer otro script, siguiendo los mismos pasos que con el anterior, pero en este caso con el siguiente texto:
#!/bin/bash
echo «(acento texano) Estamos trabajando en ello»
if [ -h /var/cache/apt/archives ]; then
sudo rm /var/cache/apt/archives
fi
if [ -d ~/archives ]; then
sudo mv ~/archives /var/cache/apt/archives
fi
if [ -d ~/.archives ]; then
sudo mv ~/.archives /var/cache/apt/archives
fi
echo «Feito.»
Reproduzco los comentarios coñones de mi compañero literalmente, pero cada uno puede escribir lo que quiera.
Espero haber ayudado a alguien.
Muchas gracias por todo, Emilio.
Me gustaMe gusta
Saludos de nuevo.
Olvidaba aclarar que lo que estamos haciendo con este script es mover los paquetes descargados a una carpeta en el home (que estará oculta y se llamará .archives) independientemente de donde se encuentre este.
Naturalmente, si nuestro home está dentro del propio SSD y lo que queremos es evitar que estos paquetes se escriban en el, habría que modificar el scrip de tal modo que los escribiesen fuera del SSD en la partición que eligigiesemos.
Saludos.
Me gustaMe gusta