[DRBD-user] DRBD rw access at both nodes

Lars Ellenberg Lars.Ellenberg at linbit.com
Thu Apr 1 11:02:56 CEST 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


/ 2004-04-01 16:37:55 +0900
\ "Kotrappa(?????)":
> Is it possible ? to use just dd command bypassing file systems??
> i.e dd if=/dev/mem  of=/dev/nb1 bs=1024  count=10

Many things are possible.
Not all of them make sense.
This definitely does not.

sure, it is possible to do this:
 $ROOT_DEV = `mount | grep "on \/ " | cut -d " " -f 1`
 dd if=/dev/zero of=$ROOT_DEV bs=4k
But you won't actually try it, would you?

> I use SUDF ( secure universal disk format filesystem) if that works.

won't work anyways, unless someone has a cluster aware derivative of it.


To clarify:

You want to have more than one node concurrently writing to the same
file system, which in turn is even submitted to more than one physical
storage.

The file system and block device and whatnot drivers need to make sure
that strict write ordering is guranteed, and that proper locking
guarantees that the "concurrency" in IO requests is serialized in the
right way. This is complexity on each level from the file system driver
almost down to the hardware driver.
The full stack of drivers need to guarantee write ordering [1],
and at least the topmost (i.e. the file system driver) needs to
guarantee proper exclusion [2] of concurring IO requests, on all nodes.

Currently DRBD could (with minor tweaks at the *right* places;
no, I won't explain it here, because of [3]) do [1], you still need some
fs like (Open)GFS to do [2]. 

I did not even mention what might happen if the communication
between the nodes, or one of the physical storage devices, or even one
of the nodes, fails.
[3] The complexity resulting from these failure an recovery scenarios is
the reason why DRBD does not support this (yet).

If you have a well thought concept about how each failure scenario and
recovery from it should be handled, covering which node may still access
a device in which failure cases, how should be determined which node has
the valid data after some failure, how should resynchronization be done
and so on and on and on ...

IFF you have such a concept, and a well founded understanding of it,
tell us about it. We shall be very thankful.

Otherwise, just stop blindly trying things which won't work.

	Lars Ellenberg



More information about the drbd-user mailing list