Así pues con VirtualBox y una imagen de Ubuntu JeOS me he puesto manos a la obra. Ubuntu JeOS se puede instalar con lo básico para que funcione en una máquina virtual. Aunque en el site de Ubuntu se dice que está optimizado para correr en VMWare o KVM funciona perfectamente en VirtualBox, eso sí, en teoría debería rendir mejor en los dos anteriores. La instalación es bien simple, únicamente como paso previo hay que activar en la maquina virtual que creemos para dicho propósito la opción “Habilitar PAE/NX” que se encuentra en “System->Processor”. Si no activamos esta opción al acabar la instalación el kernel de Ubuntu JeOS no arrancará. Otra cosa también importante es configurar correctamente la red para que el anfitrión pueda conectarse a los servicios del guest. Para ello en la máquina virtual que hayamos creado en VirtualBox hay que configurar la tarjeta de red como “Adaptador Puente (Bridge)”, opción que está en “Red->Adaptador 1->Attached To”.

Durante la instalación podremos elegir los paquetes que queramos instalar, en mi caso los necesarios para que funcione una configuración LAMP con OpenSSH. Una vez finalizada arrancamos la máquina virtual y listo. Podremos utilizarlo directamente pero mucho mejor si nos conectamos por ssh (así mejor ya que cuando se implante realmente la máquina que hará de servidor no tendrá ni monitor xD).

Puesto que el servidor algún día será público desde Internet necesitaba una forma de tener un nombre de dominio asociado con mi IP dinámica. He bajarado dos posibilidades: No-IP.com y DynDNS.com. Ambos servicios ofrecen lo mismo, podremos crearnos de forma gratuita un subdominio (hasta 5 son gratis) que apuntará a nuestra IP dinámica y mediante un cliente corriendo en nuestro servidor cada vez que cambie la IP se actualizará el subdominio para que apunte a la nueva IP. En Ubuntu por lo visto existen paquetes para los dos que podemos instalar a través de “apt-get”. El inconveniente de No-IP.com (que no lo es tanto) es que deberemos configurar la frecuencia con la que deseamos que se actualice nuestra IP. Por ejemplo, si ponemos un tiempo de 15 minutos y nuestra IP cambia pasados 9 minutos… aún tendremos que esperar 6 minutos hasta que se haga la comprobación. Por tanto, estaríamos 6 minutos caídos. Obviamente si configuramos la frecuencia para que se actualice cada minuto este problema casi desaparece, sin embargo, a mi no me gusta estar cada minuto realizando comprobaciones. Por suerte, mi router (Comptrend 536+) soporta el servicio de DynDNS con lo cual (tras registrarme y crear mi subdominio) lo he configurado directamente en el router. De esta forma, cada vez que el router obtenga una nueva IP actualizará la IP en DynDNS y no tendrá que estar periódicamente haciendo comprobaciones.

Finalmente, con todo funcionando le ha tocado el turno a Apache. La verdad que lo había tocado poquito pero con eso que sabía y lo que he podido encontrar en la documentación me ha dado lo suficiente como para configurar varios dominios virtuales. Con esto, es posible tener bajo un mismo servidor Apache varios nombres de dominio compartiendo una misma dirección IP. La idea aquí será la de ir moviendo a este servidor poco a poco algunos dominios que tengo en DreamHost, pero me da que hasta que eso ocurra todavía pasará un tiempo ya que antes habría que estudiar el tema de la seguridad. De todas formas, con lo que llevo visto por ahora Apache me está dejando un buen sabor de boca y, además,  deja entrever la gran flexibilidad de configuración que tiene, lo cual es de muy agradecer.

En fin! esto es todo por ahora, la idea de este post era un poco comentar mis planes . Cuando ya se vaya consolidando y de verdad pase a la super máquina ya iré comentando mis experiencias (realmente nada que no le haya pasado antes a alguien pero bueno, mi blog mis reglas xD).

Saludos!

En verdad no es algo nuevo, Gilles Schintgen informó de este “error” el 9 de Septiembre de 2006, es decir, hace 2 años y 3 meses aproximadamente. El bug involucraba a los paquetes acpi-support, laptop-mode-tools y pm-utils resultando afectadas múltiples distribuciones: Baltix, Fedora, Mandriva, Debian, Suse y Ubuntu entre otras. La peor consecuencia de este bug es que puede acortar la vida útil de tu disco duro.

NOTA - Hay que advertir también que este error no solo afecta a los discos duros de portátiles, sino que afecta a todos aquellos que hagan uso de la técnica del Head Parking (aparcar los cabezales, se explica luego), no obstante este artículo se centra en los equipos portátiles por ser usados cada vez por más gente habiendo superado en ventas a los PCs de sobremesa.

Introducción

Al igual que otros componentes de un ordenador portátil, un disco duro moderno también tiene un sistema de ahorro de energía, el cual se encarga de ahorrar energía cuando se detecta un período de inactividad. El disco duro está permanentemente en rotación, y por tanto, una de las formas que estos discos tienen para ahorrar energía es dejar de dar vueltas (spin down). Además de esto, cuentan con otro método para proteger al disco duro ante golpes o cuando estamos en movimiento, lo explico:

