Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Saturday 03 July 2004 17:13, Alan Jones wrote:
> 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.
> */
>
Hi,
This comment is by LGE. It referes to an "unnatural" usage pattern, that
no known filesystem has.
What it describes is:
1. FS starts read.
2. DRBD has to ship the read to the peer
3. FS starts write to the same location. (Which does not make sense!)
4. DRBD signals the completion of the two operations, note that DRBD
will return the old data for the read request.
A) No FS issues such ussage patterns.
B) Which data should be returned in this read anyway? The old, or the new
version ?
Lars and I agreed that we do not need to take care of this case...
PS: I will fix these two unchecked kmalloc()s ...
-Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :