[ENBD] ENBD on 2.4.x

[Peter T. Breuer]

"Peter T. Breuer wrote:"
> Hmmm ... you mean don't try making things safer!
> 
> >     // PTB control merge attempts so we don't overflow our buffers
> >     ll_merge_requests_fn =
> > (BLK_DEFAULT_QUEUE(MAJOR_NR))->merge_requests_fn;
> >     ll_front_merge_fn    =
> > (BLK_DEFAULT_QUEUE(MAJOR_NR))->front_merge_fn;
> >     ll_back_merge_fn     = (BLK_DEFAULT_QUEUE(MAJOR_NR))->back_merge_fn;
> >     (BLK_DEFAULT_QUEUE(MAJOR_NR))->merge_requests_fn =
> > &nbd_merge_requests_fn;
> >     (BLK_DEFAULT_QUEUE(MAJOR_NR))->front_merge_fn    =
> > &nbd_front_merge_fn;
> >     (BLK_DEFAULT_QUEUE(MAJOR_NR))->back_merge_fn     =
> > &nbd_back_merge_fn;
> 
> You can check, but you'll see that those functions do nothing if
> merge-requests=0 is set. But clearly, if things are in flux there, I
> need to do nothing until I know better. So I agree with this change.

But as a word of protest, you can see that the function I substituted
does nothing except return 0 if merge_requests=0 is set (which is the
default), otherwise call the original, which I saved in ll_blah_blah.
The extra check here is to make sure the request is not getting
too big for our internal buffer.

  static int
  nbd_front_merge_fn(request_queue_t *q, struct request *req,
    struct buffer_head *bh, int max_segments)
  {
    if (!merge_requests)
      return 0;
    if (req->nr_sectors + (bh->b_size >> 9) > buf_sectors)
      return 0;
    return ll_front_merge_fn(q,req,bh,1);
  }
  static int
  nbd_back_merge_fn(request_queue_t *q, struct request *req,
    struct buffer_head *bh, int max_segments)
  {
    if (!merge_requests)
      return 0;
    if (req->nr_sectors + (bh->b_size >> 9) > buf_sectors)
      return 0;
    return ll_back_merge_fn(q,req,bh,1);
  }


So either "return 0" is now incorrect, or what? Why not try it with
"merge_requests=1" as a module option to see if the kernel's routine
is now the better choice always. The requests should never get too
big for our buffer anyway.



Peter