gratifiant > comp.sys.* > comp.sys.sun

sylvain (18/11/2010, 15h29)
Bonjour,

Il m'arrive assez souvent au boulot d'avoir des impacts assez ennuyeux
sur des SunFire V240 qui ont un disque qui casse.

En gros, les symptômes directs sont :

- des erreurs visibles par iostat :
HostNameX {root} # iostat -En

c1t0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: FUJITSU Product: MAU3073NCSUN72G Revision: 1503 Serial No:
0517F008CV
Size: 73.40GB <73400057856 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

c1t1d0 Soft Errors: 0 Hard Errors: 10 Transport Errors: 180
Vendor: FUJITSU Product: MAU3073NCSUN72G Revision: 1503 Serial No:
0516F0086A
Size: 73.40GB <73400057856 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 10 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

- des horreurs dans les logs du noyau :
Nov 11 13:14:21 HostNameX scsi: [ID 107833 kern.warning] WARNING: /
pci@1c,600000/scsi@2 (glm0):
Nov 11 13:14:21 HostNameX Disconnected tagged cmd(s) (4)
timeout for Target 1.0
Nov 11 13:14:21 HostNameX genunix: [ID 408822 kern.info] NOTICE: glm0:
fault detected in device; service still available
Nov 11 13:14:21 HostNameX genunix: [ID 611667 kern.info] NOTICE: glm0:
Disconnected tagged cmd(s) (4) timeout for Target 1.0
Nov 11 13:14:21 HostNameX glm: [ID 401478 kern.warning] WARNING:
ID[SUNWpd.glm.cmd_timeout.6018]
Nov 11 13:14:21 HostNameX scsi: [ID 107833 kern.warning] WARNING: /
pci@1c,600000/scsi@2/sd@1,0 (sd1):
Nov 11 13:14:21 HostNameX SCSI transport failed: reason
'reset': retrying command

HostNameX {root} # grep c1t1d0 /var/adm/messages*
/var/adm/messages.0:Nov 11 13:23:11 HostNameX md_stripe: [ID 641072
kern.warning] WARNING: md: d30: read error on /dev/dsk/c1t1d0s0
/var/adm/messages.0:Nov 11 13:23:11 HostNameX md_stripe: [ID 641072
kern.warning] WARNING: md: d30: write error on /dev/dsk/c1t1d0s0
....
/var/adm/messages.0:Nov 11 13:55:54 HostNameX md_mirror: [ID 104909
kern.warning] WARNING: md: d30: /dev/dsk/c1t1d0s0 needs maintenance
/var/adm/messages.0:Nov 11 14:37:52 HostNameX md_mirror: [ID 104909
kern.warning] WARNING: md: d31: /dev/dsk/c1t1d0s1 needs maintenance
/var/adm/messages.0:Nov 11 14:37:52 HostNameX md_mirror: [ID 976326
kern.warning] WARNING: md d11: open error on /dev/dsk/c1t1d0s1
HostNameX {root} #

- l'autre disque n'est pas incriminé dans les logs noyau :

HostNameX {root} # grep c1t0d0 /var/adm/messages*
HostNameX {root} #

les deux disques sont normalement en RAID 1 comme ça :

HostNameX {root} # metastat -c
d11 m 11GB d21 d31
d21 s 11GB c1t0d0s1
d31 s 11GB c1t1d0s1
d10 m 124GB d20 d30
d20 s 124GB c1t0d0s0
d30 s 124GB c1t1d0s0
HostNameX {root} #

On fait juste un système de fichiers principal, et une zone de swap.

Et bien malgré le raid, quand un disque casse, ça arrive super souvent
(disons 1 fois sur 3) que le disque ait tellement mis le bazar sur le
bus scsi qu'il faille rebooter la machine pour faire prendre en compte
le disque de remplacement.

Pire encore il arrive aussi que la carte ou le bus scsi soient
tellement en vrac que ça provoque des erreurs de lecture/écriture ou
des grosses lenteurs qui bloquent le fonctionnement d'applications qui
tournent dessus.

Est ce que quelqu'un a déjà rencontré ce genre de problème sur du
solaris 10 ?
pour info :

HostNameX {root} # uname -a
SunOS HostNameX 5.10 Generic_139555-08 sun4u sparc SUNW,Netra-240
HostNameX {root} #

Il y a un patch à appliquer, des disques à éviter, d'autres choses à
regarder pour investiguer ?

Merci pour vos lumières.

sylvain
JKB (18/11/2010, 16h14)
Le Thu, 18 Nov 2010 05:29:04 -0800 (PST),
sylvain <sylvain.meilard> écrivait :
> Bonjour,


Bonjour,

