CEPH filesystem development
 help / color / mirror / Atom feed
From: Alex Elder <elder@inktank.com>
To: Josh Durgin <josh.durgin@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: [PATCH 3/3] rbd: consolidate rbd_do_op() calls
Date: Fri, 26 Oct 2012 16:58:35 -0500	[thread overview]
Message-ID: <508B078B.9010808@inktank.com> (raw)
In-Reply-To: <5088260B.7030308@inktank.com>

On 10/24/2012 12:31 PM, Josh Durgin wrote:
> This cleanup makes sense. We should probably check
> the return code now as well, as I note below.
> 
> Reviewed-by: Josh Durgin <josh.durgin@inktank.com>

I'm going to do this as a followup patch, next week.

					-Alex

> 
> On 10/10/2012 07:19 PM, Alex Elder wrote:
>> The two calls to rbd_do_op() from rbd_rq_fn() differ only in the
>> value passed for the snapshot id and the snapshot context.
>>
>> For reads the snapshot always comes from the mapping, and for writes
>> the snapshot id is always CEPH_NOSNAP.
>>
>> The snapshot context is always null for reads.  For writes, the
>> snapshot context always comes from the rbd header, but it is
>> acquired under protection of header semaphore and could change
>> thereafter, so we can't simply use what's available inside
>> rbd_do_op().
>>
>> Eliminate the snapid parameter from rbd_do_op(), and set it
>> based on the I/O direction inside that function instead.  Always
>> pass the snapshot context acquired in the caller, but reset it
>> to a null pointer inside rbd_do_op() if the operation is a read.
>>
>> As a result, there is no difference in the read and write calls
>> to rbd_do_op() made in rbd_rq_fn(), so just call it unconditionally.
>>
>> Signed-off-by: Alex Elder <elder@inktank.com>
>> ---
>>   drivers/block/rbd.c |   26 +++++++++-----------------
>>   1 file changed, 9 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
>> index 396af14..ca28036 100644
>> --- a/drivers/block/rbd.c
>> +++ b/drivers/block/rbd.c
>> @@ -1163,7 +1163,6 @@ done:
>>   static int rbd_do_op(struct request *rq,
>>                struct rbd_device *rbd_dev,
>>                struct ceph_snap_context *snapc,
>> -             u64 snapid,
>>                u64 ofs, u64 len,
>>                struct bio *bio,
>>                struct rbd_req_coll *coll,
>> @@ -1177,6 +1176,7 @@ static int rbd_do_op(struct request *rq,
>>       u32 payload_len;
>>       int opcode;
>>       int flags;
>> +    u64 snapid;
>>
>>       seg_name = rbd_segment_name(rbd_dev, ofs);
>>       if (!seg_name)
>> @@ -1187,10 +1187,13 @@ static int rbd_do_op(struct request *rq,
>>       if (rq_data_dir(rq) == WRITE) {
>>           opcode = CEPH_OSD_OP_WRITE;
>>           flags = CEPH_OSD_FLAG_WRITE|CEPH_OSD_FLAG_ONDISK;
>> +        snapid = CEPH_NOSNAP;
>>           payload_len = seg_len;
>>       } else {
>>           opcode = CEPH_OSD_OP_READ;
>>           flags = CEPH_OSD_FLAG_READ;
>> +        snapc = NULL;
>> +        snapid = rbd_dev->mapping.snap_id;
>>           payload_len = 0;
>>       }
>>
>> @@ -1518,24 +1521,13 @@ static void rbd_rq_fn(struct request_queue *q)
>>               kref_get(&coll->kref);
>>               bio = bio_chain_clone(&rq_bio, &next_bio, &bp,
>>                             op_size, GFP_ATOMIC);
>> -            if (!bio) {
>> +            if (bio)
>> +                (void) rbd_do_op(rq, rbd_dev, snapc,
>> +                        ofs, op_size,
>> +                        bio, coll, cur_seg);
> 
> We could check the error code here pretty easily now.
> 
>> +            else
>>                   rbd_coll_end_req_index(rq, coll, cur_seg,
>>                                  -ENOMEM, op_size);
>> -                goto next_seg;
>> -            }
>> -
>> -            /* init OSD command: write or read */
>> -            if (do_write)
>> -                (void) rbd_do_op(rq, rbd_dev,
>> -                        snapc, CEPH_NOSNAP,
>> -                        ofs, op_size, bio,
>> -                        coll, cur_seg);
>> -            else
>> -                (void) rbd_do_op(rq, rbd_dev,
>> -                        NULL, rbd_dev->mapping.snap_id,
>> -                        ofs, op_size, bio,
>> -                        coll, cur_seg);
>> -next_seg:
>>               size -= op_size;
>>               ofs += op_size;
>>
> 


      reply	other threads:[~2012-10-26 21:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-11  2:17 [PATCH 0/3] rbd: simplify rbd_do_op() et al Alex Elder
2012-10-11  2:19 ` [PATCH 1/3] rbd: kill rbd_req_{read,write}() Alex Elder
2012-10-24 17:24   ` Josh Durgin
2012-10-11  2:19 ` [PATCH 2/3] rbd: kill drop rbd_do_op() opcode and flags Alex Elder
2012-10-24 17:26   ` Josh Durgin
2012-10-11  2:19 ` [PATCH 3/3] rbd: consolidate rbd_do_op() calls Alex Elder
2012-10-24 17:31   ` Josh Durgin
2012-10-26 21:58     ` Alex Elder [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=508B078B.9010808@inktank.com \
    --to=elder@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=josh.durgin@inktank.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox