All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Hopper <hopper@omnifarious.org>
To: linux-lvm@sistina.com
Subject: [linux-lvm] Re: How to handle Bad Block relocation with LVM?
Date: Fri Feb 14 08:52:01 2003	[thread overview]
Message-ID: <1045065586.477.16.camel@dev-ehopper.tiecommerce.com> (raw)

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

I manually relocated a few bad blocks on a bad IBM drive I had when I
replaced the drive.  It took a lot of time and effort.  I had to run the
dd command many times very carefully to make it work.

One big problem for me was that read-ahead obscured which actual sectors
were in error.  I needed a 'raw' LVM device, but I don't think such a
thing exists for LVM1 on Linux 2.4.x.

What I did was used pvmove to move the PE containing the bad block to a
different spot on the hard drive, then allocated a new LV that was one
LE long, and forced it to allocate the PE containing the bad block. 
Then I used dd to carefully copy over the LE in sections, narrowing down
the location of the bad sectors until I had copied everything that could
possibly be read.

After that, I ran fsck on the filesystem that had originally contained
the bad block, and I was fine.  I checked carefully, and it didn't even
seem that I had lost any data.

Long, time consuming process though.

Actually, it may have been even ickier than I first thought.

It could be that pvmove wouldn't work, and I had to shorten the LV
containing the bad block (the BLV) to contain all PEs prior to the bad
one, allocate a new LV (the NLV) containing all the bad PE, lengthen the
BLV by 1 PE, using a brand new PE, then lengthen it to its original
length so it would contain all the PEs after that bad PE, the do the
procedure I outlined above.

Now that I think of it, I'm nearly positive that pvmove didn't work.  I
had dearly wished for some kind of option to pvmove that would force it
to try as hard as it could to get good reads of all the sectors in a PE,
then move the LE to a new PE, even if there were errors.

Have fun (if at all possible),
-- 
Eric Hopper <hopper@omnifarious.org>
Omnifarious Software

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

             reply	other threads:[~2003-02-14  8:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-14  8:52 Eric Hopper [this message]
2003-02-14 11:27 ` [linux-lvm] Re: How to handle Bad Block relocation with LVM? 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
2012-11-29 15:55       ` Stuart D Gathman
2012-11-30  0:10         ` Brian J. Murrell
     [not found] <20030218012102.12299.65097.Mailman@hermes.sistina.com>
2003-02-18  8:08 ` [linux-lvm] " Eric M. Hopper

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=1045065586.477.16.camel@dev-ehopper.tiecommerce.com \
    --to=hopper@omnifarious.org \
    --cc=linux-lvm@sistina.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.