I seem to run into a weird problem. LVM refused to work properly,
after a "vgscan" command "vgchange -a y" would still complain
that things weren't consistent and I got a messages about an
I/O error on 08:11.
Interestingly my sdb does not have any partitions since it's one
big PV, and fdisk agrees with me on that. However the kernel
seems to thing I do have a partition there and as a result LVM
seems to get somewhat confused.
This happens with both 2.4.9-ac17 and 2.4.10-ac3. If anyone has
any ideas on how to go about fixing this don't hestitate to ask
me for more details.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
> I seem to run into a weird problem. LVM refused to work properly,
> after a "vgscan" command "vgchange -a y" would still complain
> that things weren't consistent and I got a messages about an
> I/O error on 08:11.
Does it complain about wrong block sizes ?
> Interestingly my sdb does not have any partitions since it's one
> big PV, and fdisk agrees with me on that. However the kernel
> seems to thing I do have a partition there and as a result LVM
> seems to get somewhat confused.
The partition code will look for tables. That bit is fine
The exact error would be good too
Previously Alan Cox wrote:
> Does it complain about wrong block sizes ?
No
> The partition code will look for tables. That bit is fine
If that bit is fine then how can it differ in opinion from fdisk?
> The exact error would be good too
I/O error: dev 08:11, sector 0
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
On Oct 02, 2001 22:00 +0200, Wichert Akkerman wrote:
> Previously Alan Cox wrote:
> > Does it complain about wrong block sizes ?
>
> No
>
> > The partition code will look for tables. That bit is fine
>
> If that bit is fine then how can it differ in opinion from fdisk?
What does the first 512 bytes of the disk show (od -Ax -tx1 /dev/)?
Maybe there is still "0xaa55" on the disk at 0x1fe and the kernel
thinks it is a DOS partition?
> > The exact error would be good too
>
> I/O error: dev 08:11, sector 0
Hmm, this is sda11, so you would need both a primary and extended
partition table to get that. What does /proc/partitions show?
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
> If that bit is fine then how can it differ in opinion from fdisk?
>
> > The exact error would be good too
>
> I/O error: dev 08:11, sector 0
Nothing before or after it ?
Followup to: <[email protected]>
By author: Andreas Dilger <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > If that bit is fine then how can it differ in opinion from fdisk?
>
> What does the first 512 bytes of the disk show (od -Ax -tx1 /dev/)?
> Maybe there is still "0xaa55" on the disk at 0x1fe and the kernel
> thinks it is a DOS partition?
>
Note that that is true for *ANY* partition scheme which is bootable,
since this is a requirement of the boot firmware interface, rather of
any particular partitioning scheme...
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Previously Alan Cox wrote:
> Nothing before or after it ?
Nothing at all.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
On Tue, Oct 02, 2001 at 03:08:20PM -0600, Andreas Dilger wrote:
> > I/O error: dev 08:11, sector 0
>
> Hmm, this is sda11
No. These messages give hex values.
Previously Andreas Dilger wrote:
> What does the first 512 bytes of the disk show (od -Ax -tx1 /dev/)?
See below.
> Maybe there is still "0xaa55" on the disk at 0x1fe and the kernel
> thinks it is a DOS partition?
Hmm, there does seem to be a 0xaa55 there..
> Hmm, this is sda11, so you would need both a primary and extended
> partition table to get that. What does /proc/partitions show?
It's not sda11, that output is in hex. At any rate /proc/partitions
contents is also below.
Wichert.
cloud:/home/wichert# od -Ax -tx1 /dev/discs/disc0/disc | head -32
000000 fa ea 80 00 c0 07 4c 49 4c 4f 01 00 15 07 b5 00
000010 24 00 00 00 15 ce b5 3b e2 20 b0 00 00 e3 20 b0
000020 00 00 e1 20 b0 00 00 01 00 00 00 00 00 00 00 e5
000030 20 b0 00 00 16 0b b0 00 00 17 0b b0 00 00 18 0b
000040 b0 00 00 19 0b b0 00 00 1a 0b b0 00 00 1b 0b b0
000050 00 00 1c 0b b0 00 00 1d 0b b0 00 00 1e 0b b0 00
000060 00 1f 0b b0 00 00 20 0b b0 00 00 00 00 00 00 00
000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000080 8c c8 8e d0 bc 80 00 52 53 06 56 bc 00 08 fb 8e
000090 d8 b0 0d e8 6d 00 b0 0a e8 68 00 b0 4c e8 63 00
0000a0 be 34 00 cd 12 c1 e0 06 2d 60 02 50 07 31 db ad
0000b0 91 ac a8 60 75 0f 4e ad 89 c2 09 c8 74 1b ac b4
0000c0 02 cd 13 eb 0d 92 ad f6 c2 20 75 02 30 e4 97 e8
0000d0 3a 00 72 0e 80 c7 02 eb d6 b0 49 e8 25 00 06 6a
0000e0 00 cb b0 20 e8 1c 00 e8 06 00 31 c0 cd 13 eb b0
0000f0 c1 c0 04 e8 03 00 c1 c0 04 24 0f 04 30 3c 3a 72
000100 02 04 07 50 30 ff b4 0e cd 10 58 c3 56 51 53 88
000110 d3 80 e2 8f f6 c3 40 75 33 bb aa 55 b8 00 41 cd
000120 13 72 29 81 fb 55 aa 75 23 f6 c1 01 74 1e 5b 59
000130 1e 31 f6 56 56 57 51 06 53 6a 01 6a 10 89 e6 16
000140 1f b8 00 42 cd 13 8d 64 10 1f eb 44 5b 59 53 52
000150 57 51 06 b4 08 cd 13 07 72 38 51 c0 e9 06 86 e9
000160 89 cf 59 88 f0 fe c0 80 e1 3f f6 e1 96 58 5a 39
000170 f2 73 23 f7 f6 39 f8 77 1d c0 e4 06 86 e0 92 f6
000180 f1 fe c4 00 e2 89 d1 5a 5b 86 f0 b8 01 02 cd 13
000190 eb 09 59 5f eb 02 b4 40 5a 5b f9 5e c3 00 00 00
0001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
0001c0 01 00 83 fe 3f 03 3f 00 00 00 c5 fa 00 00 00 00
0001d0 01 04 83 fe 3f 04 04 fb 00 00 c1 3e 00 00 00 00
0001e0 01 05 8e fe ff ff c5 39 01 00 42 96 25 02 00 00
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
major minor #blocks name
58 0 524288 lvma
8 0 18051360 scsi/host0/bus0/target0/lun0/disc
8 1 32098 scsi/host0/bus0/target0/lun0/part1
8 2 8032 scsi/host0/bus0/target0/lun0/part2
8 3 18008865 scsi/host0/bus0/target0/lun0/part3
8 16 17942584 scsi/host0/bus0/target1/lun0/disc
8 17 4194304 scsi/host0/bus0/target1/lun0/part1
8 32 8969493 scsi/host0/bus0/target2/lun0/disc
8 48 8969493 scsi/host0/bus0/target3/lun0/disc
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Here are the first 512 bytes for the disk which the kernel gets
wrong (/dev/sdb):
000000 48 4d 01 00 00 00 00 00 00 04 00 00 00 10 00 00
000010 00 10 00 00 00 20 00 00 00 80 00 00 00 a0 00 00
000020 00 48 01 00 00 f0 01 00 00 00 41 00 47 59 75 35
000030 50 30 6a 63 58 57 45 42 74 38 64 44 74 70 51 6d
000040 31 6a 50 38 57 41 31 4e 5a 46 39 65 00 00 00 00
000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000a0 00 00 00 00 00 00 00 00 00 00 00 00 76 67 5f 75
0000b0 73 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00
0000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
000120 00 00 00 00 00 00 00 00 00 00 00 00 63 6c 6f 75
000130 64 31 30 30 31 37 38 30 32 30 38 00 00 00 00 00
000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001a0 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
0001b0 01 00 00 00 01 00 00 00 02 00 00 00 70 90 23 02
0001c0 01 00 00 00 00 20 00 00 1b 11 00 00 80 00 00 00
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Other data point: the 2.2.19 kernel as found on the lnx bootable business
card also gets it wrong and detect a sdb1..
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
>> Maybe there is still "0xaa55" on the disk at 0x1fe and the kernel
>> thinks it is a DOS partition?
> Note that that is true for *ANY* partition scheme which is bootable,
> since this is a requirement of the boot firmware interface, rather of
> any particular partitioning scheme...
You mean on i386 hardware? With the most common BIOS versions?
[email protected] wrote:
>
> >> Maybe there is still "0xaa55" on the disk at 0x1fe and the kernel
> >> thinks it is a DOS partition?
>
> > Note that that is true for *ANY* partition scheme which is bootable,
> > since this is a requirement of the boot firmware interface, rather of
> > any particular partitioning scheme...
>
> You mean on i386 hardware? With the most common BIOS versions?
I think it applies to almost all boot firmware -- the Atari 68000 hard
disk format used it, all the x86 firmware I am familiar with uses it, and
I think Apple uses it in all it's Mac incarnations. That's pretty wide
coverage (I know nothing about Sun or other workstation formats).
If the 0xAA55 marker is not present, the standard interpretation is that
the disk is not partitioned, and the disk may still boot, but you may
just be lucky it works if it really is partitioned.
Or have I missed something (I'm not all that familiar with non-x86 hardware
so I could be missing something big -- and I'd like to know that)?
--Charles
On Oct 03, 2001 14:42 +0200, Wichert Akkerman wrote:
> Here are the first 512 bytes for the disk which the kernel gets
> wrong (/dev/sdb):
>
> 000000 48 4d 01 00 00 00 00 00 00 04 00 00 00 10 00 00
> 000010 00 10 00 00 00 20 00 00 00 80 00 00 00 a0 00 00
> 000020 00 48 01 00 00 f0 01 00 00 00 41 00 47 59 75 35
> 000030 50 30 6a 63 58 57 45 42 74 38 64 44 74 70 51 6d
> 000040 31 6a 50 38 57 41 31 4e 5a 46 39 65 00 00 00 00
> 000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0000a0 00 00 00 00 00 00 00 00 00 00 00 00 76 67 5f 75
> 0000b0 73 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 000120 00 00 00 00 00 00 00 00 00 00 00 00 63 6c 6f 75
> 000130 64 31 30 30 31 37 38 30 32 30 38 00 00 00 00 00
> 000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0001a0 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
> 0001b0 01 00 00 00 01 00 00 00 02 00 00 00 70 90 23 02
> 0001c0 01 00 00 00 00 20 00 00 1b 11 00 00 80 00 00 00
> 0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
OK, so it turns out that LVM is NOT zeroing any of the metadata outside
of the actual allocated fields in the on-disk structs. Since the on-disk
structs DO NOT include padding at the end, this means we leave garbage
like the DOS partition table signature on the disk. Yuck.
Likely places to fix this are:
- pv_setup_for_create(): zap the first few MB of the PV (and the end while
you are at it, to remove old MD RAID signatures). This is slow, and will
duplicate some of the I/O when writing the VGDA/PE tables, etc.
- pv_disk_t(): increase the size with padding at the end to LVM_PV_DISK_SIZE
You will need to do the same for all of the other on-disk structures.
You also need zero bytes from pe_on_disk.base + pe_total*sizeof(pe_disk_t)
to pe_on_disk.base + pe_on_disk.size. This is also a problem because the
LVM_PV_*_SIZE were changed, so the amount of padding is not constant.
- pv_write(): ugly since it adds constant overhead. This will be "handled"
if pv_disk_t() is increased in size.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert