On Fri, 14 Jan 2000, D. Lance Robinson wrote:
>Ingo,
>
>I can fairly regularly generate corruption (data or ext2 filesystem) on a busy
>RAID-5 by adding a spare drive to a degraded array and letting it build the
>parity. Could the problem be from the bad (illegal) buffer interactions you
>mention
Hi,
Chris Wedgwood writes:
> > This may affect data which was not being written at the time of the
> > crash. Only raid 5 is affected.
>
> Long term -- if you journal to something outside the RAID5 array (ie.
> to raid-1 protected log disks) then you should be safe against this
> type of
Hi,
Benno Senoner writes:
> wow, really good idea to journal to a RAID1 array !
>
> do you think it is possible to to the following:
>
> - N disks holding a soft RAID5 array.
> - reserve a small partition on at least 2 disks of the array to hold a RAID1
> array.
> - keep the journal o
Ingo,
I can fairly regularly generate corruption (data or ext2 filesystem) on a busy
RAID-5 by adding a spare drive to a degraded array and letting it build the
parity. Could the problem be from the bad (illegal) buffer interactions you
mentioned, or are there other areas that need fixing as well
Chris Wedgwood wrote:
> > In the power+disk failure case, there is a very narrow window in which
> > parity may be incorrect, so loss of the disk may result in inability to
> > correctly restore the lost data.
>
> For some people, this very narrow window may still be a problem.
> Especially when
Hi,
On Wed, 12 Jan 2000 22:09:35 +0100, Benno Senoner <[EMAIL PROTECTED]>
said:
> Sorry for my ignorance I got a little confused by this post:
> Ingo said we are 100% journal-safe, you said the contrary,
Raid resync is safe in the presence of journaling. Journaling is not
safe in the presence
Hi,
On Wed, 12 Jan 2000 07:21:17 -0500 (EST), Ingo Molnar <[EMAIL PROTECTED]>
said:
> On Wed, 12 Jan 2000, Gadi Oxman wrote:
>> As far as I know, we took care not to poke into the buffer cache to
>> find clean buffers -- in raid5.c, the only code which does a find_buffer()
>> is:
> yep, this i
Hi,
On Tue, 11 Jan 2000 16:41:55 -0600, "Mark Ferrell"
<[EMAIL PROTECTED]> said:
> Perhaps I am confused. How is it that a power outage while attached
> to the UPS becomes "unpredictable"?
One of the most common ways to get an outage while on a UPS is somebody
tripping over, or otherwise r
"Stephen C. Tweedie" wrote:
> Ideally, what I'd like to see the reconstruction code do is to:
>
> * lock a stripe
> * read a new copy of that stripe locally
> * recalc parity and write back whatever disks are necessary for the stripe
> * unlock the stripe
>
> so that the data never goes through t
On Wed, 12 Jan 2000, Gadi Oxman wrote:
> As far as I know, we took care not to poke into the buffer cache to
> find clean buffers -- in raid5.c, the only code which does a find_buffer()
> is:
yep, this is still the case. (Sorry Stephen, my bad.) We will have these
problems once we try to elimin
James Manning wrote:
> [ Tuesday, January 11, 2000 ] Benno Senoner wrote:
> > The problem is that power outages are unpredictable even in presence
> > of UPSes therefore it is important to have some protection against
> > power losses.
>
> I gotta ask dying power supply? cord getting ripped o
Perhaps I am confused. How is it that a power outage while attached
to the UPS becomes "unpredictable"?
We run a Dell PowerEdge 2300/400 using Linux software raid and the
system monitors it's own UPS. When power failure occures the system
will bring itself down to a minimal state (runleve
- Original Message -
From: "Benno Senoner" <[EMAIL PROTECTED]>
To: "Stephen C. Tweedie" <[EMAIL PROTECTED]>
Cc: "Linux RAID" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; "Ingo Molnar" <[EMAIL PROTECTED]>
Sent: Tues
Hi,
On Wed, 12 Jan 2000 00:12:55 +0200 (IST), Gadi Oxman
<[EMAIL PROTECTED]> said:
> Stephen, I'm afraid that there are some misconceptions about the
> RAID-5 code.
I don't think so --- I've been through this with Ingo --- but I
appreciate your feedback since I'm getting inconsistent advise her
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Tue, 11 Jan 2000 15:03:03 +0100, mauelsha
> <[EMAIL PROTECTED]> said:
>
> >> THIS IS EXPECTED. RAID-5 isn't proof against multiple failures, and the
> >> only way you can get bitten by this failure mode is to have a system
> >> failure and a disk fail
Hi,
On Tue, 11 Jan 2000 15:03:03 +0100, mauelsha
<[EMAIL PROTECTED]> said:
>> THIS IS EXPECTED. RAID-5 isn't proof against multiple failures, and the
>> only way you can get bitten by this failure mode is to have a system
>> failure and a disk failure at the same time.
> To try to avoid this k
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> This is a FAQ: I've answered it several times, but in different places,
> THIS IS EXPECTED. RAID-5 isn't proof against multiple failures, and the
> only way you can get bitten by this failure mode is to have a system
> failure and a disk failure at the
Hi,
On Tue, 11 Jan 2000 20:17:22 +0100, Benno Senoner <[EMAIL PROTECTED]>
said:
> Assume all RAID code - FS interaction problems get fixed, since a
> linux soft-RAID5 box has no battery backup, does this mean that we
> will loose data ONLY if there is a power failure AND successive disk
> failur
"Stephen C. Tweedie" wrote:
(...)
>
> 3) The soft-raid backround rebuild code reads and writes through the
>buffer cache with no synchronisation at all with other fs activity.
>After a crash, this background rebuild code will kill the
>write-ordering attempts of any journalling files
Hi,
This is a FAQ: I've answered it several times, but in different places,
so here's a definitive answer which will be my last one: future
questions will be directed to the list archives. :-)
On Tue, 11 Jan 2000 16:20:35 +0100, Benno Senoner <[EMAIL PROTECTED]>
said:
>> then raid can miscalcul
20 matches
Mail list logo
