LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Piet Delaney <piet@bluelane.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: Piet Delaney <piet@bluelane.com>, Andrew Morton <akpm@osdl.org>,
noah <noah123@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [dm-devel] Re: Data corruption with raid5/dm-crypt/lvm/reiserfs on 2.6.19.2
Date: Thu, 22 Feb 2007 15:43:13 -0800 [thread overview]
Message-ID: <1172187794.8709.124.camel@piet2.bluelane.com> (raw)
In-Reply-To: <1169502141.17211.7.camel@leto.intern.saout.de>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
On Mon, 2007-01-22 at 22:42 +0100, Christophe Saout wrote:
> Am Montag, den 22.01.2007, 11:56 -0800 schrieb Andrew Morton:
>
> > There has been a long history of similar problems when raid and dm-crypt
> > are used together. I thought a couple of months ago that we were hot on
> > the trail of a fix, but I don't think we ever got there. Perhaps
> > Christophe can comment?
>
> No, I think it's exactly this bug. Three month ago someone came up with
> a very reliable test case and I managed to nail down the bug.
>
> Readaheads that were aborted by the raid5 code (or some layer below)
> were signalled using a cleared BIO_UPTODATE bit, but no error code, and
> were missed as aborted by dm-crypt (all other layers apparently set the
> error code in this case, so this only happened with raid5) which could
> mess up the buffer cache.
>
> Anyway, it then turned out this bug was already "accidentally" fixed in
> 2.6.19 by RedHat in order to play nicely with make_request changes (the
> stuff to reduce stack usage with stacked block device layers), that's
> why you probably missed that it got fixed. The fix for pre-2.6.19
> kernels went into some 2.6.16.x and 2.6.18.6.
Hi Chris:
I've been trying Andrew's suggestion of doing fault injections,
currently just kmalloc() and mempool_alloc(), and just got a hang
on 2.6.12 that I'm poking around on with kgdb. I'm using dm-crypt
on a SCSI raid-1 (mirrored) root partition. I'm using your patch
that fixes the raid5 problem just to play it safe.
So far it looks like processes are waiting to be woken up by
the buffer cache once reads have completed.
-piet
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
--
Piet Delaney Phone: (408) 200-5256
Blue Lane Technologies Fax: (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014 Email: piet@bluelane.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2007-02-22 23:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-18 20:11 noah
2007-01-22 19:56 ` Andrew Morton
2007-01-22 21:42 ` Christophe Saout
2007-02-22 23:43 ` Piet Delaney [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=1172187794.8709.124.camel@piet2.bluelane.com \
--to=piet@bluelane.com \
--cc=akpm@osdl.org \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=noah123@gmail.com \
--subject='Re: [dm-devel] Re: Data corruption with raid5/dm-crypt/lvm/reiserfs on 2.6.19.2' \
/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
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).