From: Christoph Hellwig <hch@infradead.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, liml@rtr.ca, jens.axboe@oracle.com,
dwmw2@infradead.org
Subject: Re: [PATCH 0/7] discard support revisited
Date: Sat, 29 Aug 2009 22:15:34 -0400 [thread overview]
Message-ID: <20090830021534.GA14706@infradead.org> (raw)
In-Reply-To: <20090829233718.GD22870@parisc-linux.org>
On Sat, Aug 29, 2009 at 05:37:19PM -0600, Matthew Wilcox wrote:
> > - I have implemented support for sending WRITE SAME requests with the
> > unmap bit set in sd. This has been tested with a qemu-based backed
> > only so far, but we'll get some real array coverage soon.
>
> I think we're going to need to figure out whether we should be sending
> UNMAP or WRITE SAME ... probably need to dive back into the T10 poostorm
> to see what's going on.
Good question. Latest I had heard was that at least one array vendor
prefers the WRITE SAME. To me it looks like the much saner interface
for the OS, so unless there are arrays that strongly prefer UNMAP or
we need to make use of the multiple extends feature in it I'd go with
WRITE SAME as first choice.
> > I would really love to see some progress on this in the 2.6.32 circle.
> > We should at least get the block layer bits in that allow implementing
> > a somewhat useful discard function. I would also love to see the
> > actual scsi and libata implementations in so that we can start playing
> > around with it. But given the speed up the current TRIM implementations
> > and the expectations for WRITE SAME we should make sure the exact
> > TRIM tracking is not actually enabled anywhere by default for now.
>
> Jens had some objections to the block layer bits last time I posted
> these. I forget what they were now (this would have been around May
> 2nd, I think). What I've done instead in my current patchset (which
> undoubtedly has bugs because it isn't tested, because I'm not supposed
> to be working on the weekends) is to make sd_prep_fn() call a new method
> in the scsi_host_template. That should translate the discard request
> into a BLOCK_PC ATA_16 command, and we'll all be happy.
>
> It goes a little something like this:
> http://git.kernel.org/?p=linux/kernel/git/willy/ssd.git;a=shortlog;h=trim-20090829
>
> Right now, the test tool is telling me 'Operation not supported', and
> I haven't tried to figure out why yet.
Queue flag and handling the discard in the prep function is much better
than the prepare function, yes. I don't like the prep_fn callout to the
host a lot. If we go with WRITE SAME as prefered discard option for
scsi translating it to TRIM should be relatively easy, it uses the same
LBA/length encoding as the regular WRITE_16, except that the payload is
just a single sector. That should be not too hard to implement in the
SAT layer.
next prev parent reply other threads:[~2009-08-30 2:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-29 23:03 [PATCH 0/7] discard support revisited Christoph Hellwig
2009-08-29 23:03 ` [PATCH 1/7] Make DISCARD_BARRIER and DISCARD_NOBARRIER writes instead of reads Christoph Hellwig
2009-09-03 17:52 ` David Woodhouse
2009-09-03 17:56 ` Matthew Wilcox
2009-08-29 23:03 ` [PATCH 2/7] block: use blkdev_issue_discard in blk_ioctl_discard Christoph Hellwig
2009-09-01 9:06 ` Steven Whitehouse
2009-09-11 22:26 ` Christoph Hellwig
2009-09-14 9:40 ` Jens Axboe
2009-08-29 23:03 ` [PATCH 3/7] block: discard may need to allocate pages Christoph Hellwig
2009-08-29 23:03 ` [PATCH 4/7] sd: add support for WRITE SAME (16) with unmap bit Christoph Hellwig
2009-08-30 0:43 ` Douglas Gilbert
2009-08-30 1:05 ` Christoph Hellwig
2009-08-30 2:43 ` Douglas Gilbert
2009-08-30 2:48 ` Christoph Hellwig
2009-08-30 11:12 ` Sergei Shtylyov
2009-08-30 17:14 ` Christoph Hellwig
2009-08-29 23:03 ` [PATCH 5/7] libata: Add support for TRIM Christoph Hellwig
2009-08-29 23:03 ` [PATCH 6/7] block: allow large discard requests Christoph Hellwig
2009-08-30 2:49 ` Mark Lord
2009-08-30 2:50 ` Matthew Wilcox
2009-08-30 2:52 ` Mark Lord
2009-08-30 2:56 ` Christoph Hellwig
2009-08-29 23:03 ` [PATCH 7/7] xfs: add batches discard support Christoph Hellwig
2009-08-29 23:37 ` [PATCH 0/7] discard support revisited Matthew Wilcox
2009-08-30 2:15 ` Christoph Hellwig [this message]
2009-08-30 3:03 ` Matthew Wilcox
2009-08-30 20:17 ` James Bottomley
2009-08-30 21:42 ` Matthew Wilcox
2009-08-30 22:48 ` Christoph Hellwig
2009-09-02 19:46 ` Matthew Wilcox
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=20090830021534.GA14706@infradead.org \
--to=hch@infradead.org \
--cc=dwmw2@infradead.org \
--cc=jens.axboe@oracle.com \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).