Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Greetings,
First I want to complement whoever wrote this code; it's actually readable!
I have two questions about the below comment in the make_request() read path.
First, isn't it ok for a read to return old data if the write is issued
while the read is still outstanding? Second, isn't it true that we must
wait for the sync because of the possibility that the source could disconnect?
We don't want to return data from the sync source to the application that
we can't replicate should the application ask for the same block latter, so
we must wait for the data to be committed locally. In this case I'm referring
to a sync for crash recovery rather than for adding a new disk. It crash recovery
you should be able to continue service when the remote system disconnects,
even though the sync is not finished, because both copies are equally valid.
If drbd doesn't make this distiction, then you must fail when the primary
disconnects as a sync target, and I suppose this code path is fine. Given
the length of recovery, the disticution is worth making. FYI: tl_add_barrier()
and tl_clear() do not test the result of kmalloc() where every other use does.
If you can't do anything with the failure, I'd suggest putting in an assert().
Cheers,
Alan
if (target_area_out_of_sync) {
/* whe could kick the syncer to
* sync this extent asap, wait for
* it, then continue locally.
* Or just issue the request remotely.
*/
/* FIXME I think we have a RACE here
* we request it remotely, then later some write starts ...
* and finished *before* the answer to the read comes in,
* because the ACK for the WRITE goes over meta-socket ...
* I think we need to properly lock reads against the syncer, too.
*/
local = 0;
dec_local(mdev);
}
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail