Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: HVM disc corruption (was Re: Xen won't start its device backend?)



On Tue, Jun 02, 2015 at 06:50:12PM +0200, Reinoud Zandijk wrote:
> 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.

Can you try to dump near the end of the disk, instead of near the
start ? dd skip=xxx should do it.
If it's a variable overflow somewhere that causes the wrong block to
be read this should catch it.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index