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-21 16:46:06 +0100 \ Nuno Tavares: > Lars, > > 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" > return > endif > endif > write(file) > endif > > 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? well, "allowing concurrent access" *always* implies correct locking. and, DRBD is a BLOCK DEVICE, not a file system. and, even if we allow the access, how do we handle error cases ? as long as we cannot cope with errors, there is no point in allowing it. yes, I already have some "weird concepts" in the back of my head for it. but currently we need to make it *work* first, then we can add features. go ahead, make a good concept for two nodes concurrently accessing two blockdevices, which are expected to look identical, and keep in mind that we need to be able to (re)sync after error cases, and that each node needs to be sure it has *the same* consistent view of the data as its peer, if present... get a pen an paper, and write it down. sleep over it. post the results here. we shall be happy to discuss it. Lars Ellenberg