Re: [OT] Raid por hardware

2015-01-31 Thread Camaleón
El Sat, 31 Jan 2015 11:29:04 +0100, José Miguel (sio2) escribió:

> El Sun, 25 de Jan de 2015, a las 07:12:30PM +, Camaleón dijo:
> 
>> Recuerda que no sólo tienes que asegurarte de la configuración que
>> tienes en la BIOS para la controladora del disco duro sino también del
>> módulo del kernel que usas en todo momento.
>> 
>> Es decir, la teoría establece los siguientes parámetros óptimos:
>> 
>> BIOS → módulo del kernel
>> 
>> IDE → libata / mptctl SATA/AHCI → ahci RAID/INTEL → dm RAID/LSI →
>> mptsas
> 
> Todo esto parecía ir bien: cuando usaba la controladora RAID se cargaba
> el módulo mptsas, cuando no la usaba no lo hacía.

En un correo anterior mencionaste que con el modo IDE activado en la BIOS 
se cargaba un driver que no era el habitual "libata" sino "mptctl" lo 
cual no deja de ser una ventaja porque te permite ir combinando opciones 
de configuración en la BIOS con distintos módulos del kernel para ver qué 
combinación se desempeña mejor.

> Al final resultó que sin la controladora RAID, acabaron por producirse
> las demoras. Definitivamente tuve que quitar el servidor y poner el
> ordenador normalillo para ir tirando. Ahora vuelvo a estar en precario.

Sigue siendo raro. De todas formas, has hecho muchas cosas en ese equipo, 
yo hubiera empezado desde cero (instalando en limpio y reiniciando el 
array) para monitorizarlo.

>>> Después de cerciorarme de que la cosa seguía mal, decidí deshacer el
>>> RAID otra vez, pinchar los discos directamente a la placa base; y,
>>> como novedad, quitar físicamente la controladora del servidor. Hecho
>>> esto, probé... y funciona. Ahora va como un tiro.
> 
>> Pero te sigues olvidando del módulo del kernel y de la configuración de
>> la BIOS.
> 
> Eso no lo cité, pero lo hice también: quité la controladora y puse la
> BIOS la controladora en modo IDE (o AHCI no recuerdo bien).

Sin tener la controladora pinchada, entiendo que se podrían haber dado 
dos situaciones:

- IDE con driver libata
- AHCI con driver ahci

>> La secuencia para comprobar el correcto (o no) funcionamiento de la
>> controladora raid sería la siguiente (conlleva pérdida de datos):
>> 
>> 1/ Configurar los discos en la BIOS como RAID/LSI 2/ Acceder a la BIOS
>> de la controladora y definir el raid 1 reinicializando los discos (se
>> borra todo)
>> 3/ Instalar de nuevo el sistema operativo desde cero o asegurarte de
>> que el kernel carga el módulo adecuado (mptsas).
> 
> No instalé de nuevo el sistema, pero sí comprobé que se cargaba mptsas.
> No valía, de hecho cuando lo puse en RAID/LSI fue cuando peor fue. Peor
> que con RAID/IDE o RAID/AHCI.

Pero ya habías hecho muchas cosas, lo suyo -como te decía más arriba- era 
empezar desde cero para poder establecer una posible causa del origen del 
problema. 

>> De otra forma es posible que los metadatos de los discos con la
>> información del raid esté molestando por lo que idealmente habría que
>> empezar desde cero.
> 
> No sé si molestan o no. De hecho, no tengo muy claro que el problema sea
> de acceso a disco. Quizás que no se sincronicen los discos es una
> consecuencia y no la raíz del problema.

Tenías pocos datos del estado del array. En ocasiones la utilidad del raid 
te dice una cosa y en la BIOS de la controladora aparece otra, es decir, 
no hay que fiarse al 100%, es mejor comparar lo que te dice la utilidad 
con lo que ves desde otros sitios (la BIOS u otra aplicación).

>> De todas formas, también te digo que en ese equipo no creo que vayas a
>> notar una merma en el rendimiento por usar "md" (software raid) en
>> lugar del raid por harwdare. Si optas por esta opción (md) recuerda
>> poner el modo AHCI en la BIOS.
> 
> En realidad usé el raid por hardware por el hecho de tener la
> controladora. No es un servidor que soporte mucho tráfico, ni mucho
> menos. Va más que sobrado. Cuando funciona bien, claro.

Y no parece una controladora problemática, o la menos no he visto muchas 
quejas por Google sobre ese modelo. Y si no va a llevar gran carga de 
trabajo mejor.

>> La actualización de la BIOS te cambió los parámetros de acceso a los
>> discos, no sé ni cómo fue capaz de iniciar el sistema .
> 
> Quizás la actualización hizo algo, pero lo cierto es que yo he probado a
> cambiar los parámetros de acceso a disco. Usando la controladora RAID:
> IDE, AHCI y LSI; y sin usar la controladora IDE y AHCI; y con todos
> tenía los problemas de demora.
> 
> Puede ser que el problema esté en otro sitio.

Puede ser, pero siempre que se hacen cambios hay que analizar los 
resultados no a ojo ni con percepciones sino con pruebas y datos 
fehacientes (registros del sistema, mensajes de error, consulta del 
estado del array desde varias aplicaciones, etc...)

>> Ya contarás :-)
> 
> Pues eso, que no se arregló. El problema es que ahora no tengo mucho
> tiempo para cambalaches. Me temo que voy a tener que dejar el ordenador
> de repuesto y esperar mejores tiempos.

Bueno, al menos ha servido para saber algo más de esa controladora :-)

Sal

Re: [OT] Raid por hardware

2015-01-31 Thread sio2
El Sun, 25 de Jan de 2015, a las 07:12:30PM +, Camaleón dijo:

> Recuerda que no sólo tienes que asegurarte de la configuración que tienes 
> en la BIOS para la controladora del disco duro sino también del módulo 
> del kernel que usas en todo momento. 
> 
> Es decir, la teoría establece los siguientes parámetros óptimos:
> 
> BIOS → módulo del kernel
> 
> IDE → libata / mptctl
> SATA/AHCI → ahci
> RAID/INTEL → dm
> RAID/LSI → mptsas

Todo esto parecía ir bien: cuando usaba la controladora RAID se cargaba
el módulo mptsas, cuando no la usaba no lo hacía.

Al final resultó que sin la controladora RAID, acabaron por producirse
las demoras. Definitivamente tuve que quitar el servidor y poner el
ordenador normalillo para ir tirando. Ahora vuelvo a estar en precario.

>> Después de cerciorarme de que la cosa seguía mal, decidí deshacer el
>> RAID otra vez, pinchar los discos directamente a la placa base; y,
>> como novedad, quitar físicamente la controladora del servidor. Hecho
>> esto, probé... y funciona. Ahora va como un tiro.

> Pero te sigues olvidando del módulo del kernel y de la configuración de 
> la BIOS. 

Eso no lo cité, pero lo hice también: quité la controladora y puse la
BIOS la controladora en modo IDE (o AHCI no recuerdo bien).

> La secuencia para comprobar el correcto (o no) funcionamiento de la 
> controladora raid sería la siguiente (conlleva pérdida de datos):
> 
> 1/ Configurar los discos en la BIOS como RAID/LSI
> 2/ Acceder a la BIOS de la controladora y definir el raid 1 
> reinicializando los discos (se borra todo)
> 3/ Instalar de nuevo el sistema operativo desde cero o asegurarte de que 
> el kernel carga el módulo adecuado (mptsas).

No instalé de nuevo el sistema, pero sí comprobé que se cargaba mptsas.
No valía, de hecho cuando lo puse en RAID/LSI fue cuando peor fue. Peor
que con RAID/IDE o RAID/AHCI.

> De otra forma es posible que los metadatos de los discos con la 
> información del raid esté molestando por lo que idealmente habría que 
> empezar desde cero.

No sé si molestan o no. De hecho, no tengo muy claro que el problema sea
de acceso a disco. Quizás que no se sincronicen los discos es una
consecuencia y no la raíz del problema.

> De todas formas, también te digo que en ese equipo no creo que vayas a 
> notar una merma en el rendimiento por usar "md" (software raid) en lugar 
> del raid por harwdare. Si optas por esta opción (md) recuerda poner el 
> modo AHCI en la BIOS.

En realidad usé el raid por hardware por el hecho de tener la
controladora. No es un servidor que soporte mucho tráfico, ni mucho
menos. Va más que sobrado. Cuando funciona bien, claro.

> La actualización de la BIOS te cambió los parámetros de acceso a los 
> discos, no sé ni cómo fue capaz de iniciar el sistema .

Quizás la actualización hizo algo, pero lo cierto es que yo he probado a
cambiar los parámetros de acceso a disco. Usando la controladora RAID:
IDE, AHCI y LSI; y sin usar la controladora IDE y AHCI; y con todos
tenía los problemas de demora.

Puede ser que el problema esté en otro sitio.

> Ya contarás :-)

Pues eso, que no se arregló. El problema es que ahora no tengo mucho
tiempo para cambalaches. Me temo que voy a tener que dejar el ordenador
de repuesto y esperar mejores tiempos.

> Saludos,

Saludos.

-- 
   Flérida para mí dulce y sabrosa,
más que la fruta de cercado ajeno.
  --- Garcilaso de la Vega ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150131102904.ga5...@cubo.casa



Re: [OT] Raid por hardware

2015-01-25 Thread Camaleón
El Sat, 24 Jan 2015 09:17:48 +0100, José Miguel (sio2) escribió:

> Pues bien, traigo noticias frescas de mis tribulaciones con el servidor.
> 
> Después de comprobar que el sistema funcionaba perfectamente sobre un
> solo disco en otro ordenador distinto, probé a volver a usar el
> servidor. Nada, volvían a producirse las mismas demoras. Cambié la
> controladora de disco en la BIOS a RAID+LSI, pero no sirvió de nada. De
> hecho, me da la sensación de que nunca llegó a estar así, por la
> información que proporciona el ordenador antes de que apareciera el
> grub.

Recuerda que no sólo tienes que asegurarte de la configuración que tienes 
en la BIOS para la controladora del disco duro sino también del módulo 
del kernel que usas en todo momento. 

Es decir, la teoría establece los siguientes parámetros óptimos:

BIOS → módulo del kernel

IDE → libata / mptctl
SATA/AHCI → ahci
RAID/INTEL → dm
RAID/LSI → mptsas

El resto de combinaciones te pueden dar problemas o no proporcionarte el 
rendimiento adecuado.

> Después de cerciorarme de que la cosa seguía mal, decidí deshacer el
> RAID otra vez, pinchar los discos directamente a la placa base; y,
> como novedad, quitar físicamente la controladora del servidor. Hecho
> esto, probé... y funciona. Ahora va como un tiro.

Pero te sigues olvidando del módulo del kernel y de la configuración de 
la BIOS. 

> Como soy previsor y había montado un raid1 por software también, me toca
> limpiar el superbloque del segundo disco, enchufarlo al servidor y
> hacerlo participar en el raid como segundo disco. Renunciaré a hacer el
> RAID por hardware y ya está.

La secuencia para comprobar el correcto (o no) funcionamiento de la 
controladora raid sería la siguiente (conlleva pérdida de datos):

1/ Configurar los discos en la BIOS como RAID/LSI
2/ Acceder a la BIOS de la controladora y definir el raid 1 
reinicializando los discos (se borra todo)
3/ Instalar de nuevo el sistema operativo desde cero o asegurarte de que 
el kernel carga el módulo adecuado (mptsas).

De otra forma es posible que los metadatos de los discos con la 
información del raid esté molestando por lo que idealmente habría que 
empezar desde cero.

De todas formas, también te digo que en ese equipo no creo que vayas a 
notar una merma en el rendimiento por usar "md" (software raid) en lugar 
del raid por harwdare. Si optas por esta opción (md) recuerda poner el 
modo AHCI en la BIOS.

> Entiendo que el problema lo provoca la mera presencia de la controladora
> RAID en el sistema; y no el que gestione ella el RAID; puesto que ya
> probé hace un par de semanas a dejarla puesta sin que se encargara del
> acceso a disco. No sé si la actualización de la BIOS pudo introducir
> alguna incompatibilidad.

La actualización de la BIOS te cambió los parámetros de acceso a los 
discos, no sé ni cómo fue capaz de iniciar el sistema .

> Lo que voy a hacer antes de enchufar el segundo disco en el servidor
> definitivamente, es ponerlo en el otro ordenador y ver si es posible
> pinchar la controladora de RAID también. Si se puede, pondré a funcionar
> el conjunto a ver si se me producen esas demoras o no.

Ya contarás :-)

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.25.19.12...@gmail.com



Re: [OT] Raid por hardware

2015-01-24 Thread sio2
Pues bien, traigo noticias frescas de mis tribulaciones con el servidor.

Después de comprobar que el sistema funcionaba perfectamente sobre un
solo disco en otro ordenador distinto, probé a volver a usar el
servidor. Nada, volvían a producirse las mismas demoras. Cambié la
controladora de disco en la BIOS a RAID+LSI, pero no sirvió de nada. De
hecho, me da la sensación de que nunca llegó a estar así, por la
información que proporciona el ordenador antes de que apareciera el
grub.

Después de cerciorarme de que la cosa seguía mal, decidí deshacer el
RAID otra vez, pinchar los discos directamente a la placa base; y,
como novedad, quitar físicamente la controladora del servidor. Hecho
esto, probé... y funciona. Ahora va como un tiro.

Como soy previsor y había montado un raid1 por software también, me toca
limpiar el superbloque del segundo disco, enchufarlo al servidor y
hacerlo participar en el raid como segundo disco. Renunciaré a hacer el
RAID por hardware y ya está.

Entiendo que el problema lo provoca la mera presencia de la controladora
RAID en el sistema; y no el que gestione ella el RAID; puesto que ya
probé hace un par de semanas a dejarla puesta sin que se encargara del
acceso a disco. No sé si la actualización de la BIOS pudo introducir
alguna incompatibilidad.

Lo que voy a hacer antes de enchufar el segundo disco en el servidor
definitivamente, es ponerlo en el otro ordenador y ver si es
posible pinchar la controladora de RAID también. Si se puede, pondré a
funcionar el conjunto a ver si se me producen esas demoras o no.

Un saludo.

-- 
   Mira que la mejor parte de España,
pudiendo Casta, se llamó Castilla.
  --- Tomé de Burguillos ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150124081748.ga2...@cubo.casa



Re: [OT] Raid por hardware

2015-01-18 Thread Camaleón
El Sat, 17 Jan 2015 22:29:15 +0100, José Miguel (sio2) escribió:

> El Sat, 17 de Jan de 2015, a las 05:19:03PM +, Camaleón dijo:
> 
>>> He estado consultado la BIOS del servidor desmantelado. La
>>> controladora se puede poner como:
>>> 
>>> + IDE, que era como estaba.
>> 
>> ¿Estaba en modo IDE y con RAID habilitado? O_o
> 
> No, está en IDE ahora que hay un disco duro conectado directamente a la
> placa base y que deshice el RAID. Pero yo no toqué nada en la BIOS de la
> placa base: sólo deshice el RAID en la BIOS de la controladora RAID y
> cambié el cableado del disco para que estuviera enchufado sin pasar por
> dicha controladora.
> 
> Puede ser que al deshacer el RAID, la controladora cambiara en la BIOS
> de la placa esto (no sé si es posible).

El cambio de RAID+LSI a IDE sólo lo veo posible tras actualizar la BIOS. 
O que se haya hecho a mano.

(...)

>>> El problema que tengo ahora es que no sé cómo narices identificar uno
>>> de otro disco para que el disco que ha estado esta semana trabajando
>>> sea el disco primario del RAID. Debería haber una forma, pero soy
>>> incapaz de verla. Al menos mientras el RAID estuvo montado: a lo mejor
>>> sí se puede ver al crear el RAID.
>> No sé si el orden de colocación de los discos duros afectará al raid 1,
>> quizá no haya ningún problema si todos los datos siguen intactos en
>> ambos discos.
> 
> No, ambos discos son ya distintos, porque esta semana se han añadido
> datos al disco que ha seguido funcionando en el servidor circunstancial.

Bueno, que hayas añadido datos no importa. Lo que sí marca una diferencia 
es que hayas eliminado los metadatos del RAID, entonces tendrás que 
empezar desde cero porque tendrás que volver a crear el volumen raid 1, 
reiniciar los discos, instalar el sistema, etc... Salvo que hagas una 
copia/imagen del disco y la restaures tras haber creado de nuevo el 
volumen raid 1, claro.

> Haré copia de estos datos por si las moscas y, antes de recontruir el
> RAID, probaré a tomar otros dos discos vacíos que contengan un único
> fichero distinto cada uno. Montaré el RAID con ellos y miraré cuál es el
> disco que se tomó como primario. En base a ello, colocaré los dos discos
> que me interesan: se supone que si hago exactamente lo mismo en uno y
> otro caso, sabré de antemano cuál será tomado como primario en el
> segundo caso.

Ya te digo que el orden no afectará, menos aún si empiezas desde cero.

>> El problema está claro: se ha modificado el parámetro de la BIOS lo
>> cual no sé ni cómo ha podido funcionar. Vuelve a dejarlo como estaba y
>> verás como el problema se soluciona :-)
> 
> Yo no me las prometo tan felices. Ya contaré qué pasa.

Es que eso lo explicaría todo. Además, como te dije al principio del 
hilo, las controladoras ZCR son muy susceptibles con los cambios de BIOS 
porque no son controladoras RAID independientes, y las modificaciones en 
el firmware de la BIOS de la placa base también les puede afectar.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.18.15.44...@gmail.com



Re: [OT] Raid por hardware

2015-01-17 Thread sio2
El Sat, 17 de Jan de 2015, a las 05:19:03PM +, Camaleón dijo:

>> He estado consultado la BIOS del servidor desmantelado. La controladora
>> se puede poner como:
>> 
>> + IDE, que era como estaba.
> 
> ¿Estaba en modo IDE y con RAID habilitado? O_o

No, está en IDE ahora que hay un disco duro conectado directamente a la
placa base y que deshice el RAID. Pero yo no toqué nada en la BIOS de la
placa base: sólo deshice el RAID en la BIOS de la controladora RAID y
cambié el cableado del disco para que estuviera enchufado sin pasar por
dicha controladora.

Puede ser que al deshacer el RAID, la controladora cambiara en la BIOS
de la placa esto (no sé si es posible).

>> Lo que me escama es que la BIOS estuviera en "IDE" y no en "LSI": yo no
>> he tocado nada. A lo mejor se desconfiguró cuando actualicé la BIOS
>> (aunque tampoco sé cuál era su valor antes de la actualización).
> Ah, claro... es posible que al actualizar la BIOS todos los valores 
> volvieron al estado de fábrica, de ahí que te diera tantos problemas y te 
> fuera lentorro. Sí, prueba dejando la configuración RAID+LSI que es como 
> debería estar y conecta los dos discos, todo debería volver a la 
> normalidad.

Eso haré.

>> El problema que tengo ahora es que no sé cómo narices identificar uno de
>> otro disco para que el disco que ha estado esta semana trabajando sea el
>> disco primario del RAID. Debería haber una forma, pero soy incapaz de
>> verla. Al menos mientras el RAID estuvo montado: a lo mejor sí se puede
>> ver al crear el RAID.
> No sé si el orden de colocación de los discos duros afectará al raid 1, 
> quizá no haya ningún problema si todos los datos siguen intactos en ambos 
> discos.

No, ambos discos son ya distintos, porque esta semana se han añadido
datos al disco que ha seguido funcionando en el servidor circunstancial.
Haré copia de estos datos por si las moscas y, antes de recontruir el
RAID, probaré a tomar otros dos discos vacíos que contengan un único
fichero distinto cada uno. Montaré el RAID con ellos y miraré cuál es el
disco que se tomó como primario. En base a ello, colocaré los dos discos
que me interesan: se supone que si hago exactamente lo mismo en uno y
otro caso, sabré de antemano cuál será tomado como primario en el
segundo caso.

> El problema está claro: se ha modificado el parámetro de la BIOS lo cual 
> no sé ni cómo ha podido funcionar. Vuelve a dejarlo como estaba y verás 
> como el problema se soluciona :-)

Yo no me las prometo tan felices. Ya contaré qué pasa.

> Saludos,

Saludos y gracias.

-- 
   ¿No ha de haber un espíritu valiente?
¿Siempre se ha de sentir lo que se dice?
¿Nunca se ha de decir lo que se siente?
  --- Francisco de Quevedo ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150117212915.ga29...@cubo.casa



Re: [OT] Raid por hardware

2015-01-17 Thread Camaleón
El Fri, 16 Jan 2015 20:35:20 +0100, José Miguel (sio2) escribió:

> El Mon, 12 de Jan de 2015, a las 02:39:28PM +, Camaleón dijo:
> 
>> Mucho esperas... Me extrañaría que tuviera memoria flash con capacidad
>> suficiente para albergar los datos más allá de los que necesita
>> (firmware y metadatos). Salvo que la controladora sea buena (pero de
>> las buenas de verdad que tienen un batería y todas esas gaitas) y aún
>> así tendría mis dudas.
> 
> Pues creo que llevas razón. He comprobado el driver que hay cargado en
> el ordenador suplente temporal, que no lleva ninguna controladora RAID,
> y se carga el driver mptctl.

sm01@stt008:~$ locate mptctl.ko
/lib/modules/3.2.0-4-amd64/kernel/drivers/message/fusion/mptctl.ko

Bien, parece ser que ese módulo del kernel es el driver genérico (sin 
funciones avanzadas) de la controladora.

root@stt008:~# modinfo /lib/modules/3.2.0-4-amd64/kernel/drivers/message/
fusion/mptctl.ko | grep -i desc
description:Fusion MPT misc device (ioctl) driver

root@stt008:~# modinfo /lib/modules/3.2.0-4-amd64/kernel/drivers/message/
fusion/mptsas.ko | grep -i desc
description:Fusion MPT SAS Host driver

> Entiendo que es este driver el que me oculta que el disco tenga
> metadatos del RAID y que haciendo una consulta a las particiones y demás
> parezca un disco "normal", ¿no?

No sé exactamente cómo lo hará, es decir, entiendo que el disco duro 
contiene los metadatos del raid pero el sistema operativo sencillamente 
los ignorará ya que no hay ninguna controladora raid habilitada para leer 
esos metadatos ni interpretarlos.

>> Es que no tienes más que una controladora de disco sata y es la LSI.
> 
> He estado consultado la BIOS del servidor desmantelado. La controladora
> se puede poner como:
> 
> + IDE, que era como estaba.

¿Estaba en modo IDE y con RAID habilitado? O_o

> + ACHI.
> + RAID y dentro de esta categoría:
>   - Intel no se qué (entiendo que será un fake-raid)
>   - LSI, que utilizará la controladora RAID pinchada.
> 
> Lo he puesto en ACHI y con el segundo disco he probado a instalar un
> paquete. No ha parecido demorarse como antes, pero no me fío mucho. No
> sé si probar a ponerlo en ACHI o en RAID-LSI y probar. 

Lo suyo es que estuviera en modo RAID+LSI para configurar un volumen raid 
1 y usar el driver "mptsas" pero si esa configuración te da problemas, 
prueba con ahci y sin raid (o raid por software "md").

> Lo que me escama es que la BIOS estuviera en "IDE" y no en "LSI": yo no
> he tocado nada. A lo mejor se desconfiguró cuando actualicé la BIOS
> (aunque tampoco sé cuál era su valor antes de la actualización).

Ah, claro... es posible que al actualizar la BIOS todos los valores 
volvieron al estado de fábrica, de ahí que te diera tantos problemas y te 
fuera lentorro. Sí, prueba dejando la configuración RAID+LSI que es como 
debería estar y conecta los dos discos, todo debería volver a la 
normalidad.

> El problema que tengo ahora es que no sé cómo narices identificar uno de
> otro disco para que el disco que ha estado esta semana trabajando sea el
> disco primario del RAID. Debería haber una forma, pero soy incapaz de
> verla. Al menos mientras el RAID estuvo montado: a lo mejor sí se puede
> ver al crear el RAID.

No sé si el orden de colocación de los discos duros afectará al raid 1, 
quizá no haya ningún problema si todos los datos siguen intactos en ambos 
discos.

> Como ya he visto que el sistema en el ordenador funciona sin problemas,
> lo haré la semana que viene. Con suerte ha desaparecido el problema,
> aunque no sé muy bien cuál podría ser. La memoria la testeé y estaba
> bien. :/

El problema está claro: se ha modificado el parámetro de la BIOS lo cual 
no sé ni cómo ha podido funcionar. Vuelve a dejarlo como estaba y verás 
como el problema se soluciona :-)

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.17.17.19...@gmail.com



Re: [OT] Raid por hardware

2015-01-16 Thread sio2
El Mon, 12 de Jan de 2015, a las 02:39:28PM +, Camaleón dijo:

> Mucho esperas... Me extrañaría que tuviera memoria flash con capacidad 
> suficiente para albergar los datos más allá de los que necesita (firmware 
> y metadatos). Salvo que la controladora sea buena (pero de las buenas de 
> verdad que tienen un batería y todas esas gaitas) y aún así tendría mis 
> dudas.

Pues creo que llevas razón. He comprobado el driver que hay cargado en
el ordenador suplente temporal, que no lleva ninguna controladora RAID,
y se carga el driver mptctl.

Entiendo que es este driver el que me oculta que el disco tenga
metadatos del RAID y que haciendo una consulta a las particiones y demás
parezca un disco "normal", ¿no?

> Es que no tienes más que una controladora de disco sata y es la LSI.

He estado consultado la BIOS del servidor desmantelado. La controladora
se puede poner como:

+ IDE, que era como estaba.
+ ACHI.
+ RAID y dentro de esta categoría:
  - Intel no se qué (entiendo que será un fake-raid)
  - LSI, que utilizará la controladora RAID pinchada.

Lo he puesto en ACHI y con el segundo disco he probado a instalar un
paquete. No ha parecido demorarse como antes, pero no me fío mucho. No
sé si probar a ponerlo en ACHI o en RAID-LSI y probar. Lo que me escama
es que la BIOS estuviera en "IDE" y no en "LSI": yo no he tocado nada. A
lo mejor se desconfiguró cuando actualicé la BIOS (aunque tampoco sé
cuál era su valor antes de la actualización).

El problema que tengo ahora es que no sé cómo narices identificar uno de
otro disco para que el disco que ha estado esta semana trabajando sea el
disco primario del RAID. Debería haber una forma, pero soy incapaz de
verla. Al menos mientras el RAID estuvo montado: a lo mejor sí se puede
ver al crear el RAID.

Como ya he visto que el sistema en el ordenador funciona sin problemas,
lo haré la semana que viene. Con suerte ha desaparecido el problema,
aunque no sé muy bien cuál podría ser. La memoria la testeé y estaba
bien. :/

> Saludos,

Saludos.

-- 
   El amor es como los columpios, porque casi siempre empieza
siendo diversión y casi siempre acaba dando náuseas.
  --- Enrique Jardiel Poncela ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150116193520.ga9...@cubo.casa



Re: [OT] Raid por hardware

2015-01-12 Thread Camaleón
El Mon, 12 Jan 2015 13:12:00 +0100, José Miguel (sio2) escribió:

> El Sun, 11 de Jan de 2015, a las 04:29:13PM +, Camaleón dijo:
> 
>>> Sí, era el que usaba para comprobar el estado del RAID, antes de
>>> descubrir que también existía la utilidad lsiutil. Lo único que indica
>>> es el modelo también. De hecho, ni siquiera da información del
>>> progreso de la sincronización: sólo de que los discos no están
>>> sincronizados y de que se está en proceso de sincronización. Pero del
>>> tanto por ciento, nada de nada.
>> Pues no lo entiendo, la verdad. LSI no es precisamente un fabricante de
>> los considerados malillos, no tiene sentido que disponga de
>> herramientas para la gestión del raid tan "pobres", la menos la suya
>> (lsiutil) debería ser más completa pero parece que no :-?
> 
> Quizás me has entendido mal: es mpt-status el que no devuelve el
> porcentaje de la sincronización: lsiutil, sí. Lo que fui incapaz de
> encontrar con lsiutil fue la identificación del disco.

No me refería al estado de la sincronización sino al nº de serie de los 
discos, que no se entiende que ninguna de las dos herramientas te diga 
cuáles son. Sinceramente, incomprensible.

El hecho de que mpt-status no te diga el porcentaje de la reconstrucción 
no me extraña porque por la propia descripción del paquete parece más 
bien una herramienta de control y no tanto de gestión del raid, es decir, 
una especie de demonio que monitoriza el estado del raid y en caso de 
caída te informa de alguna manera (e-mail, wall), algo que las 
herramientas CLI convencionales que proporcionan los fabricantes no 
suelen disponer ya que se ejecutan una vez para trabajar con el raid pero 
poco más. Es decir, que mpt-status vendría a ser el complemento perfecto 
de lsiutil, cada una con funciones bien definidas.

>> No, no... qué va, no vale. Recuerda que en el supuesto que estamos
>> tratando estás "deshaciendo" el raid 1: pinchas un disco únicamente en
>> una controladora de disco duro distinta. Lo normal en ese caso es que
>> si se tratara de un volumen de inicio no pudiera arrancar.
>> > La definición del RAID en sí puede estar almacenada en memoria flash
>> > y no hay que guardar metadatos del RAID en los discos duros.
>> ¿En qué memoria flash?
> 
> En la de la propia controladora RAID, que tiene su propia BIOS
> actualizable por lo que debe tener memoria flash.

Mucho esperas... Me extrañaría que tuviera memoria flash con capacidad 
suficiente para albergar los datos más allá de los que necesita (firmware 
y metadatos). Salvo que la controladora sea buena (pero de las buenas de 
verdad que tienen un batería y todas esas gaitas) y aún así tendría mis 
dudas.

>> Los datos del RAID quedan en los discos duros y la controladora RAID es
>> la que se encarga de interpretarlos, de ahí que mientras conectes los
>> discos a una controladora igual no haya problemas pero no sucede lo
>> mismo si los discos se conectan a una controladora distinta (sea RAID o
>> no).
> 
> Pues he probado a conectar el otro disco a otro ordenador y arranca sin
> problemas. Como uno lo conecté al servidor pero no a través de la
> controladora y otro a otro ordenador sin ella, ambos discos han
> arrancado y funciona su sistema perfectamente sin la controladora. 

Si el kernel donde tienes instalado el sistema ya tiene en su imagen el 
driver de la nueva controladora donde has conectado el disco, no tienes 
que hacer nada, lo cargará al iniciarse. 

> Así que los datos de definición del RAID deben de estar en la propia
> controladora, porque el único lugar libre que se me ocurre en los discos
> es el espacio que hay entre el MBR y el principio de la primera
> partición. Pero ese espacio ya lo usa grub, al menos en parte. Además el
> RAID se puede inicializar antes de tener hecha ninguna partición. He
> mirado con fdisk la definición de las particiones del disco (que ya no
> gestiona la controladora) y no hay nada raro en ellas. La primera
> empieza en el sector 2048.

Creo que tienes un error de concepto. Cuando inicializas los discos desde 
la utilidad de la controladora raid para empezar a definir el nivel de 
raid que quieres y el resto de datos del array, lo que estás haciendo es 
grabar esa información en los discos duros que hayas seleccionado para 
formar parte del array. Los datos se almacenan en lo que llama 
"superbloques persistentes" (igual que cuando usas raid por software o 
"md").

Lo que no tenía tan claro es que se pudiera iniciar un sistema que tenía 
un raid 1 (definido por una controladora hardware raid) con un único 
disco, no sé por qué pero algo me dice que en windows te encontrarías con 
un bonito pantallazo azul, pero quizá en linux sea diferente :-)

>>> El driver no lo estoy usando para nada ahora mismo. De hecho acabo de
>>> hacer unos rmmod para eliminar todos los drivers mtp* y los he
>>> descargado sin problemas.
>> Pues la salida que enviaste de lspci decía que estaban en uso:
> 
> La salida dice que lo está usando la controladora, lo cual

Re: [OT] Raid por hardware

2015-01-12 Thread sio2
El Sun, 11 de Jan de 2015, a las 04:29:13PM +, Camaleón dijo:

>> Sí, era el que usaba para comprobar el estado del RAID, antes de
>> descubrir que también existía la utilidad lsiutil. Lo único que indica
>> es el modelo también. De hecho, ni siquiera da información del progreso
>> de la sincronización: sólo de que los discos no están sincronizados y de
>> que se está en proceso de sincronización. Pero del tanto por ciento,
>> nada de nada.
> Pues no lo entiendo, la verdad. LSI no es precisamente un fabricante de 
> los considerados malillos, no tiene sentido que disponga de herramientas 
> para la gestión del raid tan "pobres", la menos la suya (lsiutil) debería 
> ser más completa pero parece que no :-?

Quizás me has entendido mal: es mpt-status el que no devuelve el
porcentaje de la sincronización: lsiutil, sí. Lo que fui incapaz de
encontrar con lsiutil fue la identificación del disco.

> No, no... qué va, no vale. Recuerda que en el supuesto que estamos 
> tratando estás "deshaciendo" el raid 1: pinchas un disco únicamente en 
> una controladora de disco duro distinta. Lo normal en ese caso es que si 
> se tratara de un volumen de inicio no pudiera arrancar.
> > La definición del RAID en sí puede estar almacenada en memoria flash y
> > no hay que guardar metadatos del RAID en los discos duros.
> ¿En qué memoria flash?

En la de la propia controladora RAID, que tiene su propia BIOS actualizable
por lo que debe tener memoria flash.

