On Thu, 2023-08-10 at 08:42 +0200, Paul Menzel wrote:

Dear David,


Thank you for your patch.

Am 09.08.23 um 19:16 schrieb David Jeffery:

quoted

When a bio is split by md raid0, the newly created bio will not be
tracked
by md for I/O accounting. Only the portion of I/O still assigned to
the
original bio which was reduced by the split will be accounted for.
This
results in md iostat data sometimes showing I/O values far below
the actual
amount of data being sent through md.

md_account_bio() needs to be called for all bio generated by the
bio split.

Could you please add how you tested this?

quoted

Signed-off-by: David Jeffery <redacted>
Tested-by: Laurence Oberman <redacted>
---
  drivers/md/raid0.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index d1ac73fcd852..1fd559ac8c68 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c

@@ -597,8 +597,7 @@ static bool raid0_make_request(struct mddev

*mddev, struct bio *bio)
                bio = split;
        }
  
-       if (bio->bi_pool != &mddev->bio_set)
-               md_account_bio(mddev, &bio);
+       md_account_bio(mddev, &bio);
  
        orig_sector = sector;
        zone = find_zone(mddev->private, &sector);

Kind regards,

Paul

Hello

This was actually reported by a customer on RHEL9.2 and the way this
played out is they were reading the md raid device directly using dd
buffered reads.
The md raid serves an LVM volume and file system.

Using dd if=/dev/md0 of=/dev/null bs=1024K count=10000 you would
sporadically see iostat report these numbers where the raid md0 shows
invalid stats. 

     tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn Device
   221.00       111.0M         0.0k     111.0M       0.0k dm-12
   222.00       110.0M         0.0k     110.0M       0.0k dm-15
   223.00       111.0M         0.0k     111.0M       0.0k dm-16
   220.00       109.0M         0.0k     109.0M       0.0k dm-17
   221.00       111.0M         0.0k     111.0M       0.0k dm-18
   221.00       111.0M         0.0k     111.0M       0.0k dm-19
   219.00       109.0M         0.0k     109.0M       0.0k dm-20
   219.00       110.0M         0.0k     110.0M       0.0k dm-22
   880.00         6.9M         0.0k       6.9M       0.0k md0
                ******

After patching with David's patch the issue is no longer reproducible.
We tested using the same method that reproduced the issue reported by
the customer.

Thanks
Laurence