From: Lars Marowsky-Bree <lmb@suse.de>
To: Brian Jackson <brian-kernel-list@mdrx.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: md on shared storage
Date: Wed, 13 Nov 2002 12:46:41 +0100 [thread overview]
Message-ID: <20021113114641.GI19811@marowsky-bree.de> (raw)
In-Reply-To: <20021113002529.7413.qmail@escalade.vistahp.com>
On 2002-11-12T18:25:29,
Brian Jackson <brian-kernel-list@mdrx.com> said:
> Does the MD driver work with shared storage? I would also be interested to
> know if the new DM driver works with shared storage(though I must admit I
> didn't really try to answer this one myself, just hoping somebody will
> know).
The short answer is "Not sanely", as far as I know.
RAID0 might be okay, however RAID1/5 get into issues if two nodes update the
same data in parallel; they do not coordinate the writes, and thus might stomp
over each other.
In theory, given a RAID1 with disks {d1,d2}, node n1 might write in order
(d2,d1) while n2 writes as (d1,d2), resulting in inconsistent mirrors. This
becomes a bigger race window for RAID5, obviously, because more disks are
involved.
The "multiple nodes beginning to reconstruct the same md device" is also a
problem; but even if that was solved that only one node does the recovery, the
others would be blocked from doing any IO on that drive for the time being.
Another issue that any node will want to update the md superblock regularly.
LVM is fine, MD doesn't seem to be.
With the MD patches I posted weeks ago, at least MD multipathing should work
appropriately; even if the ugliness of multiple nodes scribbling over the
superblock remains, it shouldn't matter because the autodetection is based
only on the UUID for m-p.
In short, you can do "MD", if you don't use it as "shared"; have only one node
have a given md device active at any point in time. Thus, no autostart, but
manual activation. This rules out "GFS over md", basically.
If you want to fix that, it would be cool; it will just require a DLM,
membership and communication services in the kernel. ;-)
Sincerely,
Lars Marowsky-Brée <lmb@suse.de>
--
Principal Squirrel
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
next prev parent reply other threads:[~2002-11-13 11:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-13 0:25 md on shared storage Brian Jackson
2002-11-13 1:19 ` Steven Dake
2002-11-13 3:00 ` Michael Clark
2002-11-13 3:15 ` Brian Jackson
2002-11-13 13:22 ` Michael Clark
2002-11-13 2:51 ` Michael Clark
2002-11-13 11:46 ` Lars Marowsky-Bree [this message]
2002-11-13 17:17 ` Steven Dake
2002-11-13 17:25 ` Joel Becker
2002-11-13 17:56 ` Steven Dake
2002-11-13 17:24 ` Joel Becker
2002-11-13 15:35 ` Eric Weigle
2002-11-13 18:33 ` Brian Jackson
-- strict thread matches above, loose matches on Subject: below --
2002-11-13 19:25 Eric Weigle
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=20021113114641.GI19811@marowsky-bree.de \
--to=lmb@suse.de \
--cc=brian-kernel-list@mdrx.com \
--cc=linux-kernel@vger.kernel.org \
/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