Re: sd_setup_discard_cmnd: BUG: unable to handle kernel NULL pointer dereference at (null)

[Lars Ellenberg <lars.ellenberg@linbit.com>]

On Tue, Jun 24, 2014 at 07:11:47PM -0400, Martin K. Petersen wrote:
> >>>>> "Lars" == Lars Ellenberg <lars.ellenberg@linbit.com> writes:
> 
> Lars> We are receiving (from network) and submitting (to lower level IO
> Lars> stack) in the same context and would like the submit to be async.
> 
> Lars> Do you intend to provide an asynchronous interface?
> 
> I guess we can look into that if there is a need.
> 
> Do different clients share that context? I.e. does a synchronous discard
> block other clients from accessing the drbd server?

Uhm, it's not like exactly like that, really.

Because the way we do some internal bookkeeping,
we announce a max discard of 4 MiB.
So if some user on the "active" (Primary) DRBD
does large discards, you will end up submitting
lots of bios, and these are async.

Bios are the entry point to DRBD.
So DRBD ships these discard-bios over to the peer,
which then right now submits them as bios, again async.
So we do some pipelining, may have a number of discard bios in flight,
and effectively the latency will be increased by something in the order
of the network rtt.

If we now have to use the synchronous interface on the peer
for each discard bio, there is no longer any pipelining,
and the overall latency of a single "user" level discard
(that ends up doing many discard bios) will noticeably increase.

Also, since the "receiver" is blocked in "submit",
we cannot meanwhile interleave other, "normal" BIOs,
so a larger discard will block all write (and depending on configuration
and current state, also read) within that DRBD resource (which again may
be one or more DRBD minor devices or "volumes").

I don't have real-life numbers on how much that may hurt.

Similar for the WRITE_SAME interface (which we do not properly support
on the DRBD protocol level yet -- backward compatibility concerns -- but
intend to support "soon").

If we only have a synchronous interface,
we will probably have to either add some "async wrapper",
or defer such submissions to worker threads.
I'd prefer to have an async submit path.

	Lars