[..]
> timeout for Target 1.0
> Nov 11 13:14:21 HostNameX genunix: [ID 408822 kern.info] NOTICE: glm0:
> fault detected in device; service still available


C'est bien, Solaris est toujours aussi verbeux. On ne sait pas d'où
vient le problème. Bon, il y a bien un 'no device' qui traîne.

[..]
> d30 s 124GB c1t1d0s0
> HostNameX {root} #
> On fait juste un système de fichiers principal, et une zone de swap.


Certes. Mais il y a un truc que je ne comprends pas. Comment à
partir de deux disques de 73 Go, on se retrouve avec une partition
de 124 Go. Il n'y aurait pas un savant mélange entre raid0 et raid1
? Ou un vieux reste d'un assemblage linéaire ?

> Et bien malgré le raid, quand un disque casse, ça arrive super souvent
> (disons 1 fois sur 3) que le disque ait tellement mis le bazar sur le
> bus scsi qu'il faille rebooter la machine pour faire prendre en compte
> le disque de remplacement.


Est-ce que ça arrive souvent ? Parce que j'ai eu ça avec une U60, et
c'était le contrôleur de _l'autre_ disque qui mettait le bazar. Mais
dans le cas qui nous intéresse, je ne pense pas que ce soit ça.

> Pire encore il arrive aussi que la carte ou le bus scsi soient
> tellement en vrac que ça provoque des erreurs de lecture/écriture ou
> des grosses lenteurs qui bloquent le fonctionnement d'applications qui
> tournent dessus.
> Est ce que quelqu'un a déjà rencontré ce genre de problème sur du
> solaris 10 ?


Pas moi.

Mais la sortie du metastat m'interpelle... Peut-on avoir aussi celle
d'un df -h ? J'ai m'impression qu'il y a quelque chose de bizarre
dans la création du raid soft.

lebegue:[~] > metastat d6
d6: Miroir
Sous-miroir 0: d16
Etat : Ok
Sous-miroir 1: d26
Etat : Ok
Accès : 1
Option de lecture : roundrobin (par défaut)
Option d'écriture : parallel (par défaut)
Taille : 83467470 blocs (39 GB)

d16: Sous-miroir de d6
Etat : Ok
Taille : 83467470 blocs (39 GB)
....

On a bien 39 Go des deux côtés, ce qui est normal pour un disque de
73 Go (je n'ai prix qu'une partition). La question est donc de
savoir d'où viennent ces 124 Go.

JKB
sylvain (19/11/2010, 12h48)
Bonjour,

>         Certes. Mais il y a un truc que je ne comprends pas. Comment à
>         partir de deux disques de 73 Go, on se retrouve avec une partition
>         de 124 Go. Il n'y aurait pas un savant mélange entre raid0 et raid1
>         ? Ou un vieux reste d'un assemblage linéaire ?


oulà oui, j'ai dû faire ce copié/collé après avoir attaqué une dalle
de moquette

je le refais à jeun :

je copie/colle ici aussi, à tout hasard :

hostnameX {root} # metastat -c
d11 m 7.5GB d21 d31
d21 s 7.5GB c1t0d0s1
d31 s 7.5GB c1t1d0s1
d10 m 60GB d20 d30
d20 s 60GB c1t0d0s0
d30 s 60GB c1t1d0s0
hostnameX {root} # df -h
Filesystem size used avail capacity Mounted on
/dev/md/dsk/d10 60G 26G 33G 45% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 7.0G 1.5M 7.0G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1
60G 26G 33G 45% /platform/sun4u-
us3/lib/libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
60G 26G 33G 45% /platform/sun4u-
us3/lib/sparcv9/libc_psr.so.1
fd 0K 0K 0K 0% /dev/fd
swap 7.1G 131M 7.0G 2% /tmp
swap 7.0G 48K 7.0G 1% /var/run
hostnameX {root} # metastat d10
d10: Mirror
Submirror 0: d20
State: Okay
Submirror 1: d30
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 127566336 blocks (60 GB)

d20: Submirror of d10
State: Okay
Size: 127566336 blocks (60 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c1t0d0s0 0 No Okay Yes

d30: Submirror of d10
State: Okay
Size: 127566336 blocks (60 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c1t1d0s0 0 No Okay Yes

Device Relocation Information:
Device Reloc Device ID
c1t0d0 Yes
id1,sd@SFUJITSU_MAU3073NCSUN72G_000517F008CV____AN C0P54008CV
c1t1d0 Yes
id1,sd@SFUJITSU_MAU3073NCSUN72G_000516F0086A____AN C0P540086A
hostnameX {root} #

Enfin bon, je sens que ça ne va pas être facile d'investiguer là
dessus.
L'application qui s'est magnifiquement cassé la figure, c'est une base
de donnée Timesten, un produit Oracle ...

JKB : merci bien pour votre réponse, j'ai eu un gros doute quand je
l'ai lue, par rapport au problème de taille :)

Cordialement,

sylvain
JKB (19/11/2010, 14h21)
Le Fri, 19 Nov 2010 02:48:08 -0800 (PST),
sylvain <sylvain.meilard> écrivait :
[..]
> d10 m 60GB d20 d30
> d20 s 60GB c1t0d0s0
> d30 s 60GB c1t1d0s0


C'est effectivement bien mieux ;-)

[..]
> hostnameX {root} #
> Enfin bon, je sens que ça ne va pas être facile d'investiguer là
> dessus.


Effectivement.

Peut-on avoir les symtpomes exacts lors les différents plantages ?
Quels sont les fréquences de décès des disques ? État de la chaîne
SCSI ?

Je ne connais pas ces disques, j'ai des Fujitsu, mais en MAW qui
viennent directement de chez Fujitsu (j'ai arrêté les disques
d'origine Sun, parce que la fiabilité est plus que moyenne depuis
quelque temps). Avez-ovus essayé avec d'autres disques ?

> L'application qui s'est magnifiquement cassé la figure, c'est une base
> de donnée Timesten, un produit Oracle ...


C'est une application qui s'est plantée ou tout le système ?

> JKB : merci bien pour votre réponse, j'ai eu un gros doute quand je
> l'ai lue, par rapport au problème de taille :)


J'avoue avec lu votre texte deux fois pour être sûr de ne pas écrire
une grosse conceté...

JKB
Dominique ROUSSEAU (19/11/2010, 14h35)
Le jeu, 18 nov 2010 at 13:29 GMT, sylvain <sylvain.meilard> a écrit :
> Et bien malgré le raid, quand un disque casse, ça arrive super souvent
> (disons 1 fois sur 3) que le disque ait tellement mis le bazar sur le
> bus scsi qu'il faille rebooter la machine pour faire prendre en compte
> le disque de remplacement.


Mhmmm. Ca t'arrive "super souvent" de perdre un disque ?
Toujours sur la même machine ?

Parceque si c'est ça, moi, je me mettrai à soupçonner le controleur, les autres
disques, etc.
sylvain (19/11/2010, 21h06)
re-Bonjour,

>         Peut-on avoir les symtpomes exacts lors les différents plantages ?
>         Quels sont les fréquences de décès des disques ? État de la chaîne
>         SCSI ?


Les synptomes exacts sont de deux natures :
1) au niveau OS, le second disque (qui est ok) se met à avoir ses
compteurs qui s'incrémentent dans le "iostat -En", on a des erreurs de
lecture de secteurs sur le disque encore valide, un disque en bon état
mis en remplacement du disque défectueux n'est pas reconnu tant que la
machine n'est pas rebootée (cfgadm -c configure ne marche pas, entre
autre)
2) au niveau applicatif, le "truc" qui sert de base de données se
casse la figure, et le reste suit, mais bon, le "truc" qui sert de
base de données doit s'attendre à faire son accès disque en 2 secondes
et peut être ça en met 5, je ne sais pas, je n'ai pas trouvé de logs
applicatives du "truc"

>         Je ne connais pas ces disques, j'ai des Fujitsu, mais en MAW qui
>         viennent directement de chez Fujitsu (j'ai arrêté lesdisques
>         d'origine Sun, parce que la fiabilité est plus que moyenne depuis
>         quelque temps). Avez-ovus essayé avec d'autres disques ?


oulà non, on se fait livrer les machines neuves, par un fournisseur X,
on a un mainteneur Y qui remplace ce qui est cassé par une pièce
équivalente, du moment que c'est un disque de taille identique avec
les mêmes caractéristiques (vitesse de rotation essentiellement, je
pense), on ne cherche pas à savoir.

> > L'application qui s'est magnifiquement cassé la figure, c'est une base
> > de donnée Timesten, un produit Oracle ...

>         C'est une application qui s'est plantée ou tout le système ?

ha non, pas le système, juste l'application, quoi que niveau système,
il a fallut rebooter pour qu'un nouveau disque soit accepté (cf plus
haut)

>Mhmmm. Ca t'arrive "super souvent" de perdre un disque ?
>Toujours sur la m me machine ?
>Parceque si c'est a, moi, je me mettrai soup onner le controleur, les autres
>disques, etc.


Ben ce sont des machines qui en gros tournent H24 depuis 2 ans, on en
a pas mal (disons entre 200 et 300), et là on fait changer au moins un
disque par mois environ, depuis un peu plus de 6 mois, à la louche.

sylvain
Discussions similaires