WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-fr

Re: [Xen-fr] pb FS après duplication de domU avec dd

Dominique Rousseau a écrit :
Le Mon, Aug 20, 2007 at 10:59:25AM +0200, Franck ELIE [Franck.Elie@xxxxxxxxxxxxxxx] a écrit:
  
Les "certains" ne seraient pas tous issus d'une même «souche» qui
pourrait avoir eu une corruption partielle du fs datant d'avant les
copies ?
      
Un fsck sur les partitions du domU template n'a rien montré d'anormal. 
Du coup, j'aurais tendance à considérer que le problème vient de 
l'utilisation de 'dd', qui, si on ne l'associe pas un à fsck sur le 
clone, peut avoir des conséquences franchement rudes vu que cela plante 
le serveur, et par suite les domU qu'il supporte.
    

Peut-être essayer de forcer dd d'écrire en mode synchrone ?
(conv=dsync , je crois)

Si tu compares les sommes MD5 (avec md5sum) correspondant à la "source"
et la "destination", ça donne le même résultat ?

  

Bien joué le coup du MD5 ! J'étais loin de penser qu'en effectuant une copie bit à bit avec 'dd', j'obtiendrais une somme MD5 différente entre le LUN et son clone sous forme image.

Du coup, j'ai regardé de plus près mon script de sauvegarde (simplifié) :
# xm shutdown -w $DOMU
# dd if=$LUN_DOMU of=$BACKUP_FILE
# cat $LUN_DOMU | md5sum -b
# md5sum -b $BACKUP_FILE

Après quelques tests, j'ai constaté que la somme MD5 a tendance à être différente du fichier image obtenu avec dd lorsque j'effectue une copie du LUN peut de temps après avoir arrêté le domU (moins de 2min30) :

15:32:22 : Domain DOM-U terminated
15:33:46 : fin du dd + md5sum sur fichier image = 67541a7ce330dd29ffb3662daad68419
15:34:57 : fin du dd + md5sum sur fichier image = cfa979f894992f1c06c25981fc7d8cd3
15:36:22 : fin du dd + md5sum sur fichier image = cfa979f894992f1c06c25981fc7d8cd3
...

J'ai renouvelé l'expérience avec un domU local (pas dans le SAN), et ai constaté le même problème.

En conséquent, j'aurais tendance à considérer qu'il y a un problème relatif à un temps de vidage d'un buffer lié au domU, lequel peut durer quelques secondes (voire minutes) après l'arrêt du domU. Disposant de 8GO de RAM sur le serveur Xen en question, peut-être travaille-il sur une copie en mémoire du domU de 2GO.

Avez-vous observé un tel comportement ?
Savez-vous comment provoquer un "flush" de la mémoire relative au domU sur disque une fois le domaine arrêté ?

  Franck

_______________________________________________
Xen-fr mailing list
Xen-fr@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-fr