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.
Thanks,
Ilya
