On Fri, Oct 06, 2006 at 12:32:10AM +0200, Johan Ihren wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 5 Oct 2006, at 23:19, Manuel Bouyer wrote:
> 
> >On Thu, Oct 05, 2006 at 11:09:42PM +0200, Johan Ihren wrote:
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>Hi Manuel,
> >>
> >>>>for one thing: I now see a sprinkling of
> >>>>
> >>>>	"xbd IO domain 2: error 5"
> >>>>
> >>>>in the logs and on the console. Never saw that before. It is always
> >>>>"domain 2" (which is started at boot) and always "error 5" (which I
> >>>>assume is "IO error" a la errno.h). I haven't noticed any real
> >>>>problems, though, everything *seems* to still work fine.
> >>>>
> >>>>But I sure would like to know what the problem is (especially if  
> >>>>this
> >>>>signals a REAL problem somewhere) and why it arrived in combination
> >>>>with the disk replacement. Any ideas?
> >>>
> >>>Is it a physical partition or a vnd ?
> >>
> >>vnd
> >>
> >>>If it's a physical partition make sure you didn't make it too short.
> >>>If it's a vnd, make sure you can read the whole file, and that it
> >>>didn't
> >>>get truncated.
> >>
> >>There were no errors during dump/restore from old disk to new disk.
> >>The file has the correct size and I'm able to read it all from the
> >>Dom0 without any errors.
> >
> >Hum, can you dd from /dev/rvnd0d to /dev/null the whole device ?
> >If the error comes from xbdback itself, there should be another error
> >message before this one.
> 
> Stupid me, I checked that I could read the *file* not the *device*:
> 
> dom0-1:store/xen#dd if=vm/master.img bs=8192 of=/dev/null
> 49152+0 records in
> 49152+0 records out
> 402653184 bytes transferred in 9.437 secs (42667498 bytes/sec)
> 
> The device does indeed show an error:
> 
> dom0-1:store/xen#vnconfig -c vnd0 vm/master.img
> dom0-1:store/xen#dd if=/dev/rvnd0d bs=8192 of=/dev/null
> dd: /dev/rvnd0d: Input/output error
> 6014+0 records in
> 6014+0 records out
> 49266688 bytes transferred in 1.501 secs (32822576 bytes/sec)
> 
> Hum. You were spont on, the filesystem is indeed truncated. So I  
> tried to recover by mounting the image and constructing a new, clean  
> one with makefs and now the evidence is plain to see:

It may be that the file was restored sparse - vnd(4) doesn't like
sparse files.

Cheers,
-- 
Paul Ripke
Unix/OpenVMS/TSM/DBA
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams