From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Brian Murrell <brian@interlinx.bc.ca>
Subject: Re: [linux-lvm] How to handle Bad Block relocation with LVM?
Date: Wed, 28 Nov 2012 14:57:18 +0100 [thread overview]
Message-ID: <50B6183E.9020404@redhat.com> (raw)
In-Reply-To: <loom.20121128T142616-703@post.gmane.org>
Dne 28.11.2012 14:27, Brian Murrell napsal(a):
> Joe Thornber <joe <at> fib011235813.fsnet.co.uk> writes:
>>
>> Eric,
>>
>> We would like to automate the process that you have described in LVM2
>> at some point. So if you get an error on an LV and new PE will be
>> allocated, as much data as possible copied from the bad PE to the new
>> PE, and then remap the LV so that it's using the new PE (very much
>> like a small pvmove).
>>
>> The EVMS team are writing a bad block relocator target for device
>> mapper, but I don't feel it's neccessary to add yet another device
>> layer to the LVs. If I have a bad block I don't mind loosing a whole
>> PE (people may not agree with me on this ?)
>
> To resurrect a really, really, old thread, did anything ever get done in LVM2
> to either automatically or manually map out PEs with bad blocks in them?
>
> Does anyone have a recipe for doing this -- to save me the time of figuring it
> all out for myself?
Sorry, no automated tool.
You could possibly pvmove separated PEs manually with set of pvmove commands.
But I'd strongly recommend to get rid of such broken driver quickly then you
loose any more data - IMHO it's the most efficient solution cost & time.
Zdenek
next prev parent reply other threads:[~2012-11-28 13:57 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 [this message]
2012-11-29 12:26 ` Brian J. Murrell
2012-11-29 14:04 ` Lars Ellenberg
2012-11-29 22:53 ` Brian J. Murrell
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=50B6183E.9020404@redhat.com \
--to=zkabelac@redhat.com \
--cc=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).