[DRBD-user] Re: loop device and eth0 loop-back + latest version

Nuno Tavares nunotavares at hotmail.com
Wed Apr 21 17:46:06 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.


I've read the rant very fast, much of the text is too tech for me, 
since I haven't analysed the code (even if I could understand it..:).

Anyway, let me throw this in the air:
Why not using locking mechanisms? This may be more simple than 
allowing concurrent write access.
Something like this pseudo-code:

if want_to_write(file) then
   if locked_for_writing(file) then
      if at_least_one_peer_up() then
         print "file is locked. write disabled"

We would write(file) if 1) the file was not locked or 2) the file 
was locked but there were no peer's online (failure). It's very basic, 
but at least there would be some support for concurrent access.

Does this make sense?

Em Wed, 21 Apr 2004 10:03:54 +0200, Lars Ellenberg escreveu:

> / 2004-04-21 05:09:59 +0100
> \ Nuno Tavares:
>> Em Wed, 21 Apr 2004 04:48:55 +0100, Nuno Tavares escreveu:
>> > 2. It seems that drbd_1 is mounted read-only. I need it to be RW. 
>> >    Is it possible?
>> Uh-oh.. from http://www.drbd.org/:
>> Currently drbd grants read-write access only to one node at a time, which
>> is sufficient for the usual fail-over HA cluster. Although it is currently
>> not on my task list, it would not be a great effort to allow both nodes
>> read-write access. This would be useful with GFS  for example.
>> D*mn.. not good.
> see my rant in http://article.gmane.org/gmane.comp.linux.drbd/6088
> about why we do not allow two nodes access at the same time yet.
> 	Lars Ellenberg

Nuno Tavares

More information about the drbd-user mailing list