All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: splice read byte accounting
Date: Thu, 28 Jan 2010 10:15:34 -0500	[thread overview]
Message-ID: <1264691734.7553.1.camel@localhost> (raw)
In-Reply-To: <EAD3EA8D-52B9-43D4-8A35-B623270AF688@oracle.com>

On Thu, 2010-01-28 at 10:07 -0500, Chuck Lever wrote: 
> On Jan 27, 2010, at 6:19 PM, Trond Myklebust wrote:
> > On Wed, 2010-01-27 at 17:22 -0500, Chuck Lever wrote:
> >> Hi-
> >>
> >> nfs_file_splice_write() accounts for the bytes in the request in the
> >> "normal bytes written" counter, but nfs_file_splice_read() does not
> >> account for bytes read.
> >>
> >> Should the read path count these as normal bytes as well, or should
> >> the write path not account for these bytes?
> >>
> >
> > nfs_file_splice_read() should probably update NFSIOS_NORMALREADBYTES.
> >
> > That said, why do nfs_file_read(), nfs_file_write() and
> > nfs_file_splice_write() update the stats with the requested number of
> > bytes, irrespective of the number of bytes that were actually
> > read/write?
> 
> We're counting the number of bytes requested by applications.  I'm not  
> sure which is more useful here; number of bytes requested, or number  
> of bytes actually read/written.  For computing ratios of app bytes v.  
> otw bytes, I suppose the latter?
> 

Yes. Most apps will just be inputting the buffer size as the 'number of
bytes requested', which is not really a particularly useful number.



  reply	other threads:[~2010-01-28 15:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-27 22:22 splice read byte accounting Chuck Lever
2010-01-27 23:19 ` Trond Myklebust
2010-01-28 15:07   ` Chuck Lever
2010-01-28 15:15     ` Trond Myklebust [this message]
2010-01-28 16:07       ` Chuck Lever
2010-01-28 15:16     ` Suresh Jayaraman

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=1264691734.7553.1.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@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.