Skip to contentSkip to conversation

pvmove with Bad bocks

linux-lvm Stonki 5 participants 11 messages Oct 20, 2001 – Oct 22, 2001

lore
Share & tools
lore

Stonki

author
#0 lore raw

Hello list, Hello Heinz,

on Tuesday you explained me the function of moving data from one hard disc to another.
Well, regarding to Murphies Law... pvmove complains about read errors and stops before moving all data.

Error reading input physical volume /dev/hdf1 still 393216 bytes to read).

What now ? Thanks anyway...

cu
stonki

#1 lore raw
Quoted 9 lines · Stonki

Hello list, Hello Heinz,

on Tuesday you explained me the function of moving data from one hard disc to another.
Well, regarding to Murphies Law... pvmove complains about read errors and stops before moving all data.

Error reading input physical volume /dev/hdf1 still 393216 bytes to read).

If you browse the archive for the last month you will find a couple of threads on the subject.

I've posted a cruel patch to make pvmove ignore read-errors, and update the meta-data even if the sector is bad. (The extent will be moved to the other disk, but contain garbage). With this patch the behaviour is undefined when moving more than one PE. Other than that, I think it should work.

Others posted suggestions and possible some patches too - allthough there was no complete perfect solution, I think you should be able to make it work from the different tips submitted in the thread.

Signature · 2 lines
Ragnar Kjørstad
Big Storage
#2 lore raw
Quoted 20 lines · Ragnar Kjxrstad
Quoted 9 lines · Stonki

Hello list, Hello Heinz,

on Tuesday you explained me the function of moving data from one hard disc to another.
Well, regarding to Murphies Law... pvmove complains about read errors and stops before moving all data.

Error reading input physical volume /dev/hdf1 still 393216 bytes to read).

If you browse the archive for the last month you will find a couple of threads on the subject.

I've posted a cruel patch to make pvmove ignore read-errors, and update the meta-data even if the sector is bad. (The extent will be moved to the other disk, but contain garbage). With this patch the behaviour is undefined when moving more than one PE. Other than that, I think it should work.

Quoted 3 lines

Others posted suggestions and possible some patches too - allthough there was no complete perfect solution, I think you should be able to make it work from the different tips submitted in the thread.

The first thing I would try is shrinking the filesystem and pv by one extent. If this works the pv move should now work ok.

- Joe

author
#3 lore raw

Hello Joe,

Sunday, October 21, 2001, 4:56:22 PM, you wrote:

JT> The first thing I would try is shrinking the filesystem and pv by one JT> extent. If this works the pv move should now work ok. ahh ? *g* How Do I shrink the reisefs filessystem and the pv by one extent ???

cu
Stonki

#4 lore raw

[linux-lvm] shrink lvm without harddisk ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,
i've got a harddisk that crashed... (again :( ) - and so i can't even xs the lvm anymore... i want to ask if there's a way to mount the lvm with one harddisk missing (of corse there will be dataloss - but i think loosing only 40gigs is better than loosing the whole lvm...) ?
fejf

- --
Backups are usefull. Most often when you don't have one ;) -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE70vsI7Xtp66ctWuIRAqthAJ4u7zWGpxPK5MR9M3WmUcp84w/jpQCcDp3U /fkzo/SPFdjWcnbJH+sernQ=
=16Wh
-----END PGP SIGNATURE-----

#5 lore raw

Re: [linux-lvm] shrink lvm without harddisk ?

Quoted 5 lines · FEJF

hi,
i've got a harddisk that crashed... (again :( ) - and so i can't even xs the lvm anymore... i want to ask if there's a way to mount the lvm with one harddisk missing (of corse there will be dataloss - but i think loosing only 40gigs is better than loosing the whole lvm...) ?

Well, this only makes sense if there is LV(s) which don't have *any* PEs alocated on the crashed disk. If not so you'ld end up in an filesystem mess (assuming that the LV(s) contain(s) filesystems) anyway, because fs metadata and data will be missing.

If you still want to go for it you need a replacement drive, vgcfgrestore the LVM metadata to it and restart LVM.
In order to avoid such problems you might consider to go for soft/hard RAID as PV storage.

Quoted 10 lines

fejf

Signature · 7 lines
Backups are usefull. Most often when you don't have one ;)

_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Signature · 15 lines
Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
author
#6 lore raw
In reply to Joe Thornber

Hello Joe,

Sunday, October 21, 2001, 4:56:22 PM, schriebst Du:

JT> The first thing I would try is shrinking the filesystem and pv by one JT> extent. If this works the pv move should now work ok.

ok, I reduced the reiserfs from 150 GB down to 140 GB. I also reduced the LVM to 145 GB. This worked fine without any errors...

Than I started pvmove again (linux:~ # pvmove -v /dev/hdf1 /dev/hdc1), where hdf1 is the faulty drive and hdc1 is the new one...

linux:~ # pvmove -v /dev/hdf1 /dev/hdc1
pvmove -- checking name of source physical volume "/dev/hdf1"
pvmove -- locking logical volume manager
pvmove -- reading data of source physical volume from "/dev/hdf1"
pvmove -- checking volume group existence
pvmove -- reading data of volume group "Stonki2" from lvmtab
pvmove -- checking volume group consistency of "Stonki2"
pvmove -- searching for source physical volume "/dev/hdf1" in volume group "Stonki2" pvmove -- building list of possible destination physical volumes
pvmove -- checking destination physical volume names in command line
pvmove -- checking volume group activity
pvmove -- moving physical extents in active volume group "Stonki2"
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/hdf1"
pvmove -- checking for enough free physical extents in "Stonki2"
pvmove -- /dev/hdf1 [PE 3319 [LV_Stonki2 [LE 27209]] -> /dev/hdc1 [PE 3319] [1/9911] pvmove -- ERROR reading input physical volume "/dev/hdf1" (still 393216 bytes to read)

pvmove -- ERROR "pv_move_pe(): read input PV" pv_move_pe

pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents

so, same error.. Also also looked trough the archive of this mailinglist. I didn't find any patch.. Only for version > 1.00. Mine is:

linux:~ # pvmove -V
Logical Volume Manager 0.9.1_beta7
Heinz Mauelshagen, Sistina Software 10/04/2001 (IOP 10)

cu
Stonki

#7 lore raw

I guess you must still have that last extent allocated. Can you mail me (not the list) a full pvdisplay -v output please.

- Joe

#8 lore raw
In reply to Stonki
Quoted 8 lines · Stonki

pvmove -- starting to move extents away from physical volume "/dev/hdf1" pvmove -- checking for enough free physical extents in "Stonki2"
pvmove -- /dev/hdf1 [PE 3319 [LV_Stonki2 [LE 27209]] -> /dev/hdc1 [PE 3319] [1/9911] pvmove -- ERROR reading input physical volume "/dev/hdf1" (still 393216 bytes to read)

pvmove -- ERROR "pv_move_pe(): read input PV" pv_move_pe

pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents

Do you have kernel messages with ide or scsi errors in /var/log/messages?

I think there are two potential causes of pvmove erroring out - one is a bug related to the last allocaten extent, and one is actual disk error. I fail to see why reducing the size will solve any problems if the cause is a bad disk - I think you need the patch I mentioned earlier, or a simular fix.

Signature · 2 lines
Ragnar Kjørstad
Big Storage
author
#9 lore raw

Hello Ragnar,

Sunday, October 21, 2001, 10:44:16 PM, schriebst Du:

RK> I think there are two potential causes of pvmove erroring out - one is a RK> bug related to the last allocaten extent, and one is actual disk error. well its a disk error for sure. Also wrote it in my initial posting here..

RK> I fail to see why reducing the size will solve any problems if the cause RK> is a bad disk - I think you need the patch I mentioned earlier, or a RK> simular fix.
Well, I need this patch for sure :-) But excuse me, but I didn't find the patch in the mailinglist. The only thing I found was a notice of Heinz to patch the latest RC for 1.0 in line 520. But I use a much older version...

can you give me a helping hand ?

with regards,

Stefan Onken

#10 lore raw
Quoted 9 lines · Stonki

RK> I fail to see why reducing the size will solve any problems if the cause RK> is a bad disk - I think you need the patch I mentioned earlier, or a RK> simular fix.
Well, I need this patch for sure :-) But excuse me, but I didn't find the patch in the mailinglist. The only thing I found was a notice of Heinz to patch the latest RC for 1.0 in line 520. But I use a much older version...

can you give me a helping hand ?

Look for a thread started 6th of september - subject "pv_move_pe() error again".

My patch is available at:
http://vestinternett.no/~ragnark/download/LVM_ignore_read_errors.patch2

But like I explained in my original post, and others commented in the said thread, the patch is not 100%. There was a suggested change later in the same thread that was smaller than mine (it didn't change the locking), and is much cleaner if it works. I'd try that first, if I were you.

Signature · 2 lines
Ragnar Kjørstad
Big Storage