PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Share a file Manage my documents Convert Recover PDF Search Help Contact



Optimizar.una.Mandriva.o.una.Mageia.instalada.en.un.Disco.de.Estado.Sólido SSD .pdf



Original filename: Optimizar.una.Mandriva.o.una.Mageia.instalada.en.un.Disco.de.Estado.Sólido-SSD.pdf

This PDF 1.4 document has been generated by Writer / LibreOffice 3.5, and has been sent on pdf-archive.com on 12/07/2012 at 05:40, from IP address 190.20.x.x. The current document download page has been viewed 949 times.
File size: 537 KB (7 pages).
Privacy: public file




Download original PDF file









Document preview


Optimizar Mandriva o Mageia si es instalada en un Disco de Estado Sólido - SSD
Con lo de “Optimizar nuestras chicas ñuLinux” me refiero a las prácticas que se deben aplicar posterior al
particionamiento e instalación de la distro en equipos con uno o más discos de estado sólido SSD (Solid State
Drive), como siempre, antes de hacer cualquier cosa debemos asegurarnos de tener correctamente
configurados los repositorios, y de haber aplicado su correspondiente primera actualización, después que
todo lo anterior se haya cumplido de manera satisfactoria, pasamos a activar TRIM en las opciones de
montaje del sistema, agregamos algunos ajustes varios, principalmente en el fichero fstab, que es donde se
listan los discos y particiones del sistema... ¡y un par más!, el porque de esto es muy simple, a diferencia de
los clásicos discos duros (HD) con partes móviles, los discos SSD, si o si, irán degradándose con el uso por
tener un número limitado de ciclos de escritura. Los pasos son muy sencillos, aunque no por ello dejan de ser
algo peligrosos, esto si la tarea es emprendida por un usuario sin mayor experiencia con la consola y/o con la
edición de ficheros de configuración del sistema, lo bueno es que existen dos métodos de comprobación, uno
de ellos, el más simple, básicamente se refiere a si Mandriva/Mageia es capaz de volver a iniciar luego de
aplicados los ajustes xD, el otro método trata de chequear la correcta activación de una de las principales
características propia, y sobre todo, esencial en los discos SSD, me refiero a TRIM, herramienta que ayuda a
impedir la degradación del rendimiento gracias a negociaciones entre el disco y el sistema operativo,
comunicando qué bloques de datos ya no pueden ser utilizados, me refiero a los bloques/celdas expirados
y/o/u inutilizables.
En estricto rigor, en la actualidad TRIM está soportado desde la versión 2.6.33 del kernel Linux, claro que en
una wiki de Debian recomendaban utilizar kernel > 3,2 y en uan de Fedora > 3,0, en el lado oscuro está desde
Windows 7, y en el SO de los juguetes Apple, desde el 2011.
El problema es que desde mi experiencia personal, la cual no es más extensa que el tiempo transcurrido desde
que me compré mi disco SSD (hace menos de un mes basado en la fecha de envío de esta entrada),
desconozco si ñuLinux – para nosotros Mandriva y Mageia – particionan por primera vez un disco SSD
como es debido (y a decir verdad lo pongo seriamente en duda), y eso no es otra cosa que crear particiones
correctamente alineadas, básicamente significa que el primer particionado debe comenzar siempre (si o sí) en
el sector 2048, y que el sector de inicio del resto de las particiones sean siempre múltiplos de 512, se que
Windows 7 lo hace, el porqué de esto es simple, lo leí y lo comprobé empíricamente (por pura casualidad) al
instalar primero el lado oscuro en mi disco SSD, todo para poder jugar uno que otro FPS. Para saber si
Mandriva y Mageia lo hacen automáticamente, tendría que formatear de nuevo el disco, es decir, debería
olvidarme de todo el tiempo utilizado en la instalación de Mageia y win2, sus actualizaciones y por supuesto,
de la urticaria producida con el simple acto de piratearlo y perder otro montón de tiempo bajando drivers para
recién ahí poder configurarlo. :P

Requerimientos:





1 PC o portátil i386 compatible. :P
1 medio de instalación de Mandriva o Mageia (CD, DVD, Pincho USB, etc).
Particionar alineadamente e formatear en un sistema de archivos Ext4 (mi reciente experiencia dice
que con XFS también funciona, con ReiserFS no lo logré ni a la 1ª, 2ª, 3ª y tampoco al 20º intento).
1 disco SSD, el utilizado es un disco Kingston HyperX SSDNow de 120GB que costó lo mismo que
uno HD SATA3 de 3TB. XDDDD (todo por la speedionitis)

Primero voy a detallar los procedimientos en modo --verbose y luego en modo --quiet, es decir, en modo
copy&paste.

Procedimientos (modo --verbose).
Una captura del contenido del fichero fstab (en Mageia 2):

Cambios y agregados a realizar en fstab (como root vi /etc/fstab):


