[ENBD] two questions

[Peter T. Breuer]

"A month of sundays ago Wang Gang wrote:"

> Hi, Peter:
> I have two questions to ask you:
> 1. ENBD can't be used under kernel 2.4.0. I have tried 2.4.15, 2.2.29, nb=
d.c, nbd-2.4.0.c, but all=20
> reported error when compile. I found some structure definitions are not s=
ame as those in kernel
> 2.4.0. What can I do?

Use 2.4.20. It's the one in which I have been making changes for kernel 2.4=
.0.
It appears to compile and I have tested that reads are successful. It
is only just beginning to work, so be careful. I'll announce it
(really!) on freshmeat when it passes the regression tests.=20

It's available from
http://www.it.uc3m.es/ptb/nbd/src/nbd-2.4-current.tgz

That's the nightly build - it changes.

> 2. Why the read performance of ENBD is too poor (compared with write perf=
ormance).

I hadn't noticed.  I can't think of a reason for this, but several
factors in the driver may be involved:

  1) readahead
  2) plugging
  3) request merging

Readahead is a value that can be changed. It's a module parameter
(rahead). It's the number of sectors (blocks?) to prefetch on each
read. I am not sure, but I think the 2.2.* kernel prefetches on each
read unless the prefetch is cached, while the 2.4.* kernel prefetches
only on each uncached read. I.e. 2.4.* is better.

The kernel (<=3D 2.2.*) disables plugging for nbd in the main source. You
have to patch the bit of ll_blk_rw.c that does that if you want to try
it with plugging. "plugging" is the mechanism whereby the kernel blocks
access to the driver when the request queue for it is empty, then
merges (make_request in ll_blk_rw)  requests as they arrive until it
has 20 distinct requests, then sends the lot to the driver at once.

The result is bigger requests, with less overhead in each.

The reason that it is disabled is that nobody knew why but
it =B5sed to cause horrible death for nbd. I believe I know why: the
unplug was scheduled in the disk task queue, which is too soon for
something like nbd which needs to use the net. I moved the unplug
to the scheduler task queue, and had no problems. But for safety
I left the driver not using plugs at all.

I tried also using the kernel plug to throttle the device - I don't
think it's successful, but it's not harmful. I think plug=3D0 (off)
is set by default in the driver.

In any case, request merging is disabled in 2.2.* because it caused
horrible things to happen. I never knew why. It worked fine in 2.0.*.
There is some suspicion that the kernel can agglomerate non-contiguous
buffers into a single request, which wrecks a basic hypothesis. But
I don't see where it can do it.

Since the 2.4.0 request_merge code is better and easier to understand,
I have hopes of that becoming the standard. But it doesn't =E6xplain
an asymmetry between reading and writing.

Another possibility, of course, is that it is the other end that is
slower at reading than writing.

Peter