Hi Manuel, On Tue, Jun 02, 2015 at 04:07:43PM +0200, Manuel Bouyer wrote: > On Tue, Jun 02, 2015 at 01:04:16PM +0200, Reinoud Zandijk wrote: > > > http://git.qemu.org/?p=qemu.git;a=patch;h=3cad83075c7b847fe0eb6e61316fdf50984d4570 > > > > Do you have suggestions on how to debug this? Somehow i don't have a > > network connection yet :-/ With that i could just dump the devices and see > > what changes? Would that help? > > Maybe you could ktrace the qemu-dm process and see if it's requesting the > right blocks, and getting the right data ? i've tried that yes. It looks OK as in the blocks are 512 byte aligned and are multiples of 512 normally. I also managed to dump the dk0 on both hvm domu as on the dom0 and they are equal for the range i dumped them (roughly 125 Mb `hexdump -C'). What i did notice was that the dumping was slow in the hvm, but thats due to qemu :-/ and the odd code that keeps on reading the disklabel over and over and over again in qemu. I haven't dug into why this is yet though. I also managed to mount and copy some small amount of stuff on an SSD disc using the same mechanism only its a) not as big (120gb vs 512gb) and b) its nearly empty. Afterwards all fsck'd fine on dom0. Since the big disk had already been used extensively (219gb full) it wouldn't surprise me that some inodes are on the later part of the disc. The sbin inode number is 27777984 and the sbin/init is inode 27778073. I don't know how to translate those to sector numbers though. When i mount i can also get a panic in the HVM for it reads in something corrupt and i get a panic on uvm_vnode.c:355 (oldsize != ...) When i fsck the disc on the hvm i get "bad super block: values in super..." Any other ideas? I can hardly copy the entire disc, all 512 gb ;) I just don't have the space. Reinoud
Attachment:
pgp1dNfNnpAkp.pgp
Description: PGP signature