Re: [PATCH 00/12] DRBD: a block device for HA clusters

[Nikanth K]

Hi Philipp,

On Mon, Mar 30, 2009 at 10:17 PM, Philipp Reisner
<philipp.reisner@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/