Agregar la opción discard, la cual activa TRIM en un sistema de ficheros Ext4 (Ext4 es
compatible con los discos SSD). Ver mount(8)
• Para LVM agregar la opción discard en /etc/lvm/lvm.conf. Ver lvm.conf(5).


Para dm-crypt agregar la opción discard en /etc/crypttab. Ver crypttab(5).



Agregar la opción nodiratime, así como noatime indica que no se actualice la hora de acceso a
un fichero. nodiratime es similar, solo que no actualiza la hora de acceso a directorios (por
ejemplo cuando se busca un fichero por su nombre).



Cambiar la opción relatime por noatime, esta reduce la escritura en el disco SSD ya que evita
que se les actualice el momento de acceso a los inodos o nodos índices, cosa que sucede
cuando se actualiza la fecha de modificación de un archivo (para los winluseros esto es como
aprender chino mandarín vía TTY). Ver mount(8)


Mageia 2 por defecto trae configurado el parámetro relatime




relatime: Reduce considerablemente el refresco de la fecha de acceso ya que
únicamente se modifica si el valor actual de atime es menor que la fecha de
modificación del fichero. Lo que se comenta en la red es que con ciertos
programas se generarían problemas, el único citado es mutt, el cual no funciona,
pero como yo creo no necesitarlo, definitivamente me decido por aplicar el
cambio.

¡Solo si poseemos una UPS (o un portátil, aunque desconozco si el kernel_laptop ya viene
optimizado, si es así, en /etc/sysctl.conf debería existir una línea conteniendo la cadena
vm.laptop_mode)!
Agregamos la opción commit=xxx, donde xxx son segundos, por ejemplo, si commit=600,
equivale a 10 minutos. Esta opción aumenta el tiempo de acceso (por escritura) a disco para
actualizar los cambios en Metadatos, por defecto el tiempo viene configurado a 5 segundos,
para explicar esto lo más sencillamente posible, digamos que con metadatos nos referimos a
diversos cambios a los que puede ser sometido un archivo, p.e., la escritura en disco de la hora
que indique la apertura más reciente del archivo fstab, otra por la modificación, etc, etc, etc...
En mi no hay UPS, pero de todos modos me arriesgo a configurarlo a 5 minutos. :P

Chequeando que TRIM se haya activado correctamente.
Lo primero que hacemos, como root y mediante una línea de comandos, es crear un fichero que
genera un simple archivo de texto conteniendo un rango de números que van desde 1 a 1000, y en
total pesa alrededor de 4 KB (el tamaño típico de un sector), esto en alguna de las particiones del
disco SSD en cuestión:


[root@mga2 ~] # seq 1 1000 > testfile

Con ese archivo creado, es el momento de saber qué sector de la(s) la unidad(es) se está(n) utilizando
mediante la siguiente línea de comandos:


[root@mga2 ~] # hdparm --fibmap testfile

Tomamos nota del primer valor listado en la columna titulada “begin_LBA”, que en este caso
resultó es 93727208, este valor corresponde el sector de inicio del archivo testfile.
Con el número de sector en la mano, ahora podemos comprobar su contenido mediante la siguiente
línea de comandos:
• [root@mga2 ~] # sync
• [root@mga2 ~] # hdparm --read-sector 93727208 /dev/sda

El comando 'sync' se debe ejecutar antes de 'hdparm' con la intención de vaciar el buffer del
sistema de archivos, una vez ejecutado, el comando hdparm mostrará en formato hexadecimal,
todo el contenido del sector determinado.
Ahora procedemos a eliminar el archivo testfile, posteriormente, ejecutamos los mismos comandos
que antes:




[root@mga2 ~] # rm -f testfile
[root@mga2 ~] # sync
[root@mga2 ~] # hdparm --read-sector 93727208 /dev/sda

Eso es justo lo que queríamos ver ... ¡Nada!, en estricto rigor, solo ceros como se aprecia en la
imagen.
Si no aparecen solo ceros ha de haber ocurrido lo siguiente:



No trabajamos correctamente en el fichero /etc/fstab, lo que significa que no se
activó TRIM.
No ejecutamos correctamente el comando sync.

Gracias a que a esta altura ya podemos encontrar varios manuales en la red sobre optimizar el uso de discos
SSD en ñuLinux, me he demorado menos en configurar TRIM en Mageia, que construyendo este manual,
pero como se puede ver, esto nos permite realizar pruebas de comprobación muy simples. Basta con añadir
unas opciones de montaje al archivo /etc/fstab, y ya podemos utilizar nuestro disco SSD.

Pero como en este mundo ñuLinux siempre podemos llegar hasta la médula, eso si tenemos ganas, todavía
hay tarea que hacer, esto nos permitirá seguir en nuestra línea, que no es otra que lograr la menos cantidad de
escritura en nuestro disco SSD para extender lo más posible si vida útil, que en teoría, el SSD utilizado en
este manual debiese durar por lo menos 114 años... mmmmm... lo mismo dicen de esas ampolletas
fluorescentes y la verdad es que ya perdí la cuenta con las que he debido cambiar en el transcurso de este
año, en fin, que dure unos 5 años con un 100% de rendimiento y estaré muy conforme. XD

Montaje en RAM:
A continuación haremos que el sistema monte un conjunto de directorios en RAM y no en el disco
SSD, hablamos de directorios cuyo fin es contener archivos temporales, eso significa que se escribirá
a disco muchas veces con datos que, de partida, ni sabemos que están ahí, tenemos por ejemplo el
directorio /tmp, /var/y/sus/subdirectorios, etc.
Los datos que debes agregar al fichero fstab son los siguientes:
tmpfs /tmp
tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/spool tmpfs defaults 0 0
tmpfs /var/cache tmpfs defaults 0 0
Hasta el momento, fstab se ha convertido en esto:

En los tutoriales en los que me base para obtener las configuraciones finales que me permitieran optimizar el
uso de un disco SSD, se citan 2 opciones de montaje, user_xattr y barrier=1, en este manual no indico como
agregarlos (aunque es obvio) ya que si ejecuto 'mount|grep /dev/sda', aparecen habilitados los 2.
Mandriva/Mageia, mediante su centro de control o CCM, nos permite indicarle al sistema que no mantenga
el contenido del directorio /tmp después de cada reinicio, en este caso, al montarlo en RAM, ya no sería
necesario tener habilitada dicha característica.
Si somos un usuario que suele decir al sistema que guarde los ficheros RPM luego de realizar cualquier labor,
p.e., del tipo instalación de aplicaciones o actualización del sistema, no deberíamos montar /var/cache en
RAM, sino que en algún otro disco no SSD local, o en red.
Caché de Firefox:
Como el caché de Firefox se escribe en /tmp, por lo tanto haremos que este se monte en RAM,
así minimizaremos que más adelante se escriba en el disco SSD con datos que usualmente, no
nos interesa conservar. Para configurar esto añadimos las siguiente 2 líneas de comandos a
/etc/rc.d/rc.local:
mkdir /tmp/mozilla-cache
chown ej /tmp/mozilla-cache

Captura del contenido final del fichero /etc/rc.d/rc.local:

Finalmente le indicamos a Firefox donde deberá escribir su caché, para ello se añade una nueva
Cadena (Key) de nombre browser.cache.disk.parent_directory vía about:config, y en su valor
agregamos la ruta /tmp/mozilla-cache.
Captura de about:config:

Configurar / Deshabilitar SWAP
En estricto rigor necesitamos deshacernos de swap, en mi caso poseo 8GB en RAM, cantidad más que
suficiente para permitirnos decidir que nuestro sistema no requerirá nunca de swap xD, por lo tanto la
eliminamos, eso dependiendo de si en el proceso de instalación de la distro, creamos o no una
partición Swap, yo hace rato que no lo hago, menos ahora que lo que se busca es evitar el máximo de
escritura en el disco SSD.
...en fin, Como este no es un manual de Swap, añadiré unas lista de comandos y un breve comentario
de lo que hacen, si necesitan más información, pídansela a google:
# swapoff -a
// Deshabilita, apaga swap – podría agregarlo en rc.local – swapon -a lo
reactiva, claro que debe existir una aprtición swap.
# echo " vm.swappiness=0" >> /etc/sysctl.conf
// Con esto debemos disponer de una partición swap habilitada, lo que hace es
evitar lo más posible que alguna aplicación use swap.
# echo " vm.oom_kill_allocating_task=1" >> /etc/sysctl.conf
// Con esto el sistema sacrifica uno o más procesos con el fin de liberar
memoria para el sistema cuando falla todo lo demás, es decir, si una aplicación pide
swap, ¡se muere! Simple no. ;)

Reducir Cache Writeback Time
Para ver el valor actual ejecutamos:
# cat /proc/sys/vm/dirty_writeback_centisecs; cat /proc/sys/vm/dirty_expire_centisec
// 500 – 3000 respectivamente.
Procedemos a cambiar el valor de dirty_writeback_centisecs, de 500 o cambiamos a 1500:
# vi /etc/sysctl.conf

Deshabilitando el servicio readahead
Para deshabilitar readahead ejecutamos:
# systemctl disable systemd-readahead-collect.service
# systemctl disable systemd-readahead-replay.service
# systemctl disable systemd-readahead-done.service

BiblioWebgrafía:













http://goo.gl/JL2tf
http://goo.gl/MEPpX
http://goo.gl/3ZK39
http://goo.gl/iMm0v
http://goo.gl/w36H8
http://goo.gl/NvTq3
http://goo.gl/Kxv8z
http://goo.gl/rfjq8
http://goo.gl/RL6fS
http://goo.gl/muz7y
http://es.wikipedia.org/wiki/Ext4
http://wiki.debian.org/SSDoptimization


Related documents


optimizar una mandriva o una mageia instalada en un disco de estado s lido ssd
optimizar una mandriva o una mageia instalada en un disco de estado s lido ssd 1
linux magazine
documento2
precios rm
que corredores de bolsa usan1283


Related keywords