From: Bart Van Assche <bart.vanassche@sandisk.com>
To: lsf-pc@lists.linux-foundation.org
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: [LSF/MM TOPIC] Improving DISCARD support
Date: Wed, 27 Jan 2016 09:48:47 -0800 [thread overview]
Message-ID: <56A902FF.8050102@sandisk.com> (raw)
Increasing the discard granularity of an SSD helps with reducing the
production cost of an SSD. This makes it likely that in the future even
more SSDs will have a discard granularity that is larger than the block
size than today. Kernel drivers like DRBD and OCFS2 need a way to
efficiently erase a data range. This is why the function
blkdev_issue_zeroout() has been introduced in the block layer. This
function uses the DISCARD operation for those devices for which
discarded ranges read back as zero (discard_zeroes_data == 1). However,
support in the block layer for devices with a discard granularity that
is larger than the block size is suboptimal. Callers of
blkdev_issue_zeroout() namely have to ensure that the start and end of
the range that has to be zeroed are aligned with discard boundaries.
This forces driver writers to write wrapper functions that work around
this limitation. An example can be found in [1]. My proposal is to
provide such functionality in the block layer instead of forcing every
driver author to reimplement this functionality. A candidate
implementation is available in [2].
[1] Lars Ellenberg, drbd: when receiving P_TRIM, zero-out partial
unaligned chunks, October 2015
(http://git.drbd.org/drbd-8.4.git/commitdiff/5204727f9dfa695fc57915c4edeb2a9f186e5fba).
[2] Bart Van Assche, Make blkdev_issue_discard() submit aligned discard
requests, December 2015
(http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/23801).
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <bart.vanassche@sandisk.com>
To: <lsf-pc@lists.linux-foundation.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: [LSF/MM TOPIC] Improving DISCARD support
Date: Wed, 27 Jan 2016 09:48:47 -0800 [thread overview]
Message-ID: <56A902FF.8050102@sandisk.com> (raw)
Increasing the discard granularity of an SSD helps with reducing the
production cost of an SSD. This makes it likely that in the future even
more SSDs will have a discard granularity that is larger than the block
size than today. Kernel drivers like DRBD and OCFS2 need a way to
efficiently erase a data range. This is why the function
blkdev_issue_zeroout() has been introduced in the block layer. This
function uses the DISCARD operation for those devices for which
discarded ranges read back as zero (discard_zeroes_data == 1). However,
support in the block layer for devices with a discard granularity that
is larger than the block size is suboptimal. Callers of
blkdev_issue_zeroout() namely have to ensure that the start and end of
the range that has to be zeroed are aligned with discard boundaries.
This forces driver writers to write wrapper functions that work around
this limitation. An example can be found in [1]. My proposal is to
provide such functionality in the block layer instead of forcing every
driver author to reimplement this functionality. A candidate
implementation is available in [2].
[1] Lars Ellenberg, drbd: when receiving P_TRIM, zero-out partial
unaligned chunks, October 2015
(http://git.drbd.org/drbd-8.4.git/commitdiff/5204727f9dfa695fc57915c4edeb2a9f186e5fba).
[2] Bart Van Assche, Make blkdev_issue_discard() submit aligned discard
requests, December 2015
(http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/23801).
next reply other threads:[~2016-01-27 17:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 17:48 Bart Van Assche [this message]
2016-01-27 17:48 ` [LSF/MM TOPIC] Improving DISCARD support Bart Van Assche
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=56A902FF.8050102@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.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.