From: Vivek Goyal <vgoyal@redhat.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
jaxboe@fusionio.com, James.Bottomley@hansenpartnership.com,
snitzer@redhat.com, michaelc@cs.wisc.edu,
linux-scsi@vger.kernel.org
Subject: Re: DISCARD/WRITE_SAME request accounting (Was: Re: [PATCH 2/7] block: Implement support for WRITE SAME)
Date: Fri, 9 Mar 2012 11:54:04 -0500 [thread overview]
Message-ID: <20120309165404.GA7746@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1203081138440.5987@dhcp-27-109.brq.redhat.com>
On Thu, Mar 08, 2012 at 11:48:53AM +0100, Lukas Czerner wrote:
[..]
> > > In my mind the only thing we can reliably measure is the I/O we're
> > > transmitting to or receiving from the device. So I'd personally like to
> > > see zero for discard and logical block size for write same.
> >
> > counting IO which is being transmitted/received from device makes
> > sense (Given the fact we don't know how much actual work device will
> > have to do). So counting 1 block for write same and zero block for discard
> > sounds reasonable to me.
> >
> > Looks like current code counts all the discard sectors towards number of
> > blocks written. So that will need to be changed. CCing Lukas, he might have
> > thoughts/opinion on discard request accounting.
>
> I am little surprised that we still count all the discard sectors
> towards the number of bock written. I have mentioned this problem to
> Jens last year.
>
> Anyway, it would be nice to have separate counter for discard requests
> and actually counting the discard sectors rather than just one for each
> discard bio. I know that the device can ignore the whole, or part of the
> request for its own reasons. But it is not a reason for not counting
> what we actually intended to discard. I think this statistic will be
> useful.
>
> Consider for example the situation where you find you that you're
> constantly discarding more than you actually write to the device over
> some period of time. The you would probably want to adjust your discard
> policy.
Yes, may be recording number of discards is not a bad idea. Currently
we record following for disk stats.
struct disk_stats {
unsigned long sectors[2]; /* READs and WRITEs */
unsigned long ios[2];
unsigned long merges[2];
unsigned long ticks[2];
unsigned long io_ticks;
unsigned long time_in_queue;
};
May be it can be extended to record number of discards completed and
user space tools (iostat) modified to extract this info.
But that seems to be a separate functionality. So we can drop counting
discard sectors towards write? Anyway, as of today you can't extract
this info how many writes you did and how many of these were discards.
So as such there is no regression in terms of features?
Thanks
Vivek
next prev parent reply other threads:[~2012-03-09 16:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 3:22 Write same support v3 Martin K. Petersen
2012-03-02 3:22 ` [PATCH 1/7] block: Clean up merge logic Martin K. Petersen
2012-03-02 20:21 ` Vivek Goyal
2012-03-06 17:42 ` Martin K. Petersen
2012-03-07 16:52 ` Vivek Goyal
2012-03-08 4:41 ` Martin K. Petersen
2012-03-02 21:36 ` Vivek Goyal
2012-03-06 17:43 ` Martin K. Petersen
2012-03-02 3:22 ` [PATCH 2/7] block: Implement support for WRITE SAME Martin K. Petersen
2012-03-02 22:08 ` Vivek Goyal
2012-03-06 17:54 ` Martin K. Petersen
2012-03-07 17:03 ` DISCARD/WRITE_SAME request accounting (Was: Re: [PATCH 2/7] block: Implement support for WRITE SAME) Vivek Goyal
2012-03-08 10:48 ` Lukas Czerner
2012-03-09 16:54 ` Vivek Goyal [this message]
2012-03-02 3:22 ` [PATCH 3/7] block: Make blkdev_issue_zeroout use WRITE SAME Martin K. Petersen
2012-03-09 18:05 ` Paolo Bonzini
2012-03-13 2:30 ` Martin K. Petersen
2012-03-02 3:22 ` [PATCH 4/7] block: ioctl to zero block ranges Martin K. Petersen
2012-03-02 3:22 ` [PATCH 5/7] scsi: Add a report opcode helper Martin K. Petersen
2012-03-02 4:08 ` Jeff Garzik
2012-03-02 3:22 ` [PATCH 6/7] sd: Implement support for WRITE SAME Martin K. Petersen
2012-03-05 15:07 ` Vivek Goyal
2012-03-06 17:58 ` Martin K. Petersen
2012-03-02 3:22 ` [PATCH 7/7] sd: Use sd_ prefix for flush and discard functions Martin K. Petersen
2012-03-02 14:24 ` [PATCH] dm kcopyd: add WRITE SAME support to dm_kcopyd_zero Mike Snitzer
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=20120309165404.GA7746@redhat.com \
--to=vgoyal@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=jaxboe@fusionio.com \
--cc=lczerner@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michaelc@cs.wisc.edu \
--cc=snitzer@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).