On 12-11-29 09:04 AM, Lars Ellenberg wrote:
> 
> If you do
> pvs --unit s --segment -o vg_name,lv_name,seg_start,seg_size,seg_start_pe,pe_start,seg_pe_ranges

Right.  Let's assume I can find the PE.

> Having the PE number, you can easily do
> pvmove /dev/broken:PE /dev/somewhere-else

Right but that...


> Or with alloc anywhere even elsewhere on the same broken disk.

As well as that just puts a new PE in where the one with the damaged
block is but returns the PE with the damaged block back to the free list
to be allocated again at some point in the future, yes?

> # If you don't have an other PV available,
> # but there are free "healthy" extents on the same PV:
> # pvmove --alloc anywhere /dev/broken:PE /dev/broken
> Which would likely not be the smartest idea ;-)

Right because of the above, yes?  Or is there something else nasty about it?

> You should then create one LV named e.g. "BAD_BLOCKS",
> which you would create/extend to cover that bad PE,
> so that won't be re-allocated again later:
> lvextend VG/BAD_BLOCKS -l +1 /dev/broken:PE

Ahhh.  But in this case I want lvcreate -l 1 /dev/broken:PE since I
don't yet have my "badblocks" LV.  I would of course use lvextend next
time.  :-)

> Better yet, pvchange -an /dev/broken,
> so it won't be used for new LVs anymore,
> and pvmove /dev/broken completely to somewhere else.

Yeah, of course ideally.  But as I mentioned, I'm not terribly worried
about loss in this case.

> I'm unsure how pvmove will handle IO errors, though.

I thought I read somewhere about pvmove being persistent through IO
errors but I can't seem to find it any more.  I guess we'll see.  :-)

It seems the pvmove just powered through.  Sweet.

I confirmed, using Stuart Gathman's (very nifty!) lbatofile.py program
that the file that was producing a read error from before the pvmove
read with no error after it and now I have my bad PE in a "badblocks" LV.

Super sweet!

Cheers,
b.