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-22 02:34:17 +0100 \ Nuno Tavares: > Em Wed, 21 Apr 2004 18:04:24 +0200, Lars Ellenberg escreveu: > > > well, "allowing concurrent access" *always* implies correct locking. > > and, DRBD is a BLOCK DEVICE, not a file system. > > Sorry, i keep forgetting 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. > > How do you mean? It doesn't work at all? Which is the last working/better > version? 0.6.12 is perfectly stable. 0.7 is actively developed, and we are very busy with it. iron out the remaining races, thinkos, logic an other bugs. conceptually it is much better, and features will be added only to 0.7. but only after 0.7 is no longer -pre, but at least -rc . thats what I mean. > > 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... > > Just wondering.. ever thought of splitting the work by 2 layers (kernel > and user space)? what do we gain? and, maybe you are not looking for DRBD, but some other project, OPenGFS, maybe Intermezzo (never looked at that one so far), ... > > get a pen an paper, and write it down. sleep over it. post the results > > here. we shall be happy to discuss it. > > Well, that, I can try! :) ok, but as mentioned: at any time, each node needs to have either the very same consistent view of the data as the peer, or know it cannot, and refuse to access the data at all. Or, as last resort, be forced by operator to believe it has the best data available. And, we need to be able to track down any changes, and resync them. > Lars, what about the other questions I've made? must have overlooked them.