All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Andy Isaacson <adi@hexapodia.org>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [DOC PATCH] block/stat.txt
Date: Mon, 12 Dec 2005 13:45:53 +0100	[thread overview]
Message-ID: <20051212124553.GW26185@suse.de> (raw)
In-Reply-To: <20051211010339.GA26568@hexapodia.org>

On Sat, Dec 10 2005, Andy Isaacson wrote:
> I couldn't find any docs explaining the contents of
> /sys/block/<dev>/stat, so I wrote up the following.  I'm not completely
> sure it's accurate - Jens, could you give a yea or nay on this?
> 
> In particular, the counts of read/write IOs and read/write sectors are
> incremented in different places - it looks like they both increment as
> the request is being finished, but I'm not completely sure of that.

Overall it looks very nice, you basically all of it right. And thanks
for doing it btw, it's a good addition to the documentation. A few small
comments follows:


> +Name            units         description
> +----            -----         -----------
> +read I/Os       requests      number of read I/Os processed
> +read merges     requests      number of read I/Os merged with in-queue I/O
> +read sectors    blocks        number of sectors read

The unit here should just read 'sectors', blocks usually refers to a
file system block.

> +read I/Os, write I/Os
> +=====================
> +
> +These values increment when an I/O request completes.
> +
> +read merges, write merges
> +=========================
> +
> +These values increment when an I/O request is merged with an
> +already-queued I/O request.

Both correct, good!

> +read sectors, write sectors
> +===========================
> +
> +These values count the number of blocks read from or written to this
> +block device.  The "blocks" in question are the standard UNIX 512-byte
> +blocks, not any device-specific block size.  The counters are
> +incremented when the I/O completes.

These standard 512-b blocks we just call sectors in Linux.

> +in_flight
> +=========
> +
> +This value counts the number of currently-queued I/O requests.

A little confusing - it's the number of in flight io at the
driver/device end, that is after the block layer. One could read the
above as total in flight (total queued in the queue for the device),
which is a very different number.

-- 
Jens Axboe


  reply	other threads:[~2005-12-12 12:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-11  1:03 [DOC PATCH] block/stat.txt Andy Isaacson
2005-12-12 12:45 ` Jens Axboe [this message]
2005-12-13  8:41   ` Andy Isaacson
2005-12-13 18:38     ` Jens Axboe

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=20051212124553.GW26185@suse.de \
    --to=axboe@suse.de \
    --cc=adi@hexapodia.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.