[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <807b3a220904070523t746ad2abx6a46d30e816eb1d6@mail.gmail.com>
Date: Tue, 7 Apr 2009 17:53:14 +0530
From: Nikanth K <nikanth@...il.com>
To: Philipp Reisner <philipp.reisner@...bit.com>
Cc: linux-kernel@...r.kernel.org, gregkh@...e.de,
jens.axboe@...cle.com, nab@...ingtidestorage.com,
andi@...stfloor.org, Nikanth Karthikesan <knikanth@...e.de>
Subject: Re: [PATCH 00/12] DRBD: a block device for HA clusters
Hi Philipp,
On Mon, Mar 30, 2009 at 10:17 PM, Philipp Reisner
<philipp.reisner@...bit.com> wrote:
> Hi,
>
> This is a repost of DRBD, to keep you updated about the ongoing
> cleanups.
>
> Description
>
> DRBD is a shared-nothing, synchronously replicated block device. It
> is designed to serve as a building block for high availability
> clusters and in this context, is a "drop-in" replacement for shared
> storage. Simplistically, you could see it as a network RAID 1.
>
> Each minor device has a role, which can be 'primary' or 'secondary'.
> On the node with the primary device the application is supposed to
> run and to access the device (/dev/drbdX). Every write is sent to
> the local 'lower level block device' and, across the network, to the
> node with the device in 'secondary' state. The secondary device
> simply writes the data to its lower level block device.
>
> DRBD can also be used in dual-Primary mode (device writable on both
> nodes), which means it can exhibit shared disk semantics in a
> shared-nothing cluster. Needless to say, on top of dual-Primary
> DRBD utilizing a cluster file system is necessary to maintain for
> cache coherency.
>
> This is one of the areas where DRBD differs notably from RAID1 (say
> md) stacked on top of NBD or iSCSI. DRBD solves the issue of
> concurrent writes to the same on disk location. That is an error of
> the layer above us -- it usually indicates a broken lock manager in
> a cluster file system --, but DRBD has to ensure that both sides
> agree on which write came last, and therefore overwrites the other
> write.
>
So this difference to RAID1+NBD is required only if the DLM of the
clustered fs is buggy?
> More background on this can be found in this paper:
> http://www.drbd.org/fileadmin/drbd/publications/drbd8.pdf
>
> Beyond that, DRBD addresses various issues of cluster partitioning,
> which the MD/NBD stack, to the best of our knowledge, does not
> solve. The above-mentioned paper goes into some detail about that as
> well.
>
It would be nice, if you can list those limitations of NBD/RAID here.
Thanks
Nikanth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists