[linux-lvm] RE: Linux LVM pvmove -i trouble
Christian Hack
christianh at edmi.com.au
Wed Aug 4 09:30:34 UTC 2004
>
> I emailed Heinz directly since I couldn't subscribe to the
> list. First hit
> in Google for "LVM mailing list" returns
> http://linux.msede.com/lvm_mlist/
> which looks all fine and dandy, has up to date archives and
> instructions to
> subscribe which are obviously wrong. Perhaps the owner could point
> subscribers to the correct page below.
>
> He replied directly also, so I'm moving this to the mailing list for
> posterity.
>
> > > I dug your email out of the archives since the linux-lvm
> > list seems totally
> > > screwed up right now. I can't subscribe to the mailing list due to
> > > majordomo at msede.com not working properly and pretending to be
> > > majordomo at marxmeier.com.
> >
> > You hit a very old URL ther.
> > Use http://www.redhat.com/mailman/listinfo/linux-lvm please.
> >
> > > Anyway I have a dying drive with one PE that is bad on it.
> > I am trying to
> > > remove this last PE so I can remove the PV from the VG. I
> > used pvmove to get
> > > all but this bad PE off it with no troubles. "pvmove -i"
> > keeps bailing out
> > > with this error:
> > >
> > > [root at mythtv tools]# ./pvmove -i /dev/hdd
> > > pvmove -- moving physical extents in active volume group
> > "myth_volume_group"
> > > pvmove -- WARNING: if you lose power during the move you may need
> > > to restore your LVM metadata from backup!
> > > pvmove -- do you want to continue? [y/n] y
> > >
> > /dev/myth_volume_group/group::/dev/myth_volume_group/myth_logi
> > cal_volume:
> > > 1640 174981504, 0343 195035520
> > > pvmove -- ERROR "Input/output error" copying extent from
> "/dev/hdd"
> > >
> > > pvmove -- ERROR "Input/output error" moving physical extents
> > >
> > > I have tried all combinations of pvmove, -i ,
> > --ignore_read_errors etc but
> > > it seems to simply ignore this option. I upgraded to 1.0.8
> > with the same
> > > result. I see in the 1.0.8 notes it mentions:
> > >
> > > "If you run 'pvmove' and run into device errors, you must
> > first run 'vgscan'
> > > before attempting 'pvmove -i'"
> >
> > '-i' ignores read errors and tries to read as much data off
> the source
> > device it can.
> > *But* it can't ignore a write error to the destination device
> > of course.
> > Maybe that's your problem here ?
> >
> > >
> > > I did this with no success. I'm not even sure how vgscan
> > would achieve this
> > > anyway.
> >
> > It scans the changed metadata in and creates /etc/lvmtab*
> in order to
> > have the cached copy in sync with the ondosk copies for
> > proper tool runs.
> >
> > >
> > > FYI I'm getting these sorts of errors in the logs
> > >
> > > Aug 3 17:26:22 mythtv kernel: hdd: dma_intr: error=0x40 {
> > > UncorrectableError }, LBAsect=175022778, high=10, low=7250618,
> > > sector=175022721
> > > Aug 3 17:26:22 mythtv kernel: end_request: I/O error, dev
> > 16:40 (hdd),
> > > sector 175022721
> > > Aug 3 17:26:25 mythtv kernel: hdd: dma_intr: status=0x51 {
> > DriveReady
> > > SeekComplete Error }
> > > Aug 3 17:26:25 mythtv kernel: hdd: dma_intr: error=0x40 {
> > > UncorrectableError }, LBAsect=175022778, high=10,
> > low=7250618, sector=1750
> >
> > Hrm, no write io error on the destination device.
> > Try running pvmove woth option v to see waht happens.
>
> pvmove -i -vv /dev/hdd gives me this:
>
> [root at mythtv mnt]# pvmove -i -vv /dev/hdd
> pvmove -- checking name of source physical volume "/dev/hdd"
> pvmove -- locking logical volume manager
> pvmove -- reading data of source physical volume from "/dev/hdd"
> pvmove -- checking volume group existence
> pvmove -- reading data of volume group "myth_volume_group" from lvmtab
> pvmove -- checking volume group consistency of "myth_volume_group"
> pvmove -- searching for source physical volume "/dev/hdd" in
> volume group
> "myth_volume_group"
> pvmove -- building list of possible destination physical volumes
> pvmove -- checking volume group activity
> pvmove -- moving physical extents in active volume group
> "myth_volume_group"
> pvmove -- WARNING: if you lose power during the move you may need
> to restore your LVM metadata from backup!
> pvmove -- do you want to continue? [y/n] y
> pvmove -- starting to move extents away from physical volume
> "/dev/hdd"
> pvmove -- checking for enough free physical extents in
> "myth_volume_group"
> lv: /dev/myth_volume_group/myth_logical_volume[1] old_dev:
> 22:64 new_dev:
> 03:67 old_pe_sector: 174981504 new_pe_sector: 222953856
> pvmove -- opening output physical volume "/dev/hdb3"
> pvmove -- llseeking input physical volume "/dev/hdd"
> pvmove -- llseeking output physical volume "/dev/hdb3"
> pvmove -- /dev/hdd [PE 1334 [myth_logical_volume [LE 3121]]
> -> /dev/hdb3 [PE
> 1700] [1/1]
> pvmove -- copying extent from
> /dev/hdd::/dev/myth_volume_group/myth_logical_volume(0x1640):1
> 74981504 to
> /dev/hdb3(0x0343):222953856 on disk
> /dev/myth_volume_group/group::/dev/myth_volume_group/myth_logi
> cal_volume:
> 1640 174981504, 0343 222953856
> pvmove -- ERROR "Input/output error" copying extent from "/dev/hdd"
>
> pvmove -- ERROR "Input/output error" moving physical extents
>
> > > How can I remove this PE. I don't care about the data
> > that's on it. I just
> > > want to get the failing drive out of the VG.
> >
> > In case pvmove fails, only with surgery on the metadata -or- using
> > the LVM2 tools which are capable to handle partital VGs and
> > remove invalid PVs.
> > The later is the preferred way for obvious reasons.
>
> Anyone else have suggestions before I go and get the LVM2
> tools since pvmove
> -i should be working for me?
>
Fixed my problem. It seems that my system was still using the old lvm
runtime library that it was initially installed with (RH8 = LVM 1.0.3). Once
I made sure the old libraries were replaced with with 1.0.8 libraries
matching the binaries, pvmove -i successfully ignored the bad sectors (and
told me so too) and I was able to remove the PV from the VG.
CH
More information about the linux-lvm
mailing list