Para leer y escribir en un disco duro se coloca sobre el disco en rotacion un cabezal de lectura/escritura, este cabezal tradicionalmente quedaba suspendido sobre el disco incluso cuando no se estaba utilizando. La separación entre el disco (realmente uno de los platos del disco duro en caso de tener varios) y el cabezal de lectura/escritura es tan pequeña que al mover el disco duro estos dos componentes podrían llegar a tocarse provocando daños en el disco y en el cabezal. Para evitar esto, cuando se detecta un período de inactividad se retira el cabezal a una zona segura fuera de la superficie del disco (head parking).

Spin Down Time, Head Parking Time y Load Cycle Count

El disco duro para cada uno de los dos métodos mencionados arriba, spin down y head parking, tiene definido un tiempo mínimo de inactividad antes de que entre en funcionamiento la medida correspondiente, estos son el spin down time y head parking time.

Además de esto, el disco duro (con tecnología S.M.A.R.T.) puede monitorear su funcionamiento y llevar un registro de su actividad. Uno de los parámetros más importantes es el número de veces que el cabezal se desaparca (load), valor que se conoce como Load Cycle Count, y que está limitado a un número determinado de veces. El motivo por el cual el movimiento de aparcar/desaparcar el cabezal está limitado se debe a que el disco duro tiene partes mecánicas y como cualquier máquina mecánica sus piezas se desgastan con el uso.

El problema

El problema es que, al parecer, algunos discos duros realizan frecuentemente el movimiento de aparcar/desaparcar acortando significativamente su vida útil. Esto se debe a que el temporizador de este movimiento está configurado de forma tan agresiva (el head parking time tiene un valor muy pequeño) que frecuentemente detecta que el disco duro está inactivo aparcando el cabezal, y tras lo cual, se desaparca inmediatamente para realizar alguna operación de lectura/escritura sobre el disco provocando que el Load Count Cycle se incremente muy rápidamente.

En un disco duro de un portátil moderno el Load Cycle Count está limitado por el fabricante a un número de 600.000 veces, es decir, si realizamos un uso del disco duro de 24 h al día durante 2 años se tendría que aparcar/desaparcar el cabezal una vez cada 1 min. 45 seg. para llegar al límite de 600.000 (aprox. 34 veces / hora). Este comportamiento sería considerado normal en portátiles ya que así ahorran batería y puesto que un portátil no se usa 24 h al día, si suponemos un uso de 12 h / día, se tendría una vida útil de 4 años antes de alcanzar este límite.

Por tanto, se considera que un disco duro está funcionando mal cuando debido a este error el tiempo de vida esperado es inferior a 2 años, o lo que es lo mismo, el Load Cycle Count se incrementa más de 34 veces por hora.

De igual forma, este problema suele aparecer con mayor frecuencia cuando el portátil no está conectado a la toma de corriente, es decir, cuando únicamente tira de la batería. Aun así, hay muchos casos en los que indistintamente de que esté o no esté conectado el Load Cycle Count se incrementa muy rápidamente. En mi caso, ASUS G1 con Ubuntu Hardy, únicamente sucede cuando está desconectado de la toma de corriente.

Estado actual

Aunque este problema afecta a todos los Sistemas Operativos, por lo visto este problema es más visible en GNU/Linux, dicen algunos, debido a que es más eficiente a la hora de leer/escribir en el disco duro (el tiempo de sincronización de los buffers con el disco duro es mayor que el tiempo que el head parking time).

Desde que se informó de este error mucho ha llovido pero por lo visto el problema, aunque se ha trabajado en el, sigue sin haberse solucionado (a fecha de feb, 2009):

• Mandriva – Por lo visto sigue sin solución aunque se informó el  31-10-2007, la última modificación fue el 28-07-2008 y por lo reflejado en su estado (new) parece que todavía no ha sido asignado.

• Suse – Aparece como abierto desde el 04-05-08 y modificado el 04-07-2008, sin embargo el estado aparece como “resuelto” y el último comentario también de la misma fecha nos remite a http://ata.wiki.kernel.org/index.php/Known_issues para informar de nuevos problemas relacionados con este bug pues, dicen, “no es específico de SUSE”.

• Debian – Abierto el 31-10-07 y fusionado con el bug 448710 aparece como “solucionado”. Debian siempre me sorprende .

• Fedora – Abierto el 20-11-07 y modificado el 04-02-2008, increíblemente tiene el estado “not a bug”, lo cual se explica leyendo los comentarios donde aparece lo siguiente “reasignado este bug al componente del kernel ya que es un bug de ese componente”, “ese valor es puesto por la BIOS del sistema al encenderse, nosotros nunca lo cambiamos (otras distribuciones lo hacen pero Fedora no)”.

• Ubuntu – Parece ser que fue la primera donde se reportó, el 09-09-2006 y todavía sigue sin una solución permanente. Se han realizado múltiples soluciones temporales para las versiones afectadas, que al parecer son Hardy e Intripid, en las cuales en algún momento se marcó el bug como “Fix Released”, pero sin embargo, vuelve a aparecer con estado “new” en Intrepid y Jaunty (la siguiente versión) y “critical” en hardy.

Responsabilidades

En un primer momento se pensó que este problema solo afectaba a Ubuntu, pero realmente es un problema que todas las distribuciones tienen que solucionar. Además, no sólo los usuarios de GNU/Linux son los afectados sino que a raíz de que se informase de este fallo, usuarios de Windows XP, Vista y MacOS X en algún momento han reportado este mismo error en sus sistemas. También es cierto que este error no afecta a todos los discos duros, más bien a aquellos que tengan una política muy agresiva de ahorro de energía.

Con todos estos factores no está claro que parte es la responsable. Por un lado los fabricantes con discos duros que aplican políticas agresivas de ahorro de energía asumen que el Sistema Operativo va a administrar correctamente esta característica, de tal forma que si el disco duro aparca el cabezal el sistema lo detecte y postponga las escrituras a un buffer en memoria que, pasado un tiempo prudencial, debería sincronizarse con el disco duro.

Por otro lado, muchas de las distribuciones de GNU/Linux, entre ellas Ubuntu, tienen la política de no cambiar la configuración de fábrica que traen los discos duros, pues consideran que la configuración que realiza el fabricante es la mejor, pues ellos son los que han fabricado el dispositivo.

A su vez, las distribuciones GNU/Linux utilizan más frecuentemente el disco duro debido a tareas de monitorización, logs, etc, despertando continuamente al disco duro.

Sin embargo, algunas distribuciones como Suse, dicen que este error debería solucionarse dentro del Kernel Linux, de modo que se controlen las escrituras cuando el cabezal está aparcado. Sobre esto último, ya se han iniciado algunos trabajos, mantiendo una lista de discos duros afectados para que el kernel lo configure de la forma más apropiada.

¿Como sé si estoy afectado?

Una forma de conocer si se está afectado por este error es comprobar si cada poco tiempo nuestro disco duro produce un repentino ruido, similar a un chasquido. Pero para asegurarlo, en GNU/Linux la forma de saber si este problema está afectando al disco duro es por medio de la utilidad smartctl. Ejecutando el siguiente comando se obtiene el número de veces que se ha aparcado el cabezal:

$ sudo smartctl -a /dev/sda | grep Load_Cycle_Count

Y con este otro se obtienen las horas que nuestro disco duro ha estado encendido:

$ sudo smartctl -a /dev/sda | grep Power_On_Hours

Si se divide el Load_Cycle_Count por el Power_On_Hours y se obtiene un valor mayor que 34, entonces el disco duro está afectado por este problema.

Solución temporal

Hay varias soluciones temporales para este problema, pero básicamente todas consisten en configurar el disco duro para que no aparque el cabezal y nunca deje de girar.

Se considera peligroso al hecho de hacer que el disco duro deje de girar, ya que el estar continuamente girando provoca que la temperatura del mismo aumente. Por eso se recomienda, de aplicarse esta solución, el monitorizar continuamente la temperatura del disco duro para comprobar que no supere la temperatura máxima especificada por el fabricante.

En mi caso cuando estoy con la batería y el disco duro tiene un rato de inactividad, primero se aparca el cabezal y posteriormente deja de girar. Para evitar que esto ocurra hay que ejecutar el siguiente comando:

$ sudo hdparm -B 254 /dev/sda

donde “/dev/sda” ha de cambiarse por el dispositivo del disco duro en cuestión.

Con este comando lo que se está haciendo es cambiar el modo de ahorro de energía del disco duro al menos agresivo. Un valor de 255 supondría la desactivación completa, pero en algunos discos duros esto no funciona, por eso lo que le funciona bien a la mayoría es un valor de 254. Para más información consultar la página del manual de hdparm ($ man hdparm).

Como observación, cabe añadir que cuando mi portátil está enchufado a la corriente el disco duro nunca deja de girar, y este mismo comportamiento lo he observado en Windows XP indistintamente de si está funcionando sólo con batería o no.

Notas

A lo largo de este artículo se ha visto en que consiste este problema, el estado actual del mismo y una solución temporal. Si bien, las distribuciones y el kernel están trabajando para solucionarlo de la forma correcta, este problema afecta a todos los sistemas operativos, en mayor o menor grado, por lo que no debería ser un motivo para cambiar de un sistema operativo a otro. Como usuario de [K]Ubuntu, puedo confirmar que en mi sistema con Hardy este problema no se ha solucionado, sin embargo, tras la publicación de este artículo daré el salto a Intrepid, realizando una instalación limpia del mismo, para realizar las mismas pruebas y comprobar si sigue afectado o no, para posteriormente publicar los resultados.