SMART

Este artículo es principalmente una traducción del que me han publicado en Debian Package of the Day y que llegó luego a DebianTimes.

---

Uno de los paquetes que instalo manualmente en toda nueva instalación es smartmontools. Tengo cierta experiencia administrando ordenadores y redes, y es un hecho que los piratas informáticos y los fallos de los programas (bugs) no son la mayor causa de problemas en instalaciones pequeñas y medianas. Lo es el hardware.

Luego tenemos aparatos que pueden fallar, y Murphy dice que si algo puede fallar, fallará. El asunto no es evitar los fallos físicos, lo que es imposible, sino detectarlos rápidamente o incluso prevenirlos.

Particularmente para los discos duros, la herramienta encargada es smartctl del paquete smartmontools. Los discos IDE (si no son de la era de los dinosaurios) tienen una herramienta integrada de autoanálisis llamada SMART que significa“Self-Monitoring, Analysis and Reporting Technology” (Tecnología de Auto-Monitorización, Análisis e Informe). Los discos SCSI modernos también la tienen si son SCSI 3 o más nuevos. Lo que ocurre es que en la circuitería del disco hay rutinas para controlar parámetros de salud del disco: tiempo de comienzo de rotación (spin-up time), número de fallos de lectura, temperatura, tiempo de vida… Y todos esos parámetros no son solamente controlados por el propio disco, sino que tienen asignados límites de seguridad, y tanto los parámetros como los límites pueden ser obtenidos por programas que accedan a los discos utilizando las instrucciones I/O apropiadas.

Y ese programa es smartctl, una pieza del paquete Debian smartmontools. Por supuesto, como accede al disco directamente, hay que ser superusuario (root) para usar estas órdenes.

smartctl puede preguntarle al disco por su identificación SMART:

# smartctl -i /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Fujitsu MHV series
Device Model:     FUJITSU MHV2060BH
Serial Number:    NW10T652991F
Firmware Version: 00850028
User Capacity:    60,011,642,880 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 4a
Local Time is:    Mon May 12 02:39:31 2008 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Más interesante, smartctl puede preguntarle al disco por los valores de sus parámetros:

# smartctl -A /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   046    Pre-fail  Always       -       124253
  2 Throughput_Performance  0x0004   100   100   000    Old_age   Offline      -       18284544
  3 Spin_Up_Time            0x0003   100   100   025    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1199
  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       8589934592000
  7 Seek_Error_Rate         0x000e   100   087   000    Old_age   Always       -       1761
  8 Seek_Time_Performance   0x0004   100   100   000    Old_age   Offline      -       0
  9 Power_On_Seconds        0x0032   079   079   000    Old_age   Always       -       10866h+57m+47s
 10 Spin_Retry_Count        0x0012   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1199
192 Power-Off_Retract_Count 0x0032   099   099   000    Old_age   Always       -       283
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       6953
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       45 (Lifetime Min/Max 14/58)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       62
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       459276288
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000e   100   082   000    Old_age   Always       -       22371
203 Run_Out_Cancel          0x0002   100   100   000    Old_age   Always       -       1533257648465
240 Head_Flying_Hours       0x003e   200   200   000    Old_age   Always       -       0

Como se puede ver, algunos atributos están marcados como “Pre-fail”. Si cualquiera de estos atributos traspasa su límite, el disco está para fallar en cuestión de horas, quizá minutos.

Aunque hay más opciones para smartctl, las últimas que voy a comentar son -a y -t.

smartctl -t lanza una prueba automática de todo el disco. Necesita un parámetro indicando el tipo de prueba, y en el caso más largo puede durar varias decenas de minutos y comprobará el rendimiento eléctrico y mecánico del disco así como el rendimiento de lectura de las cabezas por toda la superficie. smartctl -a, por su parte, muestra toda la información disponible sobre el disco, incluidos los resultados de las pruebas automáticas. Como estas pruebas duran minutos, o decenas de minutos, no podemos observarlas. Todo lo que obtenemos al lanzar una de estas pruebas es:

# smartctl -t long /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in
off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in
off-line mode" successful.
Testing has begun.
Please wait 41 minutes for test to complete.
Test will complete after Mon May 12 05:44:03 2008

Use smartctl -X to abort test.

Aquí se nos informa de que (quizá) tengamos un rendimiento ligeramente menor del disco durante los próximos 41 minutos, porque la prueba ha comenzado. Se produce completamente en segundo plano, o sería mejor decir “fuera de plano”, ya que no ocurre bajo el control del Sistema Operativo en absoluto: todo ocurre internamente al disco, y lo único que vamos a obtener es el resultado.

smartctl -a, por su parte, muestra una enorme cantidad de información SMART sobre el disco: prácticamente toda la información SMART disponible. Normalmente es mejor utilizar una opción específica, como se puede ver en la página de manual (man).

Finalmente, quiero comentar que hay un demonio en el paquete smartmontools, llamado smartd, que se encarga de realizar las pruebas automáticas por uno. Funciona ejecutando smartctl de forma periódica (típicamente cada 30 minutos) y registrando todos los errores y los cambios de los valores de los parámetros en el registro del sistema (syslog). La configuración por defecto en Debian además enviará un mensaje al superusuario con cualquier problema detectado. No voy a explicarlo aquí porque quiero que se lean la documentación, que es concisa y clara, pero recuerden que para usarlo deben activarlo en /etc/default/smartmontools.

El paquete smartmontools ha estado disponible en Debian y Ubuntu desde hace mucho tiempo.

Hay quien ha preguntado por qué en los ejemplos todos los valores aparecen por encima de los límites. Es lo normal: los valores normalizados de los parámetros comienzan típicamente en 100 o 200, y a medida que el disco sufre van descendiendo. El problema lo tenemos cuando un parámetro desciende por debajo de su límite, no cuando está por encima. Aunque también hay que estar atento a las bajadas significativas de los parámetros aunque no leguen a los límites: son signos de que algo malo está pasando.

Como nota, los discos de Seagate tienen la costumbre de poner el parámetro de temperatura en su valor real, lo que lo convierte en uno de los pocos casos en los que un parámetro empeora cuando crece.

El escritorio que no cubría la pantalla

NOTA: Actualizado con todos los datos y capturas de pantalla.

Hoy me tocó arreglar el sistema X-Window de un portátil, un Toshiba Satellite U300 13H. Ya lo había hecho una vez, pero no recordaba cómo. El caso es que el escritorio no cubría toda la pantalla: la barra del escritorio no tocaba el fondo ni llegaba completamente a la derecha.



Y claro, fueron unas cuantas horas tratando de averiguar lo que pasaba, en realidad de recordarlo, trasteando con el siempre servicial xrandr que acudió en mi ayuda y me dijo lo que pasaba: La tarjeta gráfica se confundía y pensaba que estaban activas a la vez la salida LDVS y la salida TV. Y trataba de mostrarlas ambas en el monitor. Como la salida TV tiene menos resolución que la LDVS, pues ahí estaba el problema:

crab:~> xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right)
LVDS connected 1280x800+0+0 (normal left inverted right) 286mm x 179mm
   1280x800       59.9*+   60.0
   1280x768       60.0
   1024x768       60.0
   800x600        60.3
   640x480        59.9
TV connected 1024x768+0+0 (normal left inverted right) 0mm x 0mm
   1024x768       30.0*
   800x600        30.0
   848x480        30.0
   640x480        30.0

La solución ya la había hallado, no recuerdo ahora dónde, cuando instalé este portátil por primera vez, cuando se compró. Esta vez, me lié con la opción Option "Enable" "false" cuando no es correcta, y la solución al final me la dió esta entrada de una bitácora que se llama, curiosamente, No pienso arreglar tu ordenador. Tenía que haber usado Option "Ignore" "true".

Para explicarlo un poco mejor, el fichero xorg.conf lleva una sección donde se configura el dispositivo (la tarjeta de vídeo), otra donde se configuran los monitores (porque puede haber varios), y otra donde se junta todo creando una "pantalla".

La solución es configurar dos monitores:

