rbd: fix thread_offsets calculation of rbd bench

[hitoshikamei]

This patch fixes the way to calculate the thread_offset
vector for sequential I/O of rbd bench command.

The rbd bench command doesn't access whole image of rbd
in some cases, because the amount of accessed data is counted
up to the amount of total I/O.

For example, if options are set to below:

• rbd image size : 20M
• io-size : 4M
• io-total : 20M
• io-threads : 3
• io-type : write (sequential)

In this case, the data chunk is 5 (20MB / 4MB).
Fist, Thread 1 (T1) writes data to chunk 1. Thread 2 (T2)
writes data to chunk 2. Thread 3 (T3) writes data to
chunk 3. And, the amount of written data sums up to the "off"
value.

After that, the write position of each thread moves next
chunk, and threads overwrite data to the chunks. And,
the amount of overwritten data sums up to the "off" value.
Consequently, the off value reaches rbd image size, and
the rbd bench ends.

The rbd bench command doesn't write whole image, and 8 MB of
image is unwritten.

The processing image is described below:

            0   4   8  12  16   20 MB
            ---------------------
 chunks     | 1 | 2 | 3 | 4 | 5 |
            ---------------------
 1st loop    T1  T2  T3          -> 12 MB written (add to off value)
 2nd loop        T1  T2          ->  8 MB written (add to off value)
                                                 20 MB -> rbd bench END.

Hitoshi Kamei (1):
rbd: fix thread_offsets calculation of rbd bench

src/tools/rbd/action/Bench.cc | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)

--
2.15.1

[dillaman]

Nit: unassigned

[dillaman]

Nit: shouldn't this be something like thread_offset[i] = unit_len * i * io_size

[hitoshikamei]

Thank you for your comment. My explanation might be misleading, so I'll describe it more carefully with images.

Benchmark should not overwrite chunks because the write performance of allocated chunks is different from unallocated chunks. When an unallocated chunk is written, ceph allocates new rados object; meanwhile, when an allocated chunk is written, no need to allocate new rados object. So, the benchmark is affected by the overheads of the operation. Thus, the benchmark needs to avoid to overwrite chunks allocated by previous write.

These accesses are described below (assumption is same as PR message):

1. Current code: Overwrite just next chunk, chunk 4 and chunk 5 are not written
            0   4   8  12  16   20 MB
            ---------------------
 chunks     | 1 | 2 | 3 | 4 | 5 |
            ---------------------
 1st loop    T1  T2  T3          -> 12 MB written (add to off value)
 2nd loop        T1  T2          ->  8 MB written (add to off value)
                              Total 20 MB -> rbd bench END.

2. Your proposal code: Back to start position, chunk 4 and chunk 5 are not written
            0   4   8  12  16   20 MB
            ---------------------
 chunks     | 1 | 2 | 3 | 4 | 5 |
            ---------------------
 1st loop    T1  T2  T3          -> 12 MB written (add to off value)
 2nd loop    T1  T2              ->  8 MB written (add to off value)
                              Total 20 MB -> rbd bench END.

3. Proposed code: Write chunk 4 and chunk 5 in 2nd loop, all chunks are written
            0   4   8  12  16   20 MB
            ---------------------
 chunks     | 1 | 2 | 3 | 4 | 5 |
            ---------------------
 1st loop    T1  T2  T3          -> 12 MB written (add to off value)
 2nd loop                T1  T2  ->  8 MB written (add to off value)
                              Total 20 MB -> rbd bench END.

[dillaman]

@hitoshikamei That wasn't what I was proposing -- what I was proposing was to stop all threads restarting at offset zero after the image is written once.

[hitoshikamei]

I'm sorry. I misunderstood your comment. You referred to line 313, not 310.
I agree that the result of your proposed code is the same as current code.
So, I revised the patch according to your review comment.

[dillaman]

lgtm