linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@turbolinux.com>
To: linux-lvm@sistina.com
Cc: Andreas Dilger <adilger@turbolinux.com>
Subject: Re: [linux-lvm] badblocks handling with LVM
Date: Fri, 27 Apr 2001 17:59:33 -0600 (MDT)	[thread overview]
Message-ID: <200104272359.RAA06618@lynx.turbolabs.com> (raw)
In-Reply-To: <01042519594802.31687@lyta> from "Russell Coker" at Apr 25, 2001 07:59:48 PM

Russel Coker writes:
> On Monday 23 April 2001 12:08, Andreas Dilger wrote:
> > As long as the bad blocks are not in the first ~250kB of the partition/disk
> > then LVM doesn't care about it.  However, reiserfs doesn't yet support bad
> > blocks in the filesystem (this is currently under development AFAIK), so
> > this will not help you.
> 
> The problem is that when you move LV's around and make snapshots the bad 
> blocks on the underlieing media will move.  Therefore I think that management 
> of bad blocks possibly should be done in the LVM.

As long as the LVM metadata and the snapshotted blocks themselves don't hit
more bad blocks, the snapshot itself will be fine.  ext2 just allocates all
of the bad blocks to a file, and presumably this file gets no I/O, so just
doing a snapshot of a filesystem with bad blocks is not an issue.

This leaves several other alternatives:
- New LV has bad blocks: no different than bad blocks in a partition, so
  a new ext2 filesystem can handle this via badblocks(8).
- Extended LV has bad blocks in added PEs: you can run badblocks(8) on the
  newly allocated part of the LV (specify a start block) before fs extend
  (can't use e2fsadm in this case).
- pvmove a filesystem to PEs with bad blocks: you are mostly screwed.  If
  you _really_ wanted, you could run badblocks on the PEs (added to a temp
  LV), keep a list of bad blocks, add them to the ext2 filesystem (with
  appropriate math for their new offset inside the LV, etc) before the PE
  is moved, but it is very ugly.  As someone else suggested, you could
  simply add the entire PE to "lvbad", and simply not use them.  If you
  have so many PEs with bad sectors that it uses up a large part of your
  device, it is time to get a new disk (or use RAID with 2 semi-bad disks
  and hope that they don't have 2 bad sectors in the same place).

Cheers, Andreas
-- 
Andreas Dilger                               TurboLabs filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

      parent reply	other threads:[~2001-04-27 23:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-22  5:19 [linux-lvm] badblocks handling with LVM laurent
2001-04-23 10:08 ` Andreas Dilger
2001-04-25 17:59   ` Russell Coker
2001-04-26 10:06     ` Heinz J. Mauelshagen
2001-04-26 13:26       ` Ragnar Kjørstad
2001-04-26 14:27         ` Goetz Bock
2001-04-26 14:36           ` Ragnar Kjørstad
2001-04-26 17:11         ` Heinz J. Mauelshagen
2001-04-27 23:59     ` Andreas Dilger [this message]

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=200104272359.RAA06618@lynx.turbolabs.com \
    --to=adilger@turbolinux.com \
    --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 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).