Section "Monitor"
        Identifier      "Configured Monitor"
        Option          "DPMS"
EndSection

Section "Monitor"
        Identifier      "Disabled Monitor"
        Option          "Ignore"        "true"
EndSection

y configurar la tarjeta para que ponga sus salidas en esos dos monitores, sacando así la molesta salida TV al monitor deshabilitado:

Section "Device"
        Identifier      "Intel Corporation Mobile GM965/GL960 Integrated Graphic
s Controller"
        Driver          "intel"
        BusID           "PCI:0:2:0"
        Option          "Monitor-LVDS" "Configured Monitor"
        Option          "Monitor-TV" "Disabled Monitor"
EndSection

Diseños de teclado (II)

Siguiendo con lo escrito en "Diseños de teclado", esta vez he tenido que hacer algo semejante: que un teclado estadounidense pueda ser utilizado para escribir normalmente en castellano.

Gracias a la documentación que menciono allí ^{[1] [2] [3]} no tuve muchos problemas para conseguirlo. El modelo de teclado a utilizar era, evidentemente, el teclado estadounidense us, lo que, así solo, significa la variante basic, es decir us(basic). Pero el teclado us tiene otra variante, la internacional us(intl), que permite cosas como que las teclas con acentos se consideren teclas muertas: teclas que necesitan que se pulse otra después, como en el teclado castellano es normal.

Pero no quería poner el teclado us(intl) tal cual, porque redefine demasiadas teclas.

La solución ha sido elegir la variante de teclado compuesta us+us(intl), que utiliza como base el us(basic) y allí donde éste no llega le añade el us(intl).

Así, la sección correspondiente del fichero /etc/X11/xorg.conf la he modificado de

Section "InputDevice"

# keyboard added by rhpxl
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us"
EndSection

a

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us+us(intl)"
EndSection

El estrangulador del procesador

Los procesadores modernos (me refiero a la familia de los x86) tienen una característica muy interesante: el estrangulador (throttling) del procesador.

Muchas veces hemos oído hablar de características de los procesadores para portátiles como la de bajar la frecuencia de trabajo cuando se utiliza la batería, para que dure más. Pero el caso es que hay otras características que nos ayudan a hacer lo mismo, y mejor. Se trata de los estados de throttling del procesador, que fuerzan al mismo, independientemente de lo cargado que se encuentre, a <<echarse a dormir>> parte del tiempo. Estos estados se identifican con la letra T. El Intel Centrino Duo T2400 de mi portátil, por ejemplo, tiene 8 de estos estados de estrangulamiento, desde el T0 hasta el T7. Cuando está en el estado T0 el procesador no descansa: siempre está ejecutando algo, aunque sea el <<ciclo idle>>, y por lo mismo además siempre está gastando energía. En el estado T4, por ejemplo, el procesador estará dormido el 50% del tiempo: todas las operaciones que el usuario (o el sistema) trate de hacer, incluso a la máxima frecuencia, tardarán el doble de lo que tardarían en el estado T0.

Hoy en día, con núcleos Linux como el 2.6.26 que tengo funcionando, con las implementaciones modernas de ACPI, el estrangulador no es la vía preferida para cambiar la capacidad (ni el consumo) del procesador. Para eso están los cambios de frecuencia (los estados P del procesador), que son lo que normalmente podemos cambiar con herramientas de usuario como KPowersave. Otro día hablaré más profundamente sobre los estados P, los estados T, los estados S, los estados C, los estados G e incluso los estados D.

Antiguamente, cuando no se podía cambiar la frecuencia de los procesadores, los estados T eran la única manera de hacer que gastaran menos. Como expliqué arriba, esto se consigue poniendo el procesador a dormir por cortos períodos de tiempo, que en mi caso pueden llegar al 88% del tiempo total, dejando sólo el 12% del tiempo para ejecutar realmente instrucciones. Hoy, normalmente no se cambian estos estados salvo en caso de emergencia térmica: si el procesador está sobrecalentado por exceso de trabajo (y una ventilación o disipación deficiente), el sistema puede estrangular el procesador para obligarle a gastar menos energía (y así generar menos calor) incluso bajo las demandas más altas por parte del usuario.

Pero se pueden cambiar a mano para ver sus efectos.

Los núcleos Linux de hoy en día están cambiando sus interfaces ACPI del tradicional /proc al nuevo /sys, pero este cambio todavía no ha finalizado y nos las tenemos que ver con ambos. Para los estados T, en particular, vamos a requerir trastear con los ficheros de /proc/acpi/processor/. En este directorio veremos que hay un directorio por cada núcleo de procesador: /proc/acpi/processor/CPU0/, /proc/acpi/processor/CPU1/, etc. Utilicemos /proc/acpi/processor/CPU0/ como ejemplo. En su interior veremos varios ficheros, de los cuales nos va a interesar, en este caso, /proc/acpi/processor/CPU0/throttling. Este fichero nos indica qué estados de estrangulamiento soporta nuestro procesador (8 en el ejemplo inferior), qué tiempo duerme el procesador en cada uno de ellos y qué estado está en uso actualmente:

$ cat /proc/acpi/processor/CPU0/throttling
state count:             8
active state:            T0
state available: T0 to T7
states:
*T0:                  100%
T1:                  87%
T2:                  75%
T3:                  62%
T4:                  50%
T5:                  37%
T6:                  25%
T7:                  12%

En este ejemplo vemos que el sistema tiene 8 estados de estrangulamiento (state count), numerados de T0 a T7 (state available y la lista states), los tiempos de procesador activo de cada uno, del 100% activo (0% durmiendo) del T0 al 12% activo (88% durmiendo) del T7 (la lista states) y que el estado actual es el T0 (active state y el * en la lista states).

Se puede cambiar el estado a mano, siendo el superusuario, mediante una sencilla orden típica de /proc:

# echo 4 > /proc/acpi/processor/CPU0/throttling

o bien

# echo T4 > /proc/acpi/processor/CPU0/throttling

Si estás tratando de subirlo y no funciona, es que tu máquina está demasiado caliente y el sistema obliga al estrangulador a bajar el consumo para generar menos calor. Recuerda que cada watio gastado es un watio de calor que hay que sacar del sistema. Si sacas menos calor del que generas, el sistema se calienta y puede quemarse.

Un ejemplo: poner mi portátil sobre una esterilla aislante y poner la máquina a calcular hashes para el aMule pone la máquina en T7 independientemente de lo que yo haga. Simplemente levantarla 1cm de la esterilla aislante con unas pinzas de la ropa lleva al sistema a T4 casi inmediatamente y a T0 en unos 30 segundos. Y además en T0 el sistema responde mejor ;)

Información sobre la batería

Recientemente los núcleos de Linux han dejado de proporcionar la información de la batería que antes se encontraba en /proc/acpi/battery/BAT0 y ahora se considera que utilizar /proc para esas cosas está desaconsejado, debiéndose utilizar /sys. Pero por ningún sitio encontré información sobre en qué sitio de /sys se encuentra ahora esa información.

Y positivamente no es en /sys/bus/acpi, /sys/firmware/acpi ni /sys/module/acpi.

Después de mucho buscar (incluso buceando en los parches de varias herramientas para adaptarse al cambio) lo he encontrado: /sys/class/power_supply.

My Review of Sun Fire X4600 Server

Originally submitted at Sun Microsystems

The Sun Fire X4600 server, featuring AMD Opteron processors, packs the punch of two Xeon 4P servers in a more space-efficient and energy-efficient system for tremendous operating cost savings. Its modular design makes upgrading to future processor technologies simple and non-disruptive. The server'...

Sun Fire X4600 Server

Insufficient disk space

By Noel "Envite" Torres from Valencia, Spain on 7/3/2008

 

4out of 5

Pros: Fast, Up to 8 Quad, Easy Set Up

Cons: Bulky, Small disk space

Best Uses: Science

Describe Yourself: Quality Oriented

At Universidad de Valencia we bought this machine for scientific simulations. We're very happy with it's ease of installation and configuration, and with it's calculating power with 8 Quad (that's 32 processors).
But the hard disk is absolutely insufficient. Best possible configuration is 576GiB which is by no means sufficient for a normal simulation in Physics.

I wrote a core complete review (in spanish) at my blog in http://denvite.blogspot.com/2008/07/maravilloso-sunfire.html

(legalese)

Maravilloso SunFire

Hoy hemos instalado otra máquina con cuatro procesadores AMD Quad Core de 64 bits como los del TYAN que comentaba ayer. Esta vez, la máquina es una SunFire X4600 M2, de Sun Microsystems. Ha salido más cara por procesador, sin ninguna duda, pero a cambio me gusta más.

Una de las cosas que hacen, sin género de dudas, que esta máquina me guste más que la anterior es su procesador de servicio. Una pequeña tarjeta adicional integrada en la máquina que permite, incluso con la máquina apagada, con tal de que tenga corriente, ver el estado del hardware, encender la máquina, apagarla, reiniciarla, etc. No me cabe ninguna duda de que los fallos que ha estado teniendo la otra máquina, que tiene, repito, los mismo procesadores, caso de que se reprodujeran en esta máquina, hubieran sido más sencillos de atender. Con la otra máquina, cada vez que notábamos que la máquina no respondía, alguien tenía que acercarse a ver qué pasaba y darle al botón. Ahora, si notáramos lo mismo, podríamos conectar al procesador de servicio <<desde la playa>> y ver qué estaría ocurriendo, y en su caso, podríamos reiniciar la máquina sin tener que ir allí. Salvo, claro está, que el problema fuera un corte de luz para todo el armario. Todo eso gracias al sistema ILOM del procesador de servicio, que nos permite, además, acceder por red (HTTP, SNMP y SSH) o por consola serie.

Otra de las grandes ventajas, a mi entender, del SunFire X4600 M2 sobre el ordenador que comentaba ayer es la manera que tiene de organizar los procesadores y la memoria. Allí, cuatro procesadores iban en la placa base, y cuatro en una especie de <<placa base de expansión>>. Aquí los procesadores van, con su memoria asociada, en placas verticales, todas iguales (no cuatro preferentes y cuatro secundarios) que encajan en la placa base individualmente. Aparte de hacer más sencillo el cambio de un procesador (tan tonto como sacar una placa vertical, como se ve en la foto), encuentro el diseño más elegante y mejor pensado.

Otras ventajas, más secundarias desde mi punto de vista, son las cuatro tarjetas de red Gigabit, las cuatro fuentes de alimentación redundantes colocadas en vertical (el otro las tiene en horizontal), los cuatro ventiladores extraíbles (el otro tiene tres, y no forman túnel de aire) y el hecho de que la colocación de las placas de procesador evita una de las pesadillas de un administrador de sistemas en verano: que se estropee un ventilador de procesador. Al X4600 no se le pueden estropear porque no tiene: la ventilación frontal formando túnel de aire, con los procesadores (y sus disipadores de rejilla) justo detrás, hace todo el trabajo.

Entre lo malo está que, a consecuencia de lo anterior, se trata de una máquina que ocupa 4U.


Lo peor, los discos duros. Son discos SAS (eso es una <<Cosa Buena>> ®) pero de 2,5 pulgadas, lo que no permite tener los grandes discos propios de las máquinas de cálculo científico. El mayor disco soportado es de 146GiB, lo que nos da una capacidad total máxima de 576GiB, claramente insuficiente para cálculos científicos masivos, ya que una configuración normal para simulaciones científicas puede tener perfectamente seis discos de 500GiB cada uno. Y no es raro oír acerca de espacios de disco aún mayores. Total, que hemos acabado (gracias $DEITY por darnos RAID) con un espacio de disco de aproximadamente medio TiB para almacenar los resultados.

Eso sí, la instalación de la nueva OpenSuSE 11, recién salida del horno, con su flamante KDE 4, fue una delicia. En un ratito tuvimos la máquina completamente instalada, sin problemas de reconocimiento de <<hardware>> ni nada que se le pareciera. Ya está trabajando, y de momento no se ha caído.