> Los datos del RAID quedan en los discos duros y la 
> controladora RAID es la que se encarga de interpretarlos, de ahí que 
> mientras conectes los discos a una controladora igual no haya problemas 
> pero no sucede lo mismo si los discos se conectan a una controladora 
> distinta (sea RAID o no).

Pues he probado a conectar el otro disco a otro ordenador y arranca sin
problemas. Como uno lo conecté al servidor pero no a través de la
controladora y otro a otro ordenador sin ella, ambos discos han
arrancado y funciona su sistema perfectamente sin la controladora. Así
que los datos de definición del RAID deben de estar en la propia
controladora, porque el único lugar libre que se me ocurre en los discos
es el espacio que hay entre el MBR y el principio de la primera
partición. Pero ese espacio ya lo usa grub, al menos en parte. Además el
RAID se puede inicializar antes de tener hecha ninguna partición. He
mirado con fdisk la definición de las particiones del disco (que ya no
gestiona la controladora) y no hay nada raro en ellas. La primera
empieza en el sector 2048.
 
>> El driver no lo estoy usando para nada ahora mismo. De hecho acabo de
>> hacer unos rmmod para eliminar todos los drivers mtp* y los he
>> descargado sin problemas.
> Pues la salida que enviaste de lspci decía que estaban en uso:

La salida dice que lo está usando la controladora, lo cual es normal
porque sigue pinchada y no la he deshabilitado. Como es software plug
and play, durante el arranque se detecta que hay una controladora y se
carga su driver para usarla.

Pero no estoy usando la controladora para acceder a disco porque el
disco lo pinché directamente a la placa base. De hecho, he descargado
los módulos mpt* y se hizo sin problemas. Si hago ahora un lspci -v
no sale la línea esa que indica que ese driver está usando el módulo.
En concreto esta que citas:

>   Kernel driver in use: mptsas

> > O incluso puedo pinchar unos de los discos en un ordenador
> > completamente diferente y mirar a ver si en ese ordenador el sistema
> > tiene los lapsus que tiene en el servidor.
> 
> Bueno, con eso cuidado porque es posible que no inicie a la primera y que 
> (dependiendo de cómo tengas detectados los discos duros) tengas que hacer 
> cambios en el gestor de arranque o cargar el módulo del kernel que se 
> encargue de la controladora de los discos duros en el nuevo equipo.

Ha funcionado sin problemas. Como la placa exige tarjetas PCI de perfil
bajo, no he podido pincharle tarjetas de red para que haga exactamente
la labor del servidor y dejarlo un par de días, que sería lo suyo. Lo
que si hice fue actualizar paquetes, que es una tarea que el servidor
hace siempre anormalmente lenta, y la velocidad fue la normal. Si
pudiera hacer una prueba definitiva haciendo que se tire unos días
sustituyendo al servidor, podría descartar algún fallo de configuración,
y buscar entre el hardware del servidor el culpable. Pero tengo el
problema de la caja.

Mañana por la tarde haré algunas cosillas que tengo pendientes (chequear
la memoria y deshabilitar la controladora RAID en la BIOS si es
posible).

> Saludos,

Saludos.

-- 
   Et nulla stringo, et tutto 'l mondo abraccio
  --- Francisco Petrarca ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150112121200.ga2...@cubo.casa



Re: [OT] Raid por hardware

2015-01-11 Thread Camaleón
El Sat, 10 Jan 2015 17:06:53 +0100, José Miguel (sio2) escribió:

> El Sat, 10 de Jan de 2015, a las 03:00:54PM +, Camaleón dijo:
> 
>>> ¿Dónde yo sólo veo una numeración que es igual para ambos discos
>>> (ST3250620NS), porque esa numeración indica el modelo?
>> Anda... pues tienes razón, es el modelo de los discos y si los tienes
>> iguales no te sirve de nada, claro.
>> 
>> [...]
>>
>> Recuerda que también tienes el driver libre para monitorizar el raid
>> ("mtp-status"), nunca está de más comparar los resultados de dos
>> aplicaciones.
> 
> Sí, era el que usaba para comprobar el estado del RAID, antes de
> descubrir que también existía la utilidad lsiutil. Lo único que indica
> es el modelo también. De hecho, ni siquiera da información del progreso
> de la sincronización: sólo de que los discos no están sincronizados y de
> que se está en proceso de sincronización. Pero del tanto por ciento,
> nada de nada.

Pues no lo entiendo, la verdad. LSI no es precisamente un fabricante de 
los considerados malillos, no tiene sentido que disponga de herramientas 
para la gestión del raid tan "pobres", la menos la suya (lsiutil) debería 
ser más completa pero parece que no :-?

>> Porque como te he dicho antes, la información de los datos del raid
>> (metadatos) está en los discos duros y no estoy del todo segura de que
>> el comportamiento de un disco duro que contiene información de un raid
>> funcione correctamente sin estar conectado a la misma controladora y
>> sin el resto de discos que forman la matriz. De hecho esa suele ser una
>> de las pegas de los raid por hardware, que las migraciones no son
>> sencillas.
> 
> Entiendo que eso que dices sea necesario para un RAID por software, pero
> por que va a ser necesario en un RAID por hardware? Con que la
> controladora se encargue de abstraer el acceso a ambos discos, de manera
> que a ojos del sistema operativo sólo se vea uno vale, ¿no?

No, no... qué va, no vale. Recuerda que en el supuesto que estamos 
tratando estás "deshaciendo" el raid 1: pinchas un disco únicamente en 
una controladora de disco duro distinta. Lo normal en ese caso es que si 
se tratara de un volumen de inicio no pudiera arrancar.

> La definición del RAID en sí puede estar almacenada en memoria flash y
> no hay que guardar metadatos del RAID en los discos duros.

¿En qué memoria flash? Los datos del RAID quedan en los discos duros y la 
controladora RAID es la que se encarga de interpretarlos, de ahí que 
mientras conectes los discos a una controladora igual no haya problemas 
pero no sucede lo mismo si los discos se conectan a una controladora 
distinta (sea RAID o no).

>>> No parece que haya ninguna controladora integrada:
>> Hombre, tiene que haberla, eso seguro. No puedes pinchar los discos en
>> el aire :-)
> 
> Bueno, sí, me refería a que no había ningún pseudo-RAID integrado en la
> placa.

Sí y no. Las tarjetas de tipo ZCR (zero channel raid) no son del todo 
bien vistas aunque los drivers del kernel sean los mismos que los que 
usan sus hermanas mayores (controladoras independientes).

(...)

>> Bueno, recuerda que no las estás usando pero sigues con el mismo driver
>> (mtpsas), y si el problema está en el driver es como si no hubieras
>> hecho nada.
> 
> El driver no lo estoy usando para nada ahora mismo. De hecho acabo de
> hacer unos rmmod para eliminar todos los drivers mtp* y los he
> descargado sin problemas.

Pues la salida que enviaste de lspci decía que estaban en uso:

07:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET
PCI-Express Fusion-MPT SAS (rev 08)
(...)
Kernel driver in use: mptsas
  ^^

Y no tienes más puertos sas/sata en el equipo, así que sería interesante 
ver qué módulos tienes cargados actualmente que se encarguen de tus 
discos duros.

> No sé muy bien qué hacer. Puedo intentar deshabilitar la controladora
> del RAID para descartarla definitivamente. 

Si tu BIOS lo permite, sí, ponerlo en modo AHCI sería una opción para 
comprobar si sigues notando esa lentitud en el sistema.

> También se me ocurre hacer un memtest a ver si tengo algún problema con
> la memoria  

Eso nunca está de más, incluso puedes quitar algún módulo de memoria para 
ver si notas alguna diferencia.

> O incluso puedo pinchar unos de los discos en un ordenador
> completamente diferente y mirar a ver si en ese ordenador el sistema
> tiene los lapsus que tiene en el servidor.

Bueno, con eso cuidado porque es posible que no inicie a la primera y que 
(dependiendo de cómo tengas detectados los discos duros) tengas que hacer 
cambios en el gestor de arranque o cargar el módulo del kernel que se 
encargue de la controladora de los discos duros en el nuevo equipo.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.11.16.29...@gmail.com



Re: [OT] Raid por hardware

2015-01-10 Thread sio2
El Sat, 10 de Jan de 2015, a las 03:00:54PM +, Camaleón dijo:

>> ¿Dónde yo sólo veo una numeración que es igual para ambos discos
>> (ST3250620NS), porque esa numeración indica el modelo?
> Anda... pues tienes razón, es el modelo de los discos y si los tienes 
> iguales no te sirve de nada, claro. 
> 
> [...]
>
> Recuerda que también tienes el driver libre para monitorizar el raid 
> ("mtp-status"), nunca está de más comparar los resultados de dos 
> aplicaciones.

Sí, era el que usaba para comprobar el estado del RAID, antes de
descubrir que también existía la utilidad lsiutil. Lo único que indica
es el modelo también. De hecho, ni siquiera da información del progreso
de la sincronización: sólo de que los discos no están sincronizados y de
que se está en proceso de sincronización. Pero del tanto por ciento,
nada de nada.
 
> Porque como te he dicho antes, la información de los datos del raid 
> (metadatos) está en los discos duros y no estoy del todo segura de que el 
> comportamiento de un disco duro que contiene información de un raid 
> funcione correctamente sin estar conectado a la misma controladora y sin 
> el resto de discos que forman la matriz. De hecho esa suele ser una de 
> las pegas de los raid por hardware, que las migraciones no son sencillas.

Entiendo que eso que dices sea necesario para un RAID por software, pero
por que va a ser necesario en un RAID por hardware? Con que la
controladora se encargue de abstraer el acceso a ambos discos, de manera
que a ojos del sistema operativo sólo se vea uno vale, ¿no?

La definición del RAID en sí puede estar almacenada en memoria flash y
no hay que guardar metadatos del RAID en los discos duros.

>> No parece que haya ninguna controladora integrada:
> Hombre, tiene que haberla, eso seguro. No puedes pinchar los discos en el 
> aire :-)

Bueno, sí, me refería a que no había ningún pseudo-RAID integrado en la
placa.

> Ondiá. Vale, ya veo lo que pasa. Esa placa base tiene dos controladoras 
> IDE/ATA y una controladora SAS/SATA que no es una controladora 
> independiente (de las que puedes pinchar en cualquier placa base) sino de 
> las tipo "zero channel", son tarjetas específicas para determinadas 
> placas y que hacen uso del puerto PCI-e/PCI-X pero también dependen de la 
> BIOS de la placa base para gestionar el RAID (en el manual de la placa 
> base tendrás información ampliada sobre este tipo de chipsets y también 
> te dirá si puedes desactivarlo o no).

Miraré eso a ver.

> No, no... el driver AHCI sólo se carga cuando tienes configurado en la 
> BIOS una controladora SATA que permita configurarse en los modos 
> habituales [ide/ata/legacy, achi, raid]. Al seleccionar "ahci" es cuando 
> el kernel debería cagar ese módulo.

Vale, entiendo.

> Bueno, recuerda que no las estás usando pero sigues con el mismo driver 
> (mtpsas), y si el problema está en el driver es como si no hubieras hecho 
> nada.

El driver no lo estoy usando para nada ahora mismo. De hecho acabo de
hacer unos rmmod para eliminar todos los drivers mtp* y los he descargado
sin problemas.

No sé muy bien qué hacer. Puedo intentar deshabilitar la controladora
del RAID para descartarla definitivamente. También se me ocurre hacer un
memtest a ver si tengo algún problema con la memoria  O incluso puedo
pinchar unos de los discos en un ordenador completamente diferente y
mirar a ver si en ese ordenador el sistema tiene los lapsus que tiene en
el servidor.

> Saludos,

Saludos.

-- 
   Patrimonio es un conjunto de bienes, matrimonio es un
conjunto de males.
  --- Enrique Jardiel Poncela --


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150110160653.ga24...@cubo.casa



Re: [OT] Raid por hardware

2015-01-10 Thread Camaleón
El Sat, 10 Jan 2015 13:30:15 +0100, José Miguel (sio2) escribió:

> El Fri, 09 de Jan de 2015, a las 06:26:43PM +, Camaleón dijo:
> 
>> Qué raro... fíjate que en el ejemplo que ponen en la página que te pasé
>> siguen exactamente la misma secuencia 21/2 y el resultado muestra el nº
>> de serie de los discos:
> 
>> [...]
>> 
>> PhysDisk 0 is Bus 0 Target 1
>>   PhysDisk State:  online PhysDisk Size 238418 MB, Inquiry Data:  ATA  
>>  ST3250620NS  3BKS
>> 
>> PhysDisk 1 is Bus 0 Target 8
>>   PhysDisk State:  online PhysDisk Size 238418 MB, Inquiry Data:  ATA  
>>  ST3250620NS  3BKS
>> ***
> 
> 
> ¿Dónde yo sólo veo una numeración que es igual para ambos discos
> (ST3250620NS), porque esa numeración indica el modelo?

Anda... pues tienes razón, es el modelo de los discos y si los tienes 
iguales no te sirve de nada, claro. 

Me parece raro que "lsiutil" no permita ver el número de serie porque lo 
interesante es saber cómo y dónde ha detectado la controladora raid los 
discos duros para poder trabajar con ellos porque de nada te sirve ver el 
número de serie desde fuera (p. ej., desde smartctl) ya que no sabes a 
qué ID ha asignado la controladora ese nº de serie.

Recuerda que también tienes el driver libre para monitorizar el raid 
("mtp-status"), nunca está de más comparar los resultados de dos 
aplicaciones.

>>> No toqué la BIOS para desactivar la controladora (miraré el lunes a
>>> ver cómo se hace). Lo que sí hice fue desconectar los discos de la
>>> controladora y conectarlos directamente a la placa base.
>> Carallo. ¿Y te inició el sistema sin más? :-?
> 
> ¿Y por qué no lo iba a hacer? La controladora se encarga de duplicar la
> información simplemente haciendo escrituras en ambos discos: pero la
> información es la información, ¿no?

Porque como te he dicho antes, la información de los datos del raid 
(metadatos) está en los discos duros y no estoy del todo segura de que el 
comportamiento de un disco duro que contiene información de un raid 
funcione correctamente sin estar conectado a la misma controladora y sin 
el resto de discos que forman la matriz. De hecho esa suele ser una de 
las pegas de los raid por hardware, que las migraciones no son sencillas.

Luego está el tema del driver que uses, es decir, si en linux has 
instalado el módulo mtpsas y al pinchar el disco a una controladora 
diferente necesitas un módulo distinto que no esté incluido en el kernel 
base no te va a reconocer el disco y no podrá iniciarse el sistema. 

Por eso te decía que has tenido mucha suerte.
 
>> Bueno, el estado del RAID no era normal, y eso no es casual. La
>> controladora estaba detectando algo que no le gustaba pero si mal no
>> recuerdo hiciste una actualización de la BIOS de la placa base y el
>> problema se produjo tras esa actualización.
> 
> No, el problema puede que fuera anterior. 

¡Tongo! :-)

> Resulta que la partición raíz se me puso en modo lectura por un fallo
> de disco. Miré los log y además del fallo de disco, vi que los mensajes
> de arranque me decían que la versión de la BIOS de la placa base tenían
> bugs y que la actualizara. De hecho, tengo conectada una tarjeta de red
> PCI con cuatro bocas y cuando hacía un arranque en caliente (un reboot,
> por ejemplo) desaparecía de mi sistema (no aparecía en un lspci). Así
> que actualicé la BIOS: dejó de aparecer el mensaje y, además,
> desapareció el problema de la tarjeta.

Entonces el estado del disco duro que veías en la controladora puede que 
viniera de esos lodos, es decir, que tuviera alguna tarea pendiente de 
hacer (reconstrucción) y que no estuviera relacionado con la 
actualización de la BIOS de la placa base.

>> Hum... por curiosidad (si puedes) manda la salida de "lspci -v" a ver
>> qué cosicas tiene ese equipo, quizá la controladora sas/sata integrada
>> en la placa base también use el driver mtp :-?
> 
> No parece que haya ninguna controladora integrada:

Hombre, tiene que haberla, eso seguro. No puedes pinchar los discos en el 
aire :-)

(se me olvidó decirte que lo ejecutaras como root pero bueno, se ven 
todos los datos interesantes)

> 00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4
> port SATA Controller [IDE mode] (rev 02) (prog-if 8a [Master SecP PriP])
>   Subsystem: Intel Corporation Device 34d0 Flags: bus master, 66MHz,
>   medium devsel, latency 0, IRQ 21 I/O ports at 01f0 [size=8]
>   I/O ports at 03f4 [size=1]
>   I/O ports at 0170 [size=8]
>   I/O ports at 0374 [size=1]
>   I/O ports at 7410 [size=16]
>   I/O ports at 7400 [size=16]
>   Capabilities: 
>   Kernel driver in use: ata_piix

(...)

