On 12/21/2018 05:35 PM, Ilya Dryomov wrote:
On Tue, Dec 18, 2018 at 11:10 AM Dongsheng Yang
<dongsheng.yang@xxxxxxxxxxxx> wrote:
On 12/05/2018 06:18 PM, Ilya Dryomov wrote:
On Wed, Dec 5, 2018 at 2:17 AM Dongsheng Yang
<dongsheng.yang@xxxxxxxxxxxx> wrote:
On 12/04/2018 10:28 PM, Ilya Dryomov wrote:
On Mon, Dec 3, 2018 at 1:51 PM Dongsheng Yang
<dongsheng.yang@xxxxxxxxxxxx> wrote:
When we want to add some prefix to the bio data, such as journal header,
we don't want to copy it from bio into a new larger memory. Instead, we need
a prefix page and suffix page to store the header and footer in bio_iter.
Signed-off-by: Dongsheng Yang <dongsheng.yang@xxxxxxxxxxxx>
...
}
#endif /* CONFIG_BLOCK */
Have you looked at message data items (ceph_msg_data) for this?
A message can have multiple data items, each of different type (BIO,
PAGES, etc) and with its own iterator. The messenger will exhaust them
in order, so you can create a message with three data items: prefix
(type PAGES), data (type BIO), suffix (type PAGES).
Yes, that was my first idea, but I found the framework is not
enough to my case. And as I need to use bio only in my case,
What was the problem?
The problem is there is only one type of ceph_osd_data in
ceph_osd_req_op.extent.osd_data.
But what I want in journal append case is one ceph_osd_req_op (op
= CEPH_OSD_OP_APPEND), and extent of this ceph_osd_req_op have tree
ceph_osd_data (example: PAGES, BIO, PAGES).
I don't see a problem with adding two additional ceph_osd_data members
to extent with a comment explaining that rbd journaling needs a prefix
and a suffix. READ, WRITE, etc would still use just one, APPEND could
use all three when required.
Thanx for your suggestion.
Thanks,
Ilya
