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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/