From: Alex Elder <elder@inktank.com>
To: ceph-devel@vger.kernel.org
Subject: [PATCH 0/7] rbd: isolate mapping info, rearrange init
Date: Fri, 07 Sep 2012 08:40:33 -0500 [thread overview]
Message-ID: <5049F951.2030706@inktank.com> (raw)
This third series begins a little more interesting code
restructuring. The first five patches make more clear
the distinction in a struct rbd_device between information
about the underlying rbd image and information about the
mapped snapshot represented by the structure.
The last two patches (which might arguably belong in a
later sub-series) move some initialization code out of
one function and into its caller.
It is available as branch "wip-rbd-review-3" on the ceph-client git
repository, and is based on the branch "wip-rbd-review-2".
https://github.com/ceph/ceph-client/tree/wip-rbd-review-3
-Alex
[PATCH 1/7] f4069bf rbd: separate mapping info in rbd_dev
This groups some related fields of an rbd device structure into
a sub-structure. The fields pertain to the specific mapping
an rbd_device represents--as opposed to the base rbd image.
[PATCH 2/7] bee627f rbd: record mapped size
This adds the size of the image or snapshot that's mapped to an
rbd device's mapping information.
[PATCH 3/7] 8b45382 rbd: return snap name from rbd_add_parse_args()
[PATCH 4/7] cb93cc4 rbd: set mapping name with the rest
These two patches make the name of the mapped snapshot be set
along with the other mapping-related fields.
[PATCH 5/7] 8a245ce rbd: simplify snap_by_name() interface
This does some refactoring enabled by the previous few patches.
[PATCH 6/7] e4008bd rbd: do some header initialization earlier
This rearranges where certain initialization is done, beginning
the process of re-ordering some of these steps in order to allow
both format 1 and format 2 rbd images to be handled in the same way.
[PATCH 7/7] 275ba12 rbd: simplify rbd_init_disk() a bit
This does some refactoring enabled by the previous patch.
next reply other threads:[~2012-09-07 13:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 13:40 Alex Elder [this message]
2012-09-07 13:45 ` [PATCH 1/7] rbd: separate mapping info in rbd_dev Alex Elder
2012-09-07 18:58 ` Josh Durgin
2012-09-07 21:51 ` Alex Elder
2012-09-07 13:45 ` [PATCH 2/7] rbd: record mapped size Alex Elder
2012-09-07 19:10 ` Josh Durgin
2012-09-07 21:52 ` Alex Elder
2012-09-07 13:45 ` [PATCH 3/7] rbd: return snap name from rbd_add_parse_args() Alex Elder
2012-09-07 19:32 ` Josh Durgin
2012-09-07 13:45 ` [PATCH 4/7] rbd: set mapping name with the rest Alex Elder
2012-09-07 19:39 ` Josh Durgin
2012-09-07 13:45 ` [PATCH 5/7] rbd: simplify snap_by_name() interface Alex Elder
2012-09-07 19:41 ` Josh Durgin
2012-09-07 13:46 ` [PATCH 6/7] rbd: do some header initialization earlier Alex Elder
2012-09-07 20:32 ` Josh Durgin
2012-09-07 13:46 ` [PATCH 7/7] rbd: simplify rbd_init_disk() a bit Alex Elder
2012-09-07 20:32 ` Josh Durgin
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=5049F951.2030706@inktank.com \
--to=elder@inktank.com \
--cc=ceph-devel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.