rbd: explicitly support only one osd op
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest4 patches 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | rbd: pass num_op with ops arraydrivers/ | +1 | 0 replies | |
| 2/4 | libceph: pass num_op with opsdrivers/ include/ net/ | +5 | 0 replies | |
| 3/4 | rbd: there is really only one opdrivers/ | +1 | 0 replies | |
| 4/4 | rbd: assume single op in a requestdrivers/ | +4 | 0 replies |
Reviews trailers per patch
None of the 4 patches has a Reviewed-by or Acked-by of their own; the series has one for all of them.
| Patch | Josh Durgin |
|---|---|
| Series | R-b |
| 1/4 | |
| 2/4 | |
| 3/4 | |
| 4/4 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH REPOST 0/4] rbd: explicitly support only one osd op
An osd request can be made up of multiple "ops", all of which are completed (or not) transactionally. There is partial support for multiple ops in an rbd request in the rbd code, but it's incomplete and not even supported by the osd client or the messenger right now.
I see three problems with this partial implementation: it gives a false impression of how things work; it complicates some code in some cases where it's not necessary; and it may constrain how one might pursue fully implementing multiple ops in a request to ways that don't fit well with how we want to do things.
So this series just simplifies things, making it explicit that there is only one op in an kernel osd client request right now.
-Alex
[PATCH REPOST 1/4] rbd: pass num_op with ops array [PATCH REPOST 2/4] libceph: pass num_op with ops [PATCH REPOST 3/4] rbd: there is really only one op [PATCH REPOST 4/4] rbd: assume single op in a request