[linux-lvm] badblocks handling with LVM

[linux-lvm] badblocks handling with LVM

[laurent]

I have blocks marked bad on a ext2 filesystem.
The device has bad blocks.
I'm wondering how bad blocks are handled with lvm.
I would like to create a phycal volume on this device and use reiserfs
on it.
Could you give me some informations ?

-- 
Laurent

Re: [linux-lvm] badblocks handling with LVM

[Andreas Dilger]

Laurent writes:
> I have blocks marked bad on a ext2 filesystem.  The device has bad blocks.
> I'm wondering how bad blocks are handled with lvm.  I would like to create
> a phycal volume on this device and use reiserfs on it.
> Could you give me some informations ?

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.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] badblocks handling with LVM

[Russell Coker]

On Monday 23 April 2001 12:08, Andreas Dilger wrote:
> Laurent writes:
> > I have blocks marked bad on a ext2 filesystem.  The device has bad
> > blocks. I'm wondering how bad blocks are handled with lvm.  I would like
> > to create a phycal volume on this device and use reiserfs on it.
> > Could you give me some informations ?
>
> 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.

Or should we just assume that LVM runs over RAID arrays of ATA/SCSI disks 
that have sector-sparing so that bad blocks are not an issue?

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: [linux-lvm] badblocks handling with LVM

[Heinz J. Mauelshagen]

On Wed, Apr 25, 2001 at 07:59:48PM +0200, Russell Coker wrote:
> On Monday 23 April 2001 12:08, Andreas Dilger wrote:
> > Laurent writes:
> > > I have blocks marked bad on a ext2 filesystem.  The device has bad
> > > blocks. I'm wondering how bad blocks are handled with lvm.  I would like
> > > to create a phycal volume on this device and use reiserfs on it.
> > > Could you give me some informations ?
> >
> > 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.
> 
> Or should we just assume that LVM runs over RAID arrays of ATA/SCSI disks 
> that have sector-sparing so that bad blocks are not an issue?

That's what I recommend because disks typically "hide" bad sectors to a certain
degree using bad block relocation et al.
If the given disk capacity for this is not enough because too many bad blocks
occured already then you are in serious trouble and need to repleace
your disk (subsystem) anyway IMO.

> 
> -- 
> http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
> http://www.coker.com.au/projects.html Projects I am working on
> http://www.coker.com.au/~russell/     My home page
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] badblocks handling with LVM

[Ragnar Kjørstad]

On Thu, Apr 26, 2001 at 10:06:03AM +0000, Heinz J. Mauelshagen wrote:
> > 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.
> > 
> > Or should we just assume that LVM runs over RAID arrays of ATA/SCSI disks 
> > that have sector-sparing so that bad blocks are not an issue?
> 
> That's what I recommend because disks typically "hide" bad sectors to a certain
> degree using bad block relocation et al.
> If the given disk capacity for this is not enough because too many bad blocks
> occured already then you are in serious trouble and need to repleace
> your disk (subsystem) anyway IMO.

And if anyone insist on using LVM to mark the blocks anyway, it can be
done with out special code. Just create a volume named "broken", and put
the PVs in question in this.


-- 
Ragnar Kj�rstad
Big Storage

Re: [linux-lvm] badblocks handling with LVM

[Goetz Bock]

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


On Thu, Apr 26 '01 at 15:26, Ragnar Kjørstad wrote:
> And if anyone insist on using LVM to mark the blocks anyway, it can be
> done with out special code. Just create a volume named "broken", and put
> the PVs in question in this.
That would be a waste of space, my PVs are all 10+GB in size, I'd like
bad block handling on PE level not on PV level.
But I can live with out badblock handling in LVM.

Cu,
    Goetz.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] badblocks handling with LVM

[Ragnar Kjørstad]

On Thu, Apr 26, 2001 at 04:27:42PM +0200, Goetz Bock wrote:
> On Thu, Apr 26 '01 at 15:26, Ragnar Kj�rstad wrote:
> > And if anyone insist on using LVM to mark the blocks anyway, it can be
> > done with out special code. Just create a volume named "broken", and put
> > the PVs in question in this.
> That would be a waste of space, my PVs are all 10+GB in size, I'd like
> bad block handling on PE level not on PV level.
> But I can live with out badblock handling in LVM.

Sorry, I meant "put the PEs in question in this".
(it doesn't actually do anything, just mark that space as used, so you
won't accidently put something else there)

-- 
Ragnar Kj�rstad
Big Storage

Re: [linux-lvm] badblocks handling with LVM

[Heinz J. Mauelshagen]

On Thu, Apr 26, 2001 at 03:26:52PM +0200, Ragnar Kj�rstad wrote:
> On Thu, Apr 26, 2001 at 10:06:03AM +0000, Heinz J. Mauelshagen wrote:
> > > 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.
> > > 
> > > Or should we just assume that LVM runs over RAID arrays of ATA/SCSI disks 
> > > that have sector-sparing so that bad blocks are not an issue?
> > 
> > That's what I recommend because disks typically "hide" bad sectors to a certain
> > degree using bad block relocation et al.
> > If the given disk capacity for this is not enough because too many bad blocks
> > occured already then you are in serious trouble and need to repleace
> > your disk (subsystem) anyway IMO.
> 
> And if anyone insist on using LVM to mark the blocks anyway, it can be
> done with out special code. Just create a volume named "broken", and put
> the PVs in question in this.

It is not that I really *insist*.

I just say that it doesn't make a whole lot of sense today, because most of
the disk (subsystems) don't expose bad blacks any longer.

Once those start too, they are ready to go to the trashcan IMO anyway.

> 
> 
> -- 
> Ragnar Kj�rstad
> Big Storage
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] badblocks handling with LVM

[Andreas Dilger]

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/