Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Jun 04, 2007 at 11:58:30AM -0500, David Masover wrote: > On Monday 04 June 2007 08:56:41 Lars Ellenberg wrote: > > > you talk about DRBD + OCFS2 on a low bandwidth high latency link, > > and you want to improve on the "sluggish" behaviour by making > > drbd replication asynchronous, buffering writes for minutes. [ and here I explained why this does not make sense ... ] > Except I gave up OCFS2 ... and there you tell us that you gave up on OCFS2 anyways. so why did you suggest it at all. > Also, not entirely. I want writes to be asynchronous with respect to reads, > not with respect to other writes. In other words: "writes asynchronous with respect to reads" does not make sense to me, either, but at least this time you give an example about what you mean: > dd if=/dev/zero of=/dev/drbd0 bs=1M count=1 > > The above can hang as long as it takes to get across the network. And if, at > the same time, I'm trying to do this: > > dd if=/dev/drbd0 of=/dev/null bs=1M count=1 > > Then sure, let that one hang, too. no, it should not necessarily hang. if you tune your io scheduler for that purpose, it may finish long before the writing dd. and it may or may not return "stale" data, obviously. so yes, if you have dependencies on previous writes, you need to wait for them to be completed first. > What I don't get is this: > > dd if=/dev/drbd0 of=/dev/null bs=1M count=1 skip=1 > > That one should be instantaneous, no, since "skip" for dd litteraly means skip, it does not mean seek. it means read /dev/drbd0 from the start (offset 0), throw away the first megabyte, then ouput the second megabyte. > even while the other two are blocking. This behavior may well not work > for a clustered filesystem, like OCFS2. However, it would work very > well for a single-machine filesystem, like ResierFS -- and it seems > like this should be possible whenever allow-two-primaries is disabled. again, if you want short read latency, tune your system that way. reads in drbd do not block on writes. if it apears to you that way, I'm sorry. but they don't. so find out what actually happens on the block layer. there is lots of information available in /proc/ and /sys/. tune the io scheduler(s). get the queue length down. just do it. then, maybe, there are some knobs to turn in the drbd conf, to improve overall performance. but the should have almost no effect for reads that can be carried out locally. and there is no "works for all" advice here, I'm sorry. which knobs to turn in which direction very much depends on the respective system. > > in any case, we are developing drbd "addons", or lets say a protocol > > extension of drbd, to actually allow asynchronous replication with some > > tunable backlog of minutes/hours. > > That would be perfect for this application > -- if the writes can stay in the same order. obviously. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com :