> 00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port
> SATA Controller [IDE mode] (rev 02) (prog-if 85 [Master SecO PriO])
>   Subsystem: Intel Corporation Device 34d0 Flags: bus master, 66MHz,
>   medium devsel, latency 0, IRQ 21 I/O ports at 7428 [size=8]
>   I/O ports at 7444 [size=4]
>   I/O ports at 7420 [siz

Re: [OT] Raid por hardware

2015-01-10 Thread sio2
El Fri, 09 de Jan de 2015, a las 06:26:43PM +, Camaleón dijo:

> Qué raro... fíjate que en el ejemplo que ponen en la página que te pasé 
> siguen exactamente la misma secuencia 21/2 y el resultado muestra el nº 
> de serie de los discos:

> [...]
> 
> PhysDisk 0 is Bus 0 Target 1
>   PhysDisk State:  online
>   PhysDisk Size 238418 MB, Inquiry Data:  ATA  ST3250620NS  3BKS
> 
> PhysDisk 1 is Bus 0 Target 8
>   PhysDisk State:  online
>   PhysDisk Size 238418 MB, Inquiry Data:  ATA  ST3250620NS  3BKS
> ***


¿Dónde yo sólo veo una numeración que es igual para ambos discos
(ST3250620NS), porque esa numeración indica el modelo?

>> No toqué la BIOS para desactivar la controladora (miraré el lunes a ver
>> cómo se hace). Lo que sí hice fue desconectar los discos de la
>> controladora y conectarlos directamente a la placa base.
> Carallo. ¿Y te inició el sistema sin más? :-?

¿Y por qué no lo iba a hacer? La controladora se encarga de duplicar la
información simplemente haciendo escrituras en ambos discos: pero la
información es la información, ¿no?

> Bueno, el estado del RAID no era normal, y eso no es casual. La 
> controladora estaba detectando algo que no le gustaba pero si mal no 
> recuerdo hiciste una actualización de la BIOS de la placa base y el 
> problema se produjo tras esa actualización.

No, el problema puede que fuera anterior. Resulta que la partición raíz
se me puso en modo lectura por un fallo de disco. Miré los log y además
del fallo de disco, vi que los mensajes de arranque me decían que la
versión de la BIOS de la placa base tenían bugs y que la actualizara. De
hecho, tengo conectada una tarjeta de red PCI con cuatro bocas y cuando
hacía un arranque en caliente (un reboot, por ejemplo) desaparecía de mi
sistema (no aparecía en un lspci). Así que actualicé la BIOS: dejó de
aparecer el mensaje y, además, desapareció el problema de la tarjeta.

> Hum... por curiosidad (si puedes) manda la salida de "lspci -v" a ver qué 
> cosicas tiene ese equipo, quizá la controladora sas/sata integrada en la 
> placa base también use el driver mtp :-?

No parece que haya ninguna controladora integrada:

#v+
00:00.0 Host bridge: Intel Corporation 3200/3210 Chipset DRAM Controller
Subsystem: Intel Corporation Device 34d0
Flags: bus master, fast devsel, latency 0
Capabilities: 
Kernel driver in use: i3200_edac

00:06.0 PCI bridge: Intel Corporation 3210 Chipset Host-Secondary PCI Express 
Bridge (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=06, sec-latency=0
I/O behind bridge: 3000-6fff
Memory behind bridge: e1f0-e1ff
Prefetchable memory behind bridge: e190-e1cf
Capabilities: 
Kernel driver in use: pcieport

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network 
Connection (rev 02)
Subsystem: Intel Corporation Device 34d0
Flags: bus master, fast devsel, latency 0, IRQ 48
Memory at e200 (32-bit, non-prefetchable) [size=128K]
Memory at e202 (32-bit, non-prefetchable) [size=4K]
I/O ports at 70c0 [size=32]
Capabilities: 
Kernel driver in use: e1000e

00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Device 34d0
Flags: bus master, medium devsel, latency 0, IRQ 18
I/O ports at 70a0 [size=32]
Capabilities: 
Kernel driver in use: uhci_hcd

00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation Device 34d0
Flags: bus master, medium devsel, latency 0, IRQ 21
I/O ports at 7080 [size=32]
Capabilities: 
Kernel driver in use: uhci_hcd

00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 (rev 02) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Device 34d0
Flags: bus master, medium devsel, latency 0, IRQ 17
Memory at e2021400 (32-bit, non-prefetchable) [size=1K]
Capabilities: 
Kernel driver in use: ehci_hcd

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 
(rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=07, subordinate=07, sec-latency=0
I/O behind bridge: 2000-2fff
Memory behind bridge: e1e0-e1ef
Prefetchable memory behind bridge: f840-f87f
Capabilities: 
Kernel driver in use: pcieport

00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 
(rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=08, subordinate=08, sec-latenc

Re: [OT] Raid por hardware

2015-01-09 Thread Camaleón
El Fri, 09 Jan 2015 18:44:21 +0100, José Miguel (sio2) escribió:

> El Fri, 09 de Jan de 2015, a las 03:38:52PM +, Camaleón dijo:
> 
>>> Sí, vi que smartctl me mostraba ese número de serie. El problema es
>>> que no vi que ese número de serie me lo proporcionara ni lsiutil ni la
>>> BIOS de la controladora. Así que por un lado podía identificar los
>>> discos, pero no cuál estaba desincronizado y, por otro, podía saber
>>> cuál está desincronizado pero no identificarlo físicamente.
>> lsiutil debe decírtelo... espera que lo consulto desde el pdf que
>> enviaste... vale, creo que debe ser el menú 21 / opción 2 ("show
>> physical disks") a lo que deberás pasar el número de la controladora
>> (suele ser 1 salvo que tengas varias) para que te muestre todos los
>> datos de los discos que tienes conectados.
> 
> Es lo primero que consulté: no lo pone. Pone qué tipo de disco es
> WD-noséqué (WD de WesternDigital), pero ambos discos son iguales en este
> aspecto. Recuerdo que indica también un PhysDev (uno es el 0 y el otro
> un 1), pero no el número de serie que sí aparece usando smartctl.

Qué raro... fíjate que en el ejemplo que ponen en la página que te pasé 
siguen exactamente la misma secuencia 21/2 y el resultado muestra el nº 
de serie de los discos:

***
http://hwraid.le-vert.net/wiki/LSIFusionMPT#a3.2.lsiutil

Main menu, select an option:  [1-99 or e/p/w or 0 to quit] 21

(...)

RAID actions menu, select an option:  [1-99 or e/p/w or 0 to quit] 2

1 volume is active, 2 physical disks are active

PhysDisk 0 is Bus 0 Target 1
  PhysDisk State:  online
  PhysDisk Size 238418 MB, Inquiry Data:  ATA  ST3250620NS  3BKS

PhysDisk 1 is Bus 0 Target 8
  PhysDisk State:  online
  PhysDisk Size 238418 MB, Inquiry Data:  ATA  ST3250620NS  3BKS
***

>>> Al final, como tengo backups de los datos realmente importantes y el
>>> servidor pelado instalado en un disco virtual, decidí probar fortuna y
>>> deshice el raid por hardware.
>> Yeeech. Con un par :-S
> 
> Bueno, algo había que hacer...
> 
> He comprobado que los dos discos arrancan el sistema sin errores. Si
> logro solucionar el problema y no es por culpa de la controladora,
> siempre puedo volver a ponerlos en RAID: al crearlo se respetan los
> datos del disco primario.

Los datos (la información) del RAID se guardan en los discos duros, por 
eso cuando se cambia la controladora y se reemplaza con otra del mismo 
modelo no hay problema.

>> > Pero esto no soluciona el problema. El servidor sigue yendo
>> > anormalmente lento y creo que ese es el problema del que se derivan
>> > todos (quizás incluso el de la eterna resincronización del RAID).
>> Pero ¿con deshacer el raid ya es suficiente? Supongo que habrás tenido
>> que desactivar la controladora raid desde la bios, ponerlo en modo ahci
>> y volcar los datos/particiones de nuevo ¿no? Porque de lo contrario
>> seguirás usando el mismo módulo del kernel (mtp*) y si no quieres raid
>> por harwdare convendría que usaras el driver abierto achi que te dará
>> menos problemas.
> 
> No toqué la BIOS para desactivar la controladora (miraré el lunes a ver
> cómo se hace). Lo que sí hice fue desconectar los discos de la
> controladora y conectarlos directamente a la placa base.

Carallo. ¿Y te inició el sistema sin más? :-?

> Quizás mi problema no tenga nada que ver con el RAID ni la controladora.
> Como el sistema iba lento lo achaqué a la constante lectura y escritura
> en disco, y esta constante lectura y escritura a que no se sincronizaban
> los discos y la no sincronización a un fallo del RAID. Pero quizás el
> problema es justamente el contrario: el que se me trastabille el
> servidor de vez en cuando es lo que genera mis problemas de
> sincronización con el RAID.

Bueno, el estado del RAID no era normal, y eso no es casual. La 
controladora estaba detectando algo que no le gustaba pero si mal no 
recuerdo hiciste una actualización de la BIOS de la placa base y el 
problema se produjo tras esa actualización.
 
>> MIra a ver si sigue cargado el controlador de la tarjeta (mtp*) o estás
>> usando el driver ahci (lsmod)
> 
> El módulo se sigue cargando: lo cual es lógico porque no deshabilité la
> controladora. ahci no aparece, pero tampoco lo hace en el otro servidor
> que no tiene controladora. Quizás el núcleo de debian lo incluye
> integrado en el núcleo y no como módulo aparte.

Hum... por curiosidad (si puedes) manda la salida de "lspci -v" a ver qué 
cosicas tiene ese equipo, quizá la controladora sas/sata integrada en la 
placa base también use el driver mtp :-?

> A mí lo que me escama es que el servidor se quede trabado alguna vez
> unos segundos, incluso con los comandos más insignificantes.
> Posiblemente todos mis problema nacen de esto. Pero no tengo ni idea de
> a qué se debe.

¿No tienes nada en el "dmesg"? Por cierto, la controladora también debe 
tener un registro (búfer) interno, si lo tienes activado quizá tengas 
algún dato relevante.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIB

Re: [OT] Raid por hardware

2015-01-09 Thread sio2
El Fri, 09 de Jan de 2015, a las 03:38:52PM +, Camaleón dijo:

>> Sí, vi que smartctl me mostraba ese número de serie. El problema es que
>> no vi que ese número de serie me lo proporcionara ni lsiutil ni la BIOS
>> de la controladora. Así que por un lado podía identificar los discos,
>> pero no cuál estaba desincronizado y, por otro, podía saber cuál está
>> desincronizado pero no identificarlo físicamente.
> lsiutil debe decírtelo... espera que lo consulto desde el pdf que 
> enviaste... vale, creo que debe ser el menú 21 / opción 2 ("show physical 
> disks") a lo que deberás pasar el número de la controladora (suele ser 1 
> salvo que tengas varias) para que te muestre todos los datos de los 
> discos que tienes conectados.

Es lo primero que consulté: no lo pone. Pone qué tipo de disco es
WD-noséqué (WD de WesternDigital), pero ambos discos son iguales en este
aspecto. Recuerdo que indica también un PhysDev (uno es el 0 y el otro
un 1), pero no el número de serie que sí aparece usando smartctl.

>> Al final, como tengo backups de los datos realmente importantes y el
>> servidor pelado instalado en un disco virtual, decidí probar fortuna y
>> deshice el raid por hardware.
> Yeeech. Con un par :-S

Bueno, algo había que hacer...

He comprobado que los dos discos arrancan el sistema sin errores. Si
logro solucionar el problema y no es por culpa de la controladora,
siempre puedo volver a ponerlos en RAID: al crearlo se respetan los
datos del disco primario.

> > Pero esto no soluciona el problema. El servidor sigue yendo anormalmente
> > lento y creo que ese es el problema del que se derivan todos (quizás
> > incluso el de la eterna resincronización del RAID).
> Pero ¿con deshacer el raid ya es suficiente? Supongo que habrás tenido 
> que desactivar la controladora raid desde la bios, ponerlo en modo ahci y 
> volcar los datos/particiones de nuevo ¿no? Porque de lo contrario 
> seguirás usando el mismo módulo del kernel (mtp*) y si no quieres raid 
> por harwdare convendría que usaras el driver abierto achi que te dará 
> menos problemas.

No toqué la BIOS para desactivar la controladora (miraré el lunes a ver
cómo se hace). Lo que sí hice fue desconectar los discos de la
controladora y conectarlos directamente a la placa base.

Quizás mi problema no tenga nada que ver con el RAID ni la controladora.
Como el sistema iba lento lo achaqué a la constante lectura y
escritura en disco, y esta constante lectura y escritura a que no se
sincronizaban los discos y la no sincronización a un fallo del RAID.
Pero quizás el problema es justamente el contrario: el que se me
trastabille el servidor de vez en cuando es lo que genera mis problemas
de sincronización con el RAID.

> MIra a ver si sigue cargado el controlador de la tarjeta (mtp*) o estás 
> usando el driver ahci (lsmod)

El módulo se sigue cargando: lo cual es lógico porque no deshabilité la
controladora. ahci no aparece, pero tampoco lo hace en el otro servidor
que no tiene controladora. Quizás el núcleo de debian lo incluye
integrado en el núcleo y no como módulo aparte.

A mí lo que me escama es que el servidor se quede trabado alguna vez
unos segundos, incluso con los comandos más insignificantes.
Posiblemente todos mis problema nacen de esto. Pero no tengo ni idea de
a qué se debe.

> Saludos,

Saludos.

-- 
   Parezco en mi fortuna al Manzanares,
que con agua o sin ella siempre es río.
  --- Tomé de Burguillos ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109174421.ga11...@cubo.casa



Re: [OT] Raid por hardware

2015-01-09 Thread Camaleón
El Thu, 08 Jan 2015 21:52:42 +0100, José Miguel (sio2) escribió:

> El Thu, 08 de Jan de 2015, a las 03:06:54PM +, Camaleón dijo:
> 
>> > Y de la opción 21 (RAID options) no dice nada de nada.
>> 
>> Te dice que sirve para obtener información del RAID y de las opciones
>> que permite, que son varias, la verdad.
> 
> Cierto, pero es que esas opciones... son las que ya se ven si se ejecuta
> el programa.

Correcto, pero añaden alguna cosilla más que nunca está de más para los 
comandos que son menos obvios.

> [...]
> 
>>> Le he pasado el test "short" y el "conveyance" a ambos discos. Ambos
>>> sin problemas. Puedo intentar pasarle el "long" a lo largo de la noche
>>> a ver sí dice algo más.
>> 
>> Pásale el test extendido, merece la pena y así te quedas más tranquilo.
> 
> Los discos parecen estar bien,

Si le has pasado el test largo y no te ha detectado ningún error, 
perfecto.

>> > Otro problema que tengo es que físicamente no sé cuál es cuál.
> 
>> Las controladoras RAID suelen tener una opción para identificar los
>> discos cuando están en una cabina extraíble (a través de un comando que
>> los "ilumina"), no sé si será tu caso.
> 
> Vi en un manual de oracle para un servidor que tiene una controladora
> LSI cómo hacerlo desde su BIOS. Probé, pero no me pareció que
> funcionara.

¿El manual de Oracle? :-? 

Conviene que consultes siempre el manual de la versión de tu 
controladora, aunque nunca está de más ver lo que dicen otros fabricantes 
porque te pueden poner ejemplos de uso ten en cuenta que las opciones y 
parámetros pueden variar.

>> Si no tienes acceso externo a los discos, usa el nº de serie para
>> identificarlos ("show PD" debería darte datos de los discos, tamaño, nº
>> de serie...).
> 
> Sí, vi que smartctl me mostraba ese número de serie. El problema es que
> no vi que ese número de serie me lo proporcionara ni lsiutil ni la BIOS
> de la controladora. Así que por un lado podía identificar los discos,
> pero no cuál estaba desincronizado y, por otro, podía saber cuál está
> desincronizado pero no identificarlo físicamente.

lsiutil debe decírtelo... espera que lo consulto desde el pdf que 
enviaste... vale, creo que debe ser el menú 21 / opción 2 ("show physical 
disks") a lo que deberás pasar el número de la controladora (suele ser 1 
salvo que tengas varias) para que te muestre todos los datos de los 
discos que tienes conectados.

> Al final, como tengo backups de los datos realmente importantes y el
> servidor pelado instalado en un disco virtual, decidí probar fortuna y
> deshice el raid por hardware.

Yeeech. Con un par :-S

> Pero esto no soluciona el problema. El servidor sigue yendo anormalmente
> lento y creo que ese es el problema del que se derivan todos (quizás
> incluso el de la eterna resincronización del RAID).
> 
> Ya desecho el RAID, arranqué con un disco y probé a hacer una
> actualización de los paquetes actualizados en wheezy. La descarga de los
> paquetes se hace a velocidad normal; sin embargo, el desempaquetado,
> sustitución y configuración de los paquetes nuevos es anormalmente
> lento.

Pero ¿con deshacer el raid ya es suficiente? Supongo que habrás tenido 
que desactivar la controladora raid desde la bios, ponerlo en modo ahci y 
volcar los datos/particiones de nuevo ¿no? Porque de lo contrario 
seguirás usando el mismo módulo del kernel (mtp*) y si no quieres raid 
por harwdare convendría que usaras el driver abierto achi que te dará 
menos problemas.

> Tengo otro servidor en otro sitio para comparar, aunque no tienen el
> mismo hardware, y no hay color: el servidor que me da problemas puede
> tardar como 10 veces más en hacer las mismas operaciones triviales.
> Ambos están practicamente sin trabajo, así que no es un problema de
> sobrecarga. Tampoco parece un problema de lectura y escritura en disco,
> porque hice algunas pruebas con dd y hdparm y los resultados eran
> normales.
> 
> No sé. En ocasiones el servidor se queda como pillado con un comando y
> al poco reacciona. Por ejemplo, al instalar hdparm escribí:
> 
> # aptitude installq hdparm
> 
> me di cuenta del error nada más pulsar Enter e instintivamente escribí
> ^C. Sin embargo, el programa no respondía al ^C aunque lo escribí varias
> veces. Así estuvo como veinte segundos, hasta que finalmente reaccionó y
> se abortó.
> 
> :/

MIra a ver si sigue cargado el controlador de la tarjeta (mtp*) o estás 
usando el driver ahci (lsmod)

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.09.15.38...@gmail.com



Re: [OT] Raid por hardware

2015-01-08 Thread sio2
El Thu, 08 de Jan de 2015, a las 03:06:54PM +, Camaleón dijo:

> > Y de la opción 21 (RAID options) no dice nada de nada. 
> 
> Te dice que sirve para obtener información del RAID y de las opciones que 
> permite, que son varias, la verdad.

Cierto, pero es que esas opciones... son las que ya se ven si se ejecuta
el programa.

[...]

>> Le he pasado el test "short" y el "conveyance" a ambos discos. Ambos sin
>> problemas. Puedo intentar pasarle el "long" a lo largo de la noche a ver
>> sí dice algo más.
> 
> Pásale el test extendido, merece la pena y así te quedas más tranquilo.

Los discos parecen estar bien,
> > Otro problema que tengo es que físicamente no sé cuál es cuál.

> Las controladoras RAID suelen tener una opción para identificar los 
> discos cuando están en una cabina extraíble (a través de un comando que 
> los "ilumina"), no sé si será tu caso.

Vi en un manual de oracle para un servidor que tiene una controladora
LSI cómo hacerlo desde su BIOS. Probé, pero no me pareció que
funcionara.

> Si no tienes acceso externo a los 
> discos, usa el nº de serie para identificarlos ("show PD" debería darte 
> datos de los discos, tamaño, nº de serie...).

Sí, vi que smartctl me mostraba ese número de serie. El problema es que
no vi que ese número de serie me lo proporcionara ni lsiutil ni la BIOS
de la controladora. Así que por un lado podía identificar los discos,
pero no cuál estaba desincronizado y, por otro, podía saber cuál está
desincronizado pero no identificarlo físicamente.

Al final, como tengo backups de los datos realmente importantes y el
servidor pelado instalado en un disco virtual, decidí probar fortuna y
deshice el raid por hardware.

Pero esto no soluciona el problema. El servidor sigue yendo
anormalmente lento y creo que ese es el problema del que se derivan
todos (quizás incluso el de la eterna resincronización del RAID).

Ya desecho el RAID, arranqué con un disco y probé a hacer una
actualización de los paquetes actualizados en wheezy. La descarga de los
paquetes se hace a velocidad normal; sin embargo, el desempaquetado,
sustitución y configuración de los paquetes nuevos es anormalmente
lento.

Tengo otro servidor en otro sitio para comparar, aunque no tienen el
mismo hardware, y no hay color: el servidor que me da problemas puede
tardar como 10 veces más en hacer las mismas operaciones triviales.
Ambos están practicamente sin trabajo, así que no es un problema de
sobrecarga. Tampoco parece un problema de lectura y escritura en disco,
porque hice algunas pruebas con dd y hdparm y los resultados eran
normales.

No sé. En ocasiones el servidor se queda como pillado con un comando y
al poco reacciona. Por ejemplo, al instalar hdparm escribí:

# aptitude installq hdparm

me di cuenta del error nada más pulsar Enter e instintivamente escribí
^C. Sin embargo, el programa no respondía al ^C aunque lo escribí varias
veces. Así estuvo como veinte segundos, hasta que finalmente reaccionó y
se abortó.

:/

> Saludos,

Saludos y muchas gracias.

-- 
   En la vida humana sólo unos pocos sueños se cumplen,
la mayoría se roncan.
  --- Enrique Jardiel Poncela ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150108205242.ga18...@cubo.casa



Re: [OT] Raid por hardware

2015-01-08 Thread Camaleón
El Wed, 07 Jan 2015 21:23:17 +0100, José Miguel (sio2) escribió:

> El Wed, 07 de Jan de 2015, a las 02:23:41PM +, Camaleón dijo:
> 
>> Tienes una página bastante maja donde, además de descargar los drivers
>> y utilidades para las controladoras más comunes, explican un poco el
>> funcionamiento de los comandos básicos para ver el estado de las
>> matrices y los discos, etc...
>> 
>> http://hwraid.le-vert.net/wiki/LSI
> 
> Sí, llegué a ella en mis pesquisas: por ella descubrí la existencia de
> lsiutil.

Está muy bien, la verdad. No sé quién está detrás pero se lo curra porque 
hay muchas utilidades que sólo he encontrado en esa página.

>> Te recomendaría que no hicieras movimientos bruscos (me refiero a eso
>> del "reset" que suena un pelín radical :-P), recuerda que simplemente
>> con reinicializar un disco eliminas todos los datos que contiene, es
>> decir, mucho cuidado al ejecutar cualquier comando en una controladora
>> RAID. Conviene que leas los manuales y FAQ que encuentres para saber
>> exactamente qué hace cada opción.
> 
> El problema es que la Guía de Usuario de lsiutil:
> 
> http://www.thomas-krenn.com/de/wikiDE/images/4/44/
Lsi_userguide_2006_20130528.pdf
> 
> apenas explica nada. 

Hombre, nada, nada... explicará los comandos disponibles y lo que hacen. 
Lo que faltará es cómo interpretar correctamente lo que significa.

> Y de la opción 21 (RAID options) no dice nada de nada. 

Te dice que sirve para obtener información del RAID y de las opciones que 
permite, que son varias, la verdad. Para quien está familiarizado con los 
términos no tendrá problemas, pero si nunca has usado/gestionado un RAID 
puede sonar a chino. De todas formas, lo importante es saber qué es lo 
que se uiere hacer, la forma de lograrlo está codificada en ese manual.

> Me gustaría, por ejemplo, quitar el disco desincronizado del RAID, pero
> no tengo muy claro si se puede hacer y cómo. 

El disco lo puedes quitar cuando quieras, si la controladora y la cabina 
lo aguanta hasta en caliente, pero cuando quites el disco lo que va a 
pasar es que la controladora va a detectar que falta un volumen del raid 
1, lo va a marcar como failed y se va a poner a reconstruir el raid (es 
la opción predeterminada en la mayoría de las controladoras) y no creo 
que sea eso lo que quieres salvo que tengas un reemplazo del disco que 
has quitado. Recuerda que un raid 1 sólo protege contra el fallo de un 
disco, si por el motivo que sea al estar reconstruyendo el raid te falla 
el otro disco la cosa se puede poner fea.

> Hay una opción "Replace physical disk", pero no sé si será eso, porque
> no lo veo explicado en ningún sitio. También hay otra que es "offline
> physical disk" o incluso "quiesce physical disk I/Os". También puede
> que valga "fail physical disk", para marcarlo como erróneo. Pero vaya
> usted a saber.

La mayoría de las controladoras RAID funcionan "solas", y salvo que 
quieras usar una configuración concreta ("spares", caché, etc... que en 
tu caso no creo que sea posible porque sólo admite raid 0,1) el 
procedimiento consiste en quitar disco/poner disco/verificar que todo 
está correcto. En el caso de que no detecte el disco automáticamente 
puedes forzar un escaneo pero no suele ser lo habitual. SI ves que la 
operación de reconstrucción no se inicia, entonces sí puedes bucear por 
las opciones del menú 21 ("replace physical disk"). La opción de "offline 
PD" no creo que sirva para lo que buscas sino que más bien parece indicar 
que puedes "forzar" la baja de un disco, nada más. Para el resto de 
opciones te recomiendo que las "googlees" para ver lo que hacen.

>> Por otra parte, es posible que no necesites pinchar el disco en una
>> controladora distinta y que puedas pasarle el test de SMART si la tuya
>> lo permite.
> 
> Le he pasado el test "short" y el "conveyance" a ambos discos. Ambos sin
> problemas. Puedo intentar pasarle el "long" a lo largo de la noche a ver
> sí dice algo más.

Pásale el test extendido, merece la pena y así te quedas más tranquilo.

> Otro problema que tengo es que físicamente no sé cuál es cuál.

Las controladoras RAID suelen tener una opción para identificar los 
discos cuando están en una cabina extraíble (a través de un comando que 
los "ilumina"), no sé si será tu caso. Si no tienes acceso externo a los 
discos, usa el nº de serie para identificarlos ("show PD" debería darte 
datos de los discos, tamaño, nº de serie...).

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.08.15.06...@gmail.com



Re: [OT] Raid por hardware

2015-01-07 Thread sio2
El Wed, 07 de Jan de 2015, a las 02:23:41PM +, Camaleón dijo:

> Tienes una página bastante maja donde, además de descargar los drivers y 
> utilidades para las controladoras más comunes, explican un poco el 
> funcionamiento de los comandos básicos para ver el estado de las matrices 
> y los discos, etc...
> 
> http://hwraid.le-vert.net/wiki/LSI

Sí, llegué a ella en mis pesquisas: por ella descubrí la existencia de
lsiutil.

> Te recomendaría que no hicieras movimientos bruscos (me refiero a eso del 
> "reset" que suena un pelín radical :-P), recuerda que simplemente con 
> reinicializar un disco eliminas todos los datos que contiene, es decir, 
> mucho cuidado al ejecutar cualquier comando en una controladora RAID. 
> Conviene que leas los manuales y FAQ que encuentres para saber 
> exactamente qué hace cada opción.

El problema es que la Guía de Usuario de lsiutil:

http://www.thomas-krenn.com/de/wikiDE/images/4/44/Lsi_userguide_2006_20130528.pdf

apenas explica nada. Y de la opción 21 (RAID options) no dice nada de
nada. Me gustaría, por ejemplo, quitar el disco desincronizado del RAID,
pero no tengo muy claro si se puede hacer y cómo. Hay una opción "Replace
physical disk", pero no sé si será eso, porque no lo veo explicado en
ningún sitio. También hay otra que es "offline physical disk" o incluso
"quiesce physical disk I/Os". También puede que valga "fail physical disk",
para marcarlo como erróneo. Pero vaya usted a saber.

> Por otra parte, es posible que no necesites pinchar el disco en una 
> controladora distinta y que puedas pasarle el test de SMART si la tuya lo 
> permite.

Le he pasado el test "short" y el "conveyance" a ambos discos. Ambos sin
problemas. Puedo intentar pasarle el "long" a lo largo de la noche a ver
sí dice algo más.

Otro problema que tengo es que físicamente no sé cuál es cuál.

-- 
   e non l'arbitrio de femina lieve,
che sempre inchina a quel che men far deve.
  --- Ludovico Ariosto ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150107202317.ga1...@cubo.casa



Re: [OT] Raid por hardware

2015-01-07 Thread Camaleón
El Wed, 07 Jan 2015 17:12:08 +0100, Manolo Díaz escribió:

> El miércoles, 7 ene 2015, a las 17:07 horas (UTC+1),
> Manolo Díaz escribió:
> 
>>El miércoles, 7 ene 2015, a las 15:23 horas (UTC+1),
>>Camaleón escribió:
>>
>>[...]
>>>si se trata del WD Red no sería lo más apropiado, conviene usar discos
>>>de la gama empresarial (suelen tener garantías de 5 años
>>[...]
>>
>>Precisamente ese fabricante ofrece también 5 años de garantía para esa
>>serie. ¿Has tenido alguna mala experiencia con ella?

No, al contrario... no hace mucho tuve que reemplazar unos cuantos discos 
seagate (gama empresarial) por otros y elegí los de WD (gama empresarial 
también). Aunque a día de hoy pocas opciones hay en discos mecánicos: 
Seagate (Maxtor, Samsung) o WD (Hitachi GST/IBM) porque Toshiba/Fujitsu 
fabrica principalmente discos de 2.5" :-/

> Me corrijo: depende del modelo. Algunos solo tienen 3 años de garantía.

Exactamente. Hay que tener mucho cuidado con eso porque a veces los 
fabricantes los mezclan dentro de varias categorías y no pocas tiendas de 
informática desconocen estas cosas por lo que en caso de duda siempre es 
recomendable ver el nº de modelo y buscarlo en la página de cada 
fabricante para asegurarse de que lo que se compra es lo que quiere.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.07.16.21...@gmail.com



Re: [OT] Raid por hardware

2015-01-07 Thread Manolo Díaz
El miércoles, 7 ene 2015, a las 17:07 horas (UTC+1),
Manolo Díaz escribió:

>El miércoles, 7 ene 2015, a las 15:23 horas (UTC+1),
>Camaleón escribió:
>
>[...]
>>si se trata del WD Red no sería lo más apropiado, conviene usar discos
>>de la gama empresarial (suelen tener garantías de 5 años
>[...]
>
>Precisamente ese fabricante ofrece también 5 años de garantía para esa
>serie. ¿Has tenido alguna mala experiencia con ella?

Me corrijo: depende del modelo. Algunos solo tienen 3 años de garantía.

Saludos.
-- 
Manolo Díaz


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150107171208.64a17...@gmail.com



Re: [OT] Raid por hardware

2015-01-07 Thread Manolo Díaz
El miércoles, 7 ene 2015, a las 15:23 horas (UTC+1),
Camaleón escribió:

[...]
>si se trata del WD Red no sería lo más apropiado, conviene usar discos
>de la gama empresarial (suelen tener garantías de 5 años
[...]

Precisamente ese fabricante ofrece también 5 años de garantía para esa
serie. ¿Has tenido alguna mala experiencia con ella?

Saludos.
-- 
Manolo Díaz


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150107170714.29f1b...@gmail.com



Re: [OT] Raid por hardware

2015-01-07 Thread Camaleón
El Tue, 06 Jan 2015 18:55:53 +0100, José Miguel (sio2) escribió:

> El Mon, 05 de Jan de 2015, a las 06:57:50PM +, Camaleón dijo:
> 
>>> Tengo un pequeño servidor debian con una controladora para hacer RAID,
>>> la cual he usado para montar dos discos espejo.
>> ¿Has descartado que el disco esté fallando realmente?
> 
> No, pero tampoco se muy bien cómo verlo. Tengo una utilidad llamada
> lsiutil, pero tiene ochocientas mil opciones que no sé muy bien para qué
> sirven y que no me atrevo a probar ahora mismo, porque esta corriendo el
> servidor. Cuando pueda accedar físicamente al servidor, tengo intención
> de pararlo, arrancar con un USB y probar a hacer unos "Reset". Si lo
> cosa no funciona, supongo que intentaré eliminar el disco que no se
> acaba por sincronizar y le haré pruebas por su cuenta.

Tienes una página bastante maja donde, además de descargar los drivers y 
utilidades para las controladoras más comunes, explican un poco el 
funcionamiento de los comandos básicos para ver el estado de las matrices 
y los discos, etc...

http://hwraid.le-vert.net/wiki/LSI

Te recomendaría que no hicieras movimientos bruscos (me refiero a eso del 
"reset" que suena un pelín radical :-P), recuerda que simplemente con 
reinicializar un disco eliminas todos los datos que contiene, es decir, 
mucho cuidado al ejecutar cualquier comando en una controladora RAID. 
Conviene que leas los manuales y FAQ que encuentres para saber 
exactamente qué hace cada opción.

Por otra parte, es posible que no necesites pinchar el disco en una 
controladora distinta y que puedas pasarle el test de SMART si la tuya lo 
permite.

> Los discos no tienen mucho tiempo: llevan funcionando desde mediados de
> junio y en absoluto han tenido mucha carga, Ni siquiera una carga media.
> Es más compré Western Digital con etiqueta roja.

Los falsos positivos están a la orden del día, es decir, aunque no tenga 
carga de trabajo un simple retardo I/O en el bus de uno de los discos y 
ya te lo marca como volumen fallido y se activa el modo de 
reconstrucción. Estas controladoras son muy puñeteras.

En cuando al modelo de disco duro, si se trata del WD Red no sería lo más 
apropiado, conviene usar discos de la gama empresarial (suelen tener 
garantías de 5 años y su precio un pelín más elevado).

>> Te lo comento porque es raro que una actualización de la BIOS de la
>> placa base afecte a una controladora RAID PCI-X/PCI-e (suele interferir
>> con las controladoras integradas o las "zero channel"), aunque no
>> estaría de más que buscaras alguna actualización del firmware de la
>> BIOS de la tarjeta.
> 
> Ya, es raro: la controladora va a aparte; pero es que yo no he hecho
> otro cambio.

Tampoco descartes contactar con el fabricante de la placa (HP) y el de la 
controladora (LSI) y comentarles la situación, quizá estén al tanto y 
saquen una actualización de la BIOS que lo corrija.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.07.14.23...@gmail.com



Re: [OT] Raid por hardware

2015-01-06 Thread sio2
El Mon, 05 de Jan de 2015, a las 06:57:50PM +, Camaleón dijo:

>> Tengo un pequeño servidor debian con una controladora para hacer RAID,
>> la cual he usado para montar dos discos espejo.
> ¿Has descartado que el disco esté fallando realmente? 

No, pero tampoco se muy bien cómo verlo. Tengo una utilidad llamada
lsiutil, pero tiene ochocientas mil opciones que no sé muy bien para qué
sirven y que no me atrevo a probar ahora mismo, porque esta corriendo el
servidor. Cuando pueda accedar físicamente al servidor, tengo intención
de pararlo, arrancar con un USB y probar a hacer unos "Reset". Si lo
cosa no funciona, supongo que intentaré eliminar el disco que no se
acaba por sincronizar y le haré pruebas por su cuenta.

Los discos no tienen mucho tiempo: llevan funcionando desde mediados de
junio y en absoluto han tenido mucha carga, Ni siquiera una carga media.
Es más compré Western Digital con etiqueta roja.

> Te lo comento porque es raro que una actualización de la BIOS de la placa 
> base afecte a una controladora RAID PCI-X/PCI-e (suele interferir con las 
> controladoras integradas o las "zero channel"), aunque no estaría de más 
> que buscaras alguna actualización del firmware de la BIOS de la tarjeta.

Ya, es raro: la controladora va a aparte; pero es que yo no he hecho otro
cambio.

Un saludo y gracias.

-- 
   Tu dulce habla, ¿en cúya oreja suena?
  --- Garcilaso de la Vega ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150106175553.ga16...@cubo.casa



Re: [OT] Raid por hardware

2015-01-05 Thread Camaleón
El Mon, 05 Jan 2015 18:47:42 +0100, José Miguel (sio2) escribió:

> Un saludo a la lista:
> 
> Tengo un pequeño servidor debian con una controladora para hacer RAID,
> la cual he usado para montar dos discos espejo.
> 
> La controladora es una LSI SAS1064E con la que uso en linux los drivers
> mpt*. Hast aquí la cosa va bien y ha ido bien durante un tiempo. Hace
> poco actualicé la BIOS de la placa base por razones que no vienen al
> caso y no sé si a causa de eso, el RAID ha empezado a darme un problema:
> uno de los discos está perpetuamente desincronizado. Puedo comprobar que
> la sincronización se está llevando a cabo (incluso saber el porcentaje
> que falta para terminar la sincronización con la herramienta lsiutil,
> pero cuando la sincronización acaba, vuelve otra vez a repetirse y así
> ad infinitum.

¿Has descartado que el disco esté fallando realmente? 

Te lo comento porque es raro que una actualización de la BIOS de la placa 
base afecte a una controladora RAID PCI-X/PCI-e (suele interferir con las 
controladoras integradas o las "zero channel"), aunque no estaría de más 
que buscaras alguna actualización del firmware de la BIOS de la tarjeta.

> No tengo muy claro qué hacer y tampoco he visto mucha información en
> internet al respecto. Pasado mañana ya tendré acceso físico al servidor
> y tengo que buscarle alguna solución. A las malas siempre puedo
> renunciar al RAID por hardware y hacer uno por software con mda, pero es
> una pena no aprovechar la controladora.
> 
> Tiene alguien experiencia con este tipo de RAIDs y se le ocurre qué
> puede estar ocurriendo y qué se puede hacer.

Son un dolor de tres pares de narices. Si funcionan bien, perfecto, pero 
como tengas una controladora problemática o uses una versión del módulo 
del kernel que no se lleve bien con la controladora estás vendido, vamos, 
que puedes acabar por tener los problemas que querías evitar que es la 
pérdida de datos ;-(

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.01.05.18.57...@gmail.com



[OT] Raid por hardware

2015-01-05 Thread sio2
Un saludo a la lista:

Tengo un pequeño servidor debian con una controladora para hacer RAID,
la cual he usado para montar dos discos espejo.

La controladora es una LSI SAS1064E con la que uso en linux los drivers
mpt*. Hast aquí la cosa va bien y ha ido bien durante un tiempo. Hace
poco actualicé la BIOS de la placa base por razones que no vienen al
caso y no sé si a causa de eso, el RAID ha empezado a darme un problema:
uno de los discos está perpetuamente desincronizado. Puedo comprobar que
la sincronización se está llevando a cabo (incluso saber el porcentaje
que falta para terminar la sincronización con la herramienta lsiutil,
pero cuando la sincronización acaba, vuelve otra vez a repetirse y así
ad infinitum.

No tengo muy claro qué hacer y tampoco he visto mucha información en
internet al respecto. Pasado mañana ya tendré acceso físico al servidor
y tengo que buscarle alguna solución. A las malas siempre puedo
renunciar al RAID por hardware y hacer uno por software con mda, pero es
una pena no aprovechar la controladora.

Tiene alguien experiencia con este tipo de RAIDs y se le ocurre qué
puede estar ocurriendo y qué se puede hacer.

Muchas gracias de antemano.

-- 
   Todo el mundo se suicidaría si después de suicidarse se
pudiera seguir viviendo.
  --- Enrique Jardiel Poncela ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150105174742.ga28...@cubo.casa