From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-scsi@vger.kernel.org, axboe@kernel.dk, matthew@wil.cx
Subject: Re: [PATCH 1/2] block: add support for discard limits
Date: Thu, 29 Oct 2009 23:19:43 -0400 [thread overview]
Message-ID: <yq1ws2dsh4g.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20091029151127.257902381@bombadil.infradead.org> (Christoph Hellwig's message of "Thu, 29 Oct 2009 11:08:31 -0400")
>>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> writes:
Christoph> To properly support discard on SCSI Arrays we need to take
Christoph> the discard granularity and the first aligned discard LBA
Christoph> into account. This patch adds block limits for both of them,
Christoph> and trims down dicard requests to fit into these limits in
Christoph> blkdev_issue_discard. We also make sure the alignment offset
Christoph> is properly adjust for partitions and add sysfs files to
Christoph> expose the limits to userspaced.
Do we know for sure that this is really needed?
The reason I'm asking is that in my first attempt I also exposed all
this up the stack. However, it sucks to keep this in sync and would
require the same level of topology stacking magic as the rest of the
queue limits. My brain melted at the thought of LVM/MD volumes striped
or mirrored between devices with different unmap granularity and
alignment.
So I talked to a variety of array folks. And regardless of whether they
implement WRITE SAME or UNMAP they all appear to handle misaligned
requests just fine. I.e. there may be some mapped residue at the
beginning and end of an unmap request but any full allocation units in
between will be correctly unmapped. They all told me the alignment and
granularity parameters were purely informational and intended as hints
for laying out data. Not as hard limits for issuing I/O.
Consequently I gutted all the alignment stuff from my thin provisioning
tree. I also changed mt scsi_debug code to unmap allocations similar to
the way the arrays work (my first attempt completely ignored misaligned
requests).
ACS-2 doesn't currently have a notion of unmap granularity and all array
vendors I have talked to appear to happily process any unmap request we
throw at them. So I'm leaning towards keeping things simple and just
sending things down verbatim...
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2009-10-30 3:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 15:08 [PATCH 0/2] scsi discard support Christoph Hellwig
2009-10-29 15:08 ` [PATCH 1/2] block: add support for discard limits Christoph Hellwig
2009-10-29 19:06 ` Jens Axboe
2009-10-30 5:03 ` Christoph Hellwig
2009-11-02 12:39 ` Jens Axboe
2009-10-30 3:19 ` Martin K. Petersen [this message]
2009-10-30 5:05 ` Christoph Hellwig
2009-11-02 13:29 ` Martin K. Petersen
2009-11-02 15:39 ` James Bottomley
2009-11-02 18:16 ` Martin K. Petersen
2009-11-02 16:02 ` Boaz Harrosh
2009-11-02 18:18 ` Martin K. Petersen
2009-11-03 15:16 ` Christoph Hellwig
2009-10-29 15:08 ` [PATCH 2/2] sd: add support for WRITE SAME (16) with unmap bit Christoph Hellwig
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=yq1ws2dsh4g.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
/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