* [linux-lvm] vgscan goes into an infinite loop (migration issues)
@ 2004-01-06 15:59 Navindra Umanee
2004-01-06 17:00 ` Alasdair G Kergon
0 siblings, 1 reply; 4+ messages in thread
From: Navindra Umanee @ 2004-01-06 15:59 UTC (permalink / raw)
To: linux-lvm
Hi,
I have an LVM1 system working under 2.4. I've installed 2.6.0 with
devmapper and the LVM2 tools. Now I'm trying to get 2.6.0 to mount my
LVM1 system or at least to convert LVM1 to LVM2.
I have a single IDE harddrive with one VG named /dev/bytepool
containing four LVM partitions. I have a few LVs under
/dev/bytepool/.
vgconvert runs for a long long time, uses more than 3G of memory
(including swap) and then fails with an out of memory error. I can
increase swap if it will help, but I don't think it will.
vgscan does the same thing with global/format set to LVM1. So I put
vgscan in verbose and debug mode:
locking/file_locking.c:158 Locking /var/lock/lvm/V_bytepool RB
toollib.c:305 Finding volume group "bytepool"
device/dev-io.c:325 Opened /dev/hda6
format1/disk-rep.c:353 Found /dev/hda6 in VG bytepool
device/dev-io.c:325 Opened /dev/hda7
format1/disk-rep.c:353 Found /dev/hda7 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda7
device/dev-io.c:325 Opened /dev/hda8
format1/disk-rep.c:353 Found /dev/hda8 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda8
device/dev-io.c:325 Opened /dev/hda9
format1/disk-rep.c:353 Found /dev/hda9 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda9
format1/disk-rep.c:353 Found /dev/hda6 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda6
format1/disk-rep.c:353 Found /dev/hda7 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda7
format1/disk-rep.c:353 Found /dev/hda8 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda8
format1/disk-rep.c:353 Found /dev/hda9 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda9
format1/disk-rep.c:353 Found /dev/hda6 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda6
format1/disk-rep.c:353 Found /dev/hda7 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda7
format1/disk-rep.c:353 Found /dev/hda8 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda8
format1/disk-rep.c:353 Found /dev/hda9 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda9
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda6
format1/disk-rep.c:353 Found /dev/hda7 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda7
format1/disk-rep.c:353 Found /dev/hda8 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda8
format1/disk-rep.c:353 Found /dev/hda9 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda9
format1/disk-rep.c:353 Found /dev/hda6 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda6
format1/disk-rep.c:353 Found /dev/hda7 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda7
format1/disk-rep.c:353 Found /dev/hda8 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda8
format1/disk-rep.c:353 Found /dev/hda9 in VG bytepool
format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda9
[...]
Basically it's an infinite loop. Any idea what is going on? I would
greatly appreciate any suggestions.
Btw, it was quite an unpleasant shock to find that Linux 2.6.0 no
longer supported my LVM filesystems -- the kernel documentation
completely fails to mention anything at all about LVM changes. Can
someone take care of this oversight?
I *am* really glad my partitions and data have not been toasted so
far... :-)
Thanks,
Navin.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] vgscan goes into an infinite loop (migration issues)
2004-01-06 15:59 [linux-lvm] vgscan goes into an infinite loop (migration issues) Navindra Umanee
@ 2004-01-06 17:00 ` Alasdair G Kergon
2004-01-06 17:15 ` Navindra Umanee
0 siblings, 1 reply; 4+ messages in thread
From: Alasdair G Kergon @ 2004-01-06 17:00 UTC (permalink / raw)
To: linux-lvm
On Tue, Jan 06, 2004 at 04:57:19PM -0500, Navindra Umanee wrote:
> format1/disk-rep.c:392 Ignoring duplicate PV on /dev/hda7
Whatever goes wrong, it shouldn't loop!
And there's a clue in that error message: the PV's UUID is meant
to appear between 'PV' and 'on' - but it's empty.
Please send me a copy of your metadata so I can try to reproduce
the problem.
Alasdair
--
agk@uk.sistina.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] vgscan goes into an infinite loop (migration issues)
2004-01-06 17:00 ` Alasdair G Kergon
@ 2004-01-06 17:15 ` Navindra Umanee
2004-01-06 17:30 ` Alasdair G Kergon
0 siblings, 1 reply; 4+ messages in thread
From: Navindra Umanee @ 2004-01-06 17:15 UTC (permalink / raw)
To: linux-lvm
Alasdair G Kergon <agk@uk.sistina.com> wrote:
> And there's a clue in that error message: the PV's UUID is meant
> to appear between 'PV' and 'on' - but it's empty.
Hmmm. Does this help:
[navindra@vinata navindra]# lvm1-pvdisplay /dev/hda6
--- Physical volume ---
PV Name /dev/ide/host0/bus0/target0/lun0/part6
VG Name bytepool
PV Size 10 GB [20964762 secs] / NOT usable 32.19 MB [LVM: 129 KB]
PV# 1
PV Status available
Allocatable yes (but full)
Cur LV 5
PE Size (KByte) 32768
Total PE 318
Free PE 0
Allocated PE 318
PV UUID none
As you see, it claims there is no UUID.
> Please send me a copy of your metadata so I can try to reproduce
> the problem.
Thanks a lot for your followup! I've sent the information you requested.
Cheers,
Navin.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] vgscan goes into an infinite loop (migration issues)
2004-01-06 17:15 ` Navindra Umanee
@ 2004-01-06 17:30 ` Alasdair G Kergon
0 siblings, 0 replies; 4+ messages in thread
From: Alasdair G Kergon @ 2004-01-06 17:30 UTC (permalink / raw)
To: linux-lvm
On Tue, Jan 06, 2004 at 06:13:11PM -0500, Navindra Umanee wrote:
> PV UUID none
LVM2 uses the UUID to distinguish between PVs - so it sees all the
devices as duplicates of each other.
I'll try to change the code so it generates a UUID if it's missing.
Alasdair
--
agk@uk.sistina.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-01-06 17:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-06 15:59 [linux-lvm] vgscan goes into an infinite loop (migration issues) Navindra Umanee
2004-01-06 17:00 ` Alasdair G Kergon
2004-01-06 17:15 ` Navindra Umanee
2004-01-06 17:30 ` Alasdair G Kergon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.