From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 1 Oct 2008 16:59:10 +0200 From: Lars Ellenberg To: Thomas Schoebel-Theuer Subject: Re: [Drbd-dev] Behaviour of verify: false positives -> true positives Message-ID: <20081001145910.GG19381@soda.linbit> References: <200809091602.31104.thomas.schoebel-theuer@1und1.de> <200810011328.02278.thomas.schoebel-theuer@1und1.de> <20081001114619.GF19381@soda.linbit> <200810011449.23052.thomas.schoebel-theuer@1und1.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200810011449.23052.thomas.schoebel-theuer@1und1.de> Cc: drbd-dev@lists.linbit.com List-Id: Coordination of development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Oct 01, 2008 at 02:49:22PM +0200, Thomas Schoebel-Theuer wrote: > > > 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. I think that is a reasonable attitude ;) so we just don't bio_clone in drbd_req_new then, but bio_alloc a fresh bio with our own bvec and own pages attached, which will be submitted, _and_ be used to sendpage it over. it has to do properly initialized, obviously. we have to make sure to get an extra reference (bio_get) on that private bio then, so it cannot vanish while being handed over to tcp, it has to stay around until master bio completion (where an extra bio_put will free it). _maybe_ we could add full struct bio private_bio + reasonably sized bvec array member to struct drbd_request, so we can skip the extra bio_alloc, _get and _put (unless there is some paranoia code in the generic block layer, which may be unhappy with that). > Well, before implementing it I will reason on it for some time just to be sure > and convinced. Maybe I should implement both alternatives implement the "most correct" alternative. > and do some stress-testing on a debug kernel? absolutely. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.