[linux-lvm] pvmove on broken disk

[linux-lvm] pvmove on broken disk

[Fredrik Tolf]

Dear List,

I have an volume group with five PVs (4x120 GB IDE and 1x200GB S-ATA).
Unfortunately, one of the PVs (a 120 GB IDE disk) have started to
display broken sectors every here and there, so I'd very much like to
replace it before soon.

The problem is that since some sectors are broken, I'm assuming that
pvmove won't work. Would it somehow be possible to make pvmove replace
the broken sectors with zeroed sectors instead of failing? I realize
that it sucks, of course, but I somehow think a zeroed sector is better
than a broken sector. ;)

I've got a related question as well, but it's not really LVM-related.
The thing is that there's something strange with either the IDE chipset
(a Promise card) or the corresponding driver that this disk is connected
to, which causes a kernel panic every time a read from a bad sector is
attempted. I figure I can "fix" that by connecting the drives to a
different computer while pvmoving, but I wouldn't prefer to do that, as
it causes downtime. Does someone on the list know of this problem and
how to work around it? I figure that I can attempt to fix the driver
bug, but I wouldn't prefer to experiment with that system...

Thanks for your time!

Fredrik Tolf

Re: [linux-lvm] pvmove on broken disk

[Michael Loftis]

--On August 26, 2005 3:26:26 PM +0200 Fredrik Tolf <fredrik@dolda2000.com> 
wrote:

> Dear List,
>
<...>
> I've got a related question as well, but it's not really LVM-related.
> The thing is that there's something strange with either the IDE chipset
> (a Promise card) or the corresponding driver that this disk is connected
> to, which causes a kernel panic every time a read from a bad sector is
> attempted. I figure I can "fix" that by connecting the drives to a
> different computer while pvmoving, but I wouldn't prefer to do that, as
> it causes downtime. Does someone on the list know of this problem and
> how to work around it? I figure that I can attempt to fix the driver
> bug, but I wouldn't prefer to experiment with that system...

Actually, if you're having PV errors, it might be the filesystem driver 
that's panic-ing....you'll need to run the output through ksymoops and find 
out where it's dieieng.  If you've corrupted filesystem data, that's the 
much more likely target (although what you're hypothesizing isn't 
impossible, I've just never seen that).

>
> Thanks for your time!
>
> Fredrik Tolf
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>



--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: [linux-lvm] pvmove on broken disk

[Fredrik Tolf]

On Fri, 2005-08-26 at 10:13 -0600, Michael Loftis wrote:
> --On August 26, 2005 3:26:26 PM +0200 Fredrik Tolf <fredrik@dolda2000.com> 
> wrote:
> > I've got a related question as well, but it's not really LVM-related.
> > The thing is that there's something strange with either the IDE chipset
> > (a Promise card) or the corresponding driver that this disk is connected
> > to, which causes a kernel panic every time a read from a bad sector is
> > attempted. I figure I can "fix" that by connecting the drives to a
> > different computer while pvmoving, but I wouldn't prefer to do that, as
> > it causes downtime. Does someone on the list know of this problem and
> > how to work around it? I figure that I can attempt to fix the driver
> > bug, but I wouldn't prefer to experiment with that system...
> 
> Actually, if you're having PV errors, it might be the filesystem driver 
> that's panic-ing....you'll need to run the output through ksymoops and find 
> out where it's dieieng.  If you've corrupted filesystem data, that's the 
> much more likely target (although what you're hypothesizing isn't 
> impossible, I've just never seen that).

Thanks for the tip, but the panic message gave enough info for me to
conclude that it's a NULL pointer dereference in ide_timer_expiry.
Unfortunately, I hadn't compiled the kernel with debugging support,
however, so it's hard for me to determine just where in ide_timer_expiry
at this point.

Fredrik Tolf