btrfs_end_bio() is using btrfs_dev_stat_inc() and then
btrfs_dev_stat_print_on_error() separately instead
use btrfs_dev_stat_inc_and_print() directly.

No need to worry about print lines one for read/write
and another if the source of IO request is flush, since
as mentioned in this patch
 [patch] btrfs: REQ_PREFLUSH does not use btrfs_end_bio() completion callback
there isn't any IO which is doing that.

This consolidation is a preparatory patch to add device
critical error handling in btrfs_dev_stat_inc_and_print()
and can be renamed as needed.

Signed-off-by: Anand Jain <anand.j...@oracle.com>
---
 fs/btrfs/volumes.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index efaf85dd91b0..d1d8aa226bff 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6004,15 +6004,14 @@ static void btrfs_end_bio(struct bio *bio)
                        dev = bbio->stripes[stripe_index].dev;
                        if (dev->bdev) {
                                if (bio_op(bio) == REQ_OP_WRITE)
-                                       btrfs_dev_stat_inc(dev,
+                                       btrfs_dev_stat_inc_and_print(dev,
                                                BTRFS_DEV_STAT_WRITE_ERRS);
                                else
-                                       btrfs_dev_stat_inc(dev,
+                                       btrfs_dev_stat_inc_and_print(dev,
                                                BTRFS_DEV_STAT_READ_ERRS);
                                if (bio->bi_opf & REQ_PREFLUSH)
-                                       btrfs_dev_stat_inc(dev,
+                                       btrfs_dev_stat_inc_and_print(dev,
                                                BTRFS_DEV_STAT_FLUSH_ERRS);
-                               btrfs_dev_stat_print_on_error(dev);
                        }
                }
        }
-- 
2.13.1

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to