rbd: no need for file mapping calculation
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | rbd: pull in ceph_calc_raw_layout()drivers/ | +0 | 0 replies | |
| 2/3 | rbd: open code rbd_calc_raw_layout()drivers/ | +0 | 0 replies | |
| 3/3 | rbd: don't bother calculating file mappingdrivers/ | +4 | 0 replies |
Reviews trailers per patch
None of the 3 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/3 | |
| 2/3 | |
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH REPOST 0/3] rbd: no need for file mapping calculation
Currently every osd request submitted by the rbd code undergoes a file mapping operation, which is common with what the ceph file system uses. But some analysis shows that there is no need to do this for rbd, because it already takes care of its own blocking of image data into distinct objects. Removing this simplifies things. I especially think removing this improves things conceptually, removing a complex mapping operation from the I/O path.
-Alex
[PATCH REPOST 1/3] rbd: pull in ceph_calc_raw_layout() [PATCH REPOST 2/3] rbd: open code rbd_calc_raw_layout() [PATCH REPOST 3/3] rbd: don't bother calculating file mapping