public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 212183] st read statistics inaccurate when requested and physical block mismatch
Date: Thu, 11 Mar 2021 18:42:44 +0000	[thread overview]
Message-ID: <bug-212183-11613-dbRt4d1VIG@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-212183-11613@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=212183

--- Comment #1 from Kai Mäkisara (kai.makisara@kolumbus.fi) ---
> On 9. Mar 2021, at 16.34, bugzilla-daemon@bugzilla.kernel.org wrote:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=212183
> 
>            Bug ID: 212183
>           Summary: st read statistics inaccurate when requested and
>                    physical block mismatch
>           Product: IO/Storage
>           Version: 2.5
>    Kernel Version: 5.3.1
>          Hardware: All
>                OS: Linux
>              Tree: Mainline
>            Status: NEW
>          Severity: low
>          Priority: P1
>         Component: SCSI
>          Assignee: linux-scsi@vger.kernel.org
>          Reporter: etienne.mollier@cgg.com
>        Regression: No
> 
> Created attachment 295769
>  --> https://bugzilla.kernel.org/attachment.cgi?id=295769&action=edit
> st.c patch working around stats issue when blocks size mismatch
> 
> Greetings,
> 
> when reading from tape with requested blocks larger than physical, statistics
> go wrong as using the requested size for the calculation, instead of the
> actual

…

The code around your suggested patch looks like this:

                if (scsi_req(req)->result) {
                        atomic64_add(atomic_read(&STp->stats->last_read_size)
                                - STp->buffer->cmdstat.residual,
                                &STp->stats->read_byte_cnt);
                        if (STp->buffer->cmdstat.residual > 0)
                                atomic64_inc(&STp->stats->resid_cnt);
                } else
                        atomic64_add(atomic_read(&STp->stats->last_read_size),
                                &STp->stats->read_byte_cnt);

Your patch makes the else branch look like the first command in the
if branch. If the SILI option bit is not set, the command result should be
non-zero when the read block is shorter than the requested size. If the
SILI bit is set, this is not considered error and the else part is executed.
Your patch applies to this case?

If we trust that the residual (resid_len) is set correctly, the conditional
branches could be omitted and the residual could be subtracted always:
-----
-diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index 841ad2fc369a..4f1f2abfbca3 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -498,15 +498,11 @@ static void st_do_stats(struct scsi_tape *STp, struct
request *req)
                atomic64_add(ktime_to_ns(now), &STp->stats->tot_read_time);
                atomic64_add(ktime_to_ns(now), &STp->stats->tot_io_time);
                atomic64_inc(&STp->stats->read_cnt);
-               if (scsi_req(req)->result) {
-                       atomic64_add(atomic_read(&STp->stats->last_read_size)
-                               - STp->buffer->cmdstat.residual,
-                               &STp->stats->read_byte_cnt);
-                       if (STp->buffer->cmdstat.residual > 0)
-                               atomic64_inc(&STp->stats->resid_cnt);
-               } else
-                       atomic64_add(atomic_read(&STp->stats->last_read_size),
-                               &STp->stats->read_byte_cnt);
+               atomic64_add(atomic_read(&STp->stats->last_read_size)
+                            - STp->buffer->cmdstat.residual,
+                            &STp->stats->read_byte_cnt);
+               if (STp->buffer->cmdstat.residual > 0)
+                       atomic64_inc(&STp->stats->resid_cnt);
        } else {
                now = ktime_sub(now, STp->stats->other_time);
                atomic64_add(ktime_to_ns(now), &STp->stats->tot_io_time);
----

Opinions? (I don’t nowadays have access to any reasonable SCSI tape drive to
test
this.)

Thanks,
Kai

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

  parent reply	other threads:[~2021-03-11 18:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09 14:34 [Bug 212183] New: st read statistics inaccurate when requested and physical block mismatch bugzilla-daemon
2021-03-11 18:41 ` "Kai Mäkisara (Kolumbus)"
2021-03-11 18:42 ` bugzilla-daemon [this message]
2021-03-12 16:50 ` [Bug 212183] " bugzilla-daemon
2021-03-12 16:58 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-212183-11613-dbRt4d1VIG@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox