3 pièce(s) jointe(s)
Prendre garde à l'espace disque du host si disques virtuels dynamiques
Bonjour,
(je mets ça dans "contribuez" car si ça se trouve, ça concerne tous les hyperviseurs -- je ne connais que VirtualBox.)
je me suis récemment demandé comment le grossissement d'un disque dynamique était vu et géré par le système hôte (Debian 7), et la réponse est "mal", malheureusement.
--Scénario--
1) Préparatifs :
prendre une clé usb (512 Mo dans mon cas) vierge, et y créer un disque virtuel dynamique de 16 Go, le monter, le partitionner (1 seule part.) et formater la partoche, en ext4.
df, qui montre d'abord la clé, puis la partoche :
Code:
1
2
3
| Sys. fich. 1K-blocks Util. Disponible Uti% Monté sur
/dev/sdc1 503528 23624 479904 5% /media/6488-A3E4
/dev/loop0 15990112 39984 15131216 1% /mnt/vdisksrc/Partition1 |
préparer un fichier zip de 48,6 Mo (aléatoire, c'est tombé comm' ça) quelque part (un .zip c'est sympa car avec mc car il suffit de faire F3 pour en voir le contenu)
copier avec mc ce fichier dans la partoche du disque virtuel, résultat :
/dev/sdc1 503528 72776 430752 15% /media/6488-A3E4.
72776 - 23624 = 49152 ko, c'est bien le .zip
Je le renomme vit' fait de test.zip en test.zip0.
2) Action qui tue :
Recopier autant de fois que possible ce test.zip vers la partoche virtuelle (définie à 16 Go, je le rappelle) en renommant à chaque fois après la copie, en .zip1, .zip2 ...
Ralentissements à zip9, zipb, gros ralentissement à zipc et erreur pendant le suivant
Pièce jointe 431698
--> j'interromps, et, question suivante (non reproduite ici), je conserve le bout du 14e incomplet.
Il y a donc maintenant 13 fichiers de 48,6 Mo (clic droit / Propriétés sur un fichier --> 48,6 Mo (48 621 939 bytes)) dans cette partoche de 16 Go, soit 48,6 x 13 = presque 632 Mo + un bout du 14e (1380 ko)
Code:
1
2
| /dev/sdc1 503528 503528 0 100% /media/6488-A3E4
/dev/loop0 15990112 658756 14512444 5% /mnt/vdisksrc/Partition1 |
L'examen des fichiers à coup de F3 montre que .zipc est cassé mais les 12 autres sont bien affichés.
48,6 Mo x 12 = 583 Mo, pas mal pour une clé de 512 Mo !
3) Vérifs complémentaires :
Démontage machins virtuels, extraction clé, réinsertion et remontage, la clé est rw, je vais voir avec mc pour supprimer le bout cassé mais surprise !, il a disparu, et j'ai l'explication du .zipc cassé : il est deux fois plus petit que les autres !
Pièce jointe 431694
L'examen des autres fichiers montre que zip9 est aussi cassé
Pièce jointe 431695
ainsi que zipa et zipb qui sont pleins de vide.
Il y a donc 9 fichiers valides (on en voyait 12 avant extraction, à la fin de l'étape précédente), soit 48,6 x 9 = 437,4 Mo. Un 10e pourrait-il rentrer, maintenant ?
/dev/loop0 15990112 467340 14703860 4% /mnt/vdisksrc/Partition1.
467 + 49 = 516, pas sûr du tout mais en jouant sur les approximations (1000 vs 1024), je me dis "peut-être", tentons donc !
4) Manip de fin
Je supprime les fichiers cassés :
/dev/loop0 15990112 467340 14703860 4% /mnt/vdisksrc/Partition1.
Un peu d'arithmétique :
467340 - 39984 (esp. occ. après formatage) = 427356 / 9 fichiers = 47484 ko x 1024 = 48 623 616, on retrouve la taille des .zip, 48,6 Mo, ok.
Test du 10e : 48,6 x 10 = 486 Mo, donc ça pourrait rentrer.
Relance de la copie avec F5 --> elle est instantanée, comme les premières fois, et df me dit
/dev/loop0 15990112 514824 14656376 4% /mnt/vdisksrc/Partition1.
514824 - 467340 = 47484 (ok) et son examen avec F3 ne montre rien d'anormal.
Démontage extraction remontage et vérif = fichier cassé et inutilisable.
--Conclusion--
On peut remplir une partition de disque virtuel dynamique au-delà de la capacité réelle du support de stockage du fichier sans avoir instantanément d'alerte, et ainsi croire que la copie est bonne, :aie:
Je sens que je vais convertir mes disques dynamiques en disques statiques...
