On 1082825674 seconds since the Beginning of the UNIX epoch
Christian Limpach wrote:
>

>Doesn't this mess up the ordering of the buffers on the queue when diskstart
>doesn't process a buf and we have to put it back on the queue with BUFQ_PUT?

I don't think that there are many situations where this can actually
happen.  dk_start() is called at splbio(), so this change should
mostly affect what happens when dk_start() is called on the same
device further down the stack.  In this case, we are guaranteed
that the buffers will be put back in order in failure cases.  (In
fact, in cgd.c we should not actually get to another dk_start on
the same device until we actually know that the buffer will not be
put back on the queue---but that's another issue.)

We may OTOH have this issue in a multi-CPU case.  We should have a
look at that case.

Also, we should also not that although preserving the ordering is
desirable, it is by no means necessary.  E.g. the underlying disk
driver will be putting the buffer into its queue using disksort().
Ordering properties are preserved using the iodone() routines to
callback the higher layers and let them know that the blocks have
in fact been committed to stable storage.

>Additionally, the change prevents a *start routine from processing and
>dequeueing multiple bufs and then return -1 to make dk_start exit.
>(see arch/xen/xen/xbd.c rev 1.1)

When I wrote the interface, this was not something I was considering.
I'll have a look at it and think about it a little.  :-)

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/