Fix #4429
closedlibceph: support a list of data items in a message
0%
Description
This will require a number of patches to complete, but
it's a logical unit of work.
An abstracted data item is now used to represent a block
of data, either a list of pages, a page array, or a bio
list. What we will want for multiple ops is to allow
more than one such data item to be associated with a
message. That way, an osd request can build up a single
request message containing an array of ops, and each of
those ops can independently append a data item to be used
for outgoing or incoming data, in whatever form is required
(page list, bio, etc.).
This depends on completion of the work to abstract the
data item, and to use it for both read and write requests.
The general sequence I intend to follow is:
- collapse the separate structures representing data in
a message (now named "p", "l", and "b" for a page array,
page list, and bio list) into a single item. It turns
out only one of these is ever (currently) used for any
message (though that wasn't obvious before). They'll
all be represented by a structure "data" that will be
handled by the messenger according to its representation.
- Replace the single "data" structure with a pointer to such
a structure. Allocate that structure dynamically only
when a message will have a data portion.
- Implement a list of these structures, with the "data"
field in the message tracking the head (and tail) of
data items on that list.
- Have the callers that now "set" the data field instead
"add" it to the existing data in a message.
- Use this capability in the osd client for multiple ops
that carry data. (This may just be a contrived test
for now.)
This is related to http://tracker.ceph.com/issues/3761.