Reprise du message précédent :

tu pourrais faire un effort  

+1

je ne suis pas gros, juste un peu...
      /
   

edit 1 : beuuuu...
 
edit 2 : ....aaaarz'hhh
   

t'as bien un truc à raser quelquepart?  

une compil du kernel    pour que ça pousse

 
Alors que tout tient ensemble avec du scotch et des ficelles ?
 

Au moins le scotch et la ficelle, c'est des trucs éprouvés depuis des lustres, pas comme les nouvelles technologies de maintenant  

FYP

Preums
J'adore les portiques et tubes à rayons X qui sont juste pour le décor en gare du nord...

Illusion de la sécurité anyway, au moins c'est honnête.
Jusqu'à maintenant l'histoire contemporaine a prouvé que de toute façons c'est inutile

C'est comme le contrôle visuel des sacs à la défense mais en plus cher (et c'est toi qui paye).

Exactament, en outre j'ai croisé pas mal de fans de Johnny qui affluaient dès 7h du matin à Paris pour assister à l'hommage de l'idole des vieux (évadés fiscaux).

io  

preums

bonjour,

Le client qui dit que nos snapshots ne marchent pas (on appelle l'API de XenServer) et qui nous sort son `dmesg` avec plein de `I/O errors` sur son storage, et ça viendrai de nous parce qu'à part ces messages d'erreur sur ses storages, tout va bien

lol

/     \
l=0=l
\     /

bonjour,

salut Jules

Jonbour,

Ben ça veut pas toujours dire grand chose les I/O error, genre si il fait du multipath avec des LUNs de type failover, t'en as plein des messages comme ça et c'est parfaitement normal

 
Des read marqué bloqué à certains secteurs, je suis pas sûr que ça soit très bon signe, non ? Enfin je sais pas ce que t'en penses :
 

faut regarder les infos smart pour voir si ce sont des secteurs défectueux

C'est quoi le backend ?
Si ce sont simplement des disques en SATA tu devrais voir la couche ATA/SCSI qui fait des retry et/ou t'annonce que des block sont illisibles.
Si c'est une carte RAID, il faut utiliser la cli qui vient avec pour voir les logs du controleur.

Je crois que c'est une baie de storage en iSCSI. Mais j'en saurai plus quand j'aurai accès à l'hôte

Du coup c'est soit l'accès au backend qui a foiré, ce qui pourrait expliquer pourquoi tu vois des erreurs sur autant de devices, soit c'est un problème au niveau du backend lui même mais pour qu'autant de disques soient impactés c'est que c'est sérieux

Ca ressemble pas mal aux erreurs générées par les checks de multipath
Surtout que les sdab, sdac, etc indique que y a pas mal de block device, ce qui correspond bien aussi.
Après j'ai plus de stockage de ce type sous la main pour contrôler...
 
Regardes du côté de multipath -l (ou multipath -ll) pour voir un peu mieux si c'est juste des path foireux (ce qui peut être normal) ou si c'est la merde au-dessus.

Pas forcément, si la baie a plusieurs controleurs en actif/passif, c'est le comportement normal, multipath fait des checks des différents chemins et n'utilise que ceux qui sont bons, et en cas d'erreur bascule sur ceux de secours.
Comme il teste régulièrement tous les chemins, y a ces messages d'erreurs qui apparaissent, mais ça n'est pas forcément signe de mauvaise santé.
Y a que la commande multipath pour le dire si c'est bon ou pas bon.

Effectivement cela peut être le multipath mais de la façon dont il en parle j'ai compris que l'accès aux datas ne fonctionne pas et que le client ne lui a donné que cet extrait de log. Du coup "l'erreur normale" du multipath semble être hors de cause.

Disons qu'en plus de ça, des snapshots semblent échouer à cause du storage. Mais j'en saurai plus bientôt. Toujours est-il que ça vient pas de nous (et je vois pas comment ça pourrai être le cas)

 
Avec un schéma comme ça, c'est le stagiaire qui essaye de faire une lecture FS sur un device block et qui s'est gentiment foiré quand il a défini les disques virtuels, parce que bon, scrubber le secteur 0, puis le secteur de fin puis le fin data puis le début data sur tout les disques ? C'est un foutu script foiré.
 
Dit leurs de vérifier leurs config LVM.

Invocation MystérieuseX - Essai n°1

bonsoir,
 

 
xav

 io

bonjour,

Preums in Madrid

,ruojnob

Jur noob.