[Drbd-dev] Behaviour of verify: false positives -> true positives

Thomas Schoebel-Theuer thomas.schoebel-theuer at 1und1.de
Wed Oct 1 14:49:22 CEST 2008


> > Well, one problem is that the length of bvec could be nearly arbitrary
> > (in theory),
>
> BIO_MAX_PAGES
> DRBD_MAX_SEGMENT_SIZE

Ok.

> > But what about simply generating a completely new bio and copying over
> > all the stuff by hand? This would mean to implement some sort of
> > bio_copy() in the local code which could then later be lifted upstreams
> > if other people liked it too. What do you think is better?
>
> no, I think it would be enough to just set (pseudo code)
> copy_page->private = orig_page;

Hmm. what if the caller used orig_page->private already and is now accessing 
the page _in parallel_ to us? IMHO in combination with the next step it 
_could_ lead to an observable difference:

> bvec->bv_page = copy_page;

IMHO this could cause a side effect for any observer accessing "his" page 
via "his" orig_bio and finally arriving at our copy_page->private. I am not 
sure whether this really happens in the kernel anywhere, but even if 
currently not it probably could happen sometime in future. The idea behind 
bio_copy() was to _never_ touch the original and all its transitively 
reachable descendants in any way, just to be sure nothing can ever go wrong 
with it (similar to a COW style). Well, the performance might be slightly 
worse, but we are reasoning on correctness at a rather tricky high level.

I am not sure whether it really does any harm, I'm just curious and cautious.

Well, before implementing it I will reason on it for some time just to be sure 
and convinced. Maybe I should implement both alternatives and do some 
stress-testing on a debug kernel?

Thanks for your feedback,

Thomas


More information about the drbd-dev mailing list