linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] How to handle Bad Block relocation with LVM?
Date: Thu, 29 Nov 2012 17:53:06 -0500	[thread overview]
Message-ID: <k98p0h$feg$1@ger.gmane.org> (raw)
In-Reply-To: <20121129140401.GE674@soda.linbit>

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

  reply	other threads:[~2012-11-29 22:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-14  8:52 [linux-lvm] Re: How to handle Bad Block relocation with LVM? Eric Hopper
2003-02-14 11:27 ` Joe Thornber
2012-11-28 13:27   ` [linux-lvm] " Brian Murrell
2012-11-28 13:57     ` Zdenek Kabelac
2012-11-29 12:26       ` Brian J. Murrell
2012-11-29 14:04         ` Lars Ellenberg
2012-11-29 22:53           ` Brian J. Murrell [this message]
2012-11-29 15:55       ` Stuart D Gathman
2012-11-30  0:10         ` Brian J. Murrell
  -- strict thread matches above, loose matches on Subject: below --
2023-03-15 16:00 Roland
2003-02-10 19:18 Rocky Lee
2003-02-11  8:24 ` Heinz J . Mauelshagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='k98p0h$feg$1@ger.gmane.org' \
    --to=brian@interlinx.bc.ca \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).