linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Robinson <john.robinson@anonymous.org.uk>
To: Roman Mamedov <rm@romanrm.ru>
Cc: Jason Tinker <jsntinker@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: Incompatibility of internal bitmap with ext4 barriers?
Date: Tue, 17 May 2011 21:20:43 +0100	[thread overview]
Message-ID: <4DD2D89B.4050700@anonymous.org.uk> (raw)
In-Reply-To: <20110518010020.353e5865@natsu>

On 17/05/2011 20:00, Roman Mamedov wrote:
> On Tue, 17 May 2011 22:43:48 +0400
> Jason Tinker<jsntinker@gmail.com>  wrote:
>
>> Do you have RAID5 over RAID0's or an ordinary RAID5? On my box
>> ordinary RAID5 works perfectly too.
>
> Yes, I ran RAID5 of 4x2TB+(1+1TB RAID0)+(1.5+0.5TB RAID0), recently changed to
> RAID6 though, also replaced one of the RAID0s with another 2TB drive.
>
>> If your configuration is also RAID5 over RAID0 and it works fine on
>> 2.6.38 then I'll just wait for next ubuntu lts...
>
> I am not saying you should just give up. The logs you posted seem like
> they can be very helpful in tracking this down. But if it is indeed a kernel
> issue, how do you fix or even debug it it without replacing/compiling a new
> kernel, which is exactly what you do not want to do. And if you're already
> replacing a kernel, why not try a 2.6.38 right away, to check if your issue is
> already solved in there (after all 2.6.32 vs 2.6.38 are eons apart BOTH
> mdadm-wise and ext4-wise).

I've said it before and no doubt I'll say it again, but the RHEL kernels 
are often a lot closer to the most recent than their version numbers 
suggest. It's a little more difficult to tell with EL6, because Red Hat 
don't ship vanilla+patches sources any more, but their .32 series 
includes lots of backported fixes from .38 etc.

Jason, it's probably worth testing with vanilla .38 to see if that does 
fix your problem, then post to Red Hat bugzilla saying so, especially as 
it looks to me like the configuration you're trying to use ought to be a 
supported one - then a future RHEL .32 might well include the fix.

Cheers,

John.
(Not a spokesman for Red Hat, nor anyone else other than myself, and 
sometimes not even that ;-)


      reply	other threads:[~2011-05-17 20:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 12:10 Incompatibility of internal bitmap with ext4 barriers? Jason Tinker
2011-05-17 13:17 ` Roman Mamedov
2011-05-17 18:43   ` Jason Tinker
2011-05-17 19:00     ` Roman Mamedov
2011-05-17 20:20       ` John Robinson [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=4DD2D89B.4050700@anonymous.org.uk \
    --to=john.robinson@anonymous.org.uk \
    --cc=jsntinker@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=rm@romanrm.ru \
    /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).