On Sat, 2007-10-27 at 11:26 -0400, Bill Davidsen wrote:
> Alberto Alonso wrote:
> > On Fri, 2007-10-26 at 18:12 +0200, Goswin von Brederlow wrote:
> >
> >
> >> Depending on the hardware you can still access a different disk while
> >> another one is reseting. But since there is no timeout in md
Alberto Alonso wrote:
On Fri, 2007-10-26 at 18:12 +0200, Goswin von Brederlow wrote:
Depending on the hardware you can still access a different disk while
another one is reseting. But since there is no timeout in md it won't
try to use any other disk while one is stuck.
That is exactly what
On Fri, 2007-10-26 at 18:12 +0200, Goswin von Brederlow wrote:
> Depending on the hardware you can still access a different disk while
> another one is reseting. But since there is no timeout in md it won't
> try to use any other disk while one is stuck.
>
> That is exactly what I miss.
>
> MfG
Bill Davidsen <[EMAIL PROTECTED]> writes:
> Alberto Alonso wrote:
>> On Tue, 2007-10-23 at 18:45 -0400, Bill Davidsen wrote:
>>
>>
>>> I'm not sure the timeouts are the problem, even if md did its own
>>> timeout, it then needs a way to tell the driver (or device) to stop
>>> retrying. I don't bel
On Fri, 26 Oct 2007, Goswin von Brederlow wrote:
Justin Piszcz <[EMAIL PROTECTED]> writes:
On Fri, 19 Oct 2007, Alberto Alonso wrote:
On Thu, 2007-10-18 at 17:26 +0200, Goswin von Brederlow wrote:
Mike Accetta <[EMAIL PROTECTED]> writes:
What I would like to see is a timeout driven fal
Justin Piszcz <[EMAIL PROTECTED]> writes:
> On Fri, 19 Oct 2007, Alberto Alonso wrote:
>
>> On Thu, 2007-10-18 at 17:26 +0200, Goswin von Brederlow wrote:
>>> Mike Accetta <[EMAIL PROTECTED]> writes:
>>
>>> What I would like to see is a timeout driven fallback mechanism. If
>>> one mirror does not
On Wed, 2007-10-24 at 16:04 -0400, Bill Davidsen wrote:
> I think what you really want is to notice how long the drive and driver
> took to recover or fail, and take action based on that. In general "kick
> the drive" is not optimal for a few bad spots, even if the drive
> recovery sucks.
The
Alberto Alonso wrote:
On Tue, 2007-10-23 at 18:45 -0400, Bill Davidsen wrote:
I'm not sure the timeouts are the problem, even if md did its own
timeout, it then needs a way to tell the driver (or device) to stop
retrying. I don't believe that's available, certainly not everywhere,
and anyt
On Tue, 2007-10-23 at 18:45 -0400, Bill Davidsen wrote:
> I'm not sure the timeouts are the problem, even if md did its own
> timeout, it then needs a way to tell the driver (or device) to stop
> retrying. I don't believe that's available, certainly not everywhere,
> and anything other than eve
Alberto Alonso wrote:
On Thu, 2007-10-18 at 17:26 +0200, Goswin von Brederlow wrote:
Mike Accetta <[EMAIL PROTECTED]> writes:
What I would like to see is a timeout driven fallback mechanism. If
one mirror does not return the requested data within a certain time
(say 1 second) then
On Sat, 20 Oct 2007, Michael Tokarev wrote:
There was an idea some years ago about having an additional layer on
between a block device and whatever else is above it (filesystem or
something else), that will just do bad block remapping. Maybe it was
even implemented in LVM or IBM-proposed EVM
Justin Piszcz wrote:
[]
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to [EMAIL PROTECTED]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Justin, forgive me please, but can you learn to trim the original
messages wh
On Fri, 19 Oct 2007, Alberto Alonso wrote:
On Thu, 2007-10-18 at 17:26 +0200, Goswin von Brederlow wrote:
Mike Accetta <[EMAIL PROTECTED]> writes:
What I would like to see is a timeout driven fallback mechanism. If
one mirror does not return the requested data within a certain time
(say 1
On Thu, 2007-10-18 at 17:26 +0200, Goswin von Brederlow wrote:
> Mike Accetta <[EMAIL PROTECTED]> writes:
> What I would like to see is a timeout driven fallback mechanism. If
> one mirror does not return the requested data within a certain time
> (say 1 second) then the request should be duplicat
Mike Accetta <[EMAIL PROTECTED]> writes:
> Also, read errors don't tend to fail the array so when the bad disk is
> again accessed for some subsequent read the whole hopeless retry process
> begins anew.
>
> I posted a patch about 6 weeks ago which attempts to improve this situation
> for RAID1 by
On Tue, 2007-10-16 at 17:57 -0400, Mike Accetta wrote:
> Was the disk driver generating any low level errors or otherwise
> indicating that it might be retrying operations on the bad drive at
> the time (i.e. console diagnostics)? As Neil mentioned later, the md layer
> is at the mercy of the low
Mike Accetta wrote:
is at the mercy of the low level disk driver. We've observed abysmal
RAID1 recovery times on failing SATA disks because all the time is
being spent in the driver retrying operations which will never succeed.
Also, read errors don't tend to fail the array so when the bad disk
Alberto Alonso writes:
> On Sun, 2007-10-14 at 08:50 +1000, Neil Brown wrote:
> > On Saturday October 13, [EMAIL PROTECTED] wrote:
> > > Over the past several months I have encountered 3
> > > cases where the software RAID didn't work in keeping
> > > the servers up and running.
> > >
> > > In al
On Sun, 2007-10-14 at 10:21 -0600, Maurice Hilarius wrote:
> Alberto Alonso wrote:
> >
> PATA (IDE) with
> Master and Slave drives is a "bad idea" as, when one drive fails, the
> other of the Master & Slave pair often is no longer usable.
> On discrete interfaces, with all drives configured as
On Sun, 2007-10-14 at 08:50 +1000, Neil Brown wrote:
> On Saturday October 13, [EMAIL PROTECTED] wrote:
> > Over the past several months I have encountered 3
> > cases where the software RAID didn't work in keeping
> > the servers up and running.
> >
> > In all cases, the failure has been on a sin
On Saturday October 13, [EMAIL PROTECTED] wrote:
> Over the past several months I have encountered 3
> cases where the software RAID didn't work in keeping
> the servers up and running.
>
> In all cases, the failure has been on a single drive,
> yet the whole md device and server become unresponsi
RAID0 is non redundant so a disk failure will correctly fail the array.
Alberto Alonso wrote:
Over the past several months I have encountered 3
cases where the software RAID didn't work in keeping
the servers up and running.
In all cases, the failure has been on a single drive,
yet the whole md
Over the past several months I have encountered 3
cases where the software RAID didn't work in keeping
the servers up and running.
In all cases, the failure has been on a single drive,
yet the whole md device and server become unresponsive.
(usb-storage)
In one situation a RAID 0 across 2 USB dri
23 matches
Mail list logo
