On 2005-04-13T11:26:05, Lars Marowsky-Bree <lmb@xxxxxxx> wrote:
Ok, so the subject is a bit of a lie, because I haven't yet brought over
all changes from our 2.4.21 vendor kernel to 2.4.30 (as I'd need to
disentangle some feature additions first which Neil doesn't like).
However, I've found the root cause of the data corruption issue with md
multipath, after having been side tracked by the abhorrent locking
issues ;-)
It's this innocent "bh->b_rsector = bh->b_blocknr;" in
multipath.c:multipathd(), an obvious artifact from having forked this
from raid1.c - where however this has a clearly different meaning.
For md multipath, this basically implies that _EVERY_ IO which was
in-flight when the error happened and was requeued will be written to a
wrong block on disk.
A minimal fix would be to remove at least this one line, if one didn't
want to fix the locking raid1.c-style (was introduced with 2.4.28).
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
