xbd IO domain 2: error 5 (Xen2, NetBSD 3.0)

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.

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

-----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:

dom0-1:store/xen#makefs -t ffs -b 256m -f 10000
vm/master.2.img tmpmnt
Calculated size of `vm/master.2.img': 429924352 bytes, 16581
inodes
Extent size set to 8192
vm/master.2.img: 410.0MB (839696 sectors) block size 8192,
fragment  
size 1024
         using 8 cylinder groups of 53.45MB, 6842 blks, 2240
inodes.
super-block backups (for fsck -b #) at:
      32, 109504, 218976, 328448, 437920, 547392, 656864,
766336,
Populating `vm/master.2.img'
makefs: Reading `tmpmnt/usr/mdec/netboot_ne2000_isa.rom',
8192 bytes  
to go: Input/output error

Many thanks for the quick help, Manuel. Now that I know what
has  
happened I'll recreate the image from another source.

Regards,

Johan


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD4DBQFFJYfwKJmr+nqSTbYRArfFAJUeVhf8jMEVdFuBi7p4CIEShwCSAKCk
c0GU
lMawM++LNpqZA2dFthIIlg==
=P7ug
-----END PGP SIGNATURE-----

-----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:

dom0-1:store/xen#makefs -t ffs -b 256m -f 10000
vm/master.2.img tmpmnt
Calculated size of `vm/master.2.img': 429924352 bytes, 16581
inodes
Extent size set to 8192
vm/master.2.img: 410.0MB (839696 sectors) block size 8192,
fragment  
size 1024
         using 8 cylinder groups of 53.45MB, 6842 blks, 2240
inodes.
super-block backups (for fsck -b #) at:
      32, 109504, 218976, 328448, 437920, 547392, 656864,
766336,
Populating `vm/master.2.img'
makefs: Reading `tmpmnt/usr/mdec/netboot_ne2000_isa.rom',
8192 bytes  
to go: Input/output error

Many thanks for the quick help, Manuel. Now that I know what
has  
happened I'll recreate the image from another source.

Regards,

Johan


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD4DBQFFJYfwKJmr+nqSTbYRArfFAJUeVhf8jMEVdFuBi7p4CIEShwCSAKCk
c0GU
lMawM++LNpqZA2dFthIIlg==
=P7ug
-----END PGP SIGNATURE-----