linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
	Tejun Heo <tj@kernel.org>, Jeff Garzik <jeff@garzik.org>
Subject: Re: Getting TRIM working
Date: Sun, 8 Mar 2009 10:54:47 -0600	[thread overview]
Message-ID: <20090308165447.GN25995@parisc-linux.org> (raw)
In-Reply-To: <49B39DCB.3040203@panasas.com>

On Sun, Mar 08, 2009 at 12:28:27PM +0200, Boaz Harrosh wrote:
> That's because you are doing it at the wrong level at the wrong stage.
> 1. block-level submits a request
> 2. sd/sr or what ever ULD prepares a scsi_cmnd out of request.
>    Request's sizes are only a recommendation. ULD or scsi-ml may
>    prepare a smaller command then request. Once command is prepared
>    request is disregarded, you can bang on it all you want code will
>    not care about it one bit.

I may well be changing more than I need to, but it would be foolish of
me to make the assumption at this point that nothing is looking at the
request.

> 3. LLD executes the scsi-command (Not the block-request)

This is true, *but* some of the lengths in the block request still end
up getting used, for example bv_len is used by blk_rq_map_sg() which is
called by the LLD.

> 4. scsi-ml completes command's bytes, at this stage the request might
>    not be over and, and a reminder is re-prepared so the request can
>    be complete.
> 
> The code above scmd->sdb.length = req->data_len = size; is not allowed
> and can cause data leaks.

Simply not true.  We are *changing the amount of data we wish to
transfer*.  SCSI would have sent down 24 bytes of data.  ATA needs to
send down 512 bytes of data.

> You should ping Tejun, block-layer(1) and ATA-LLD(3) has a way to communicate
> alignments and drain buffers that expose some other possible lenght's to ata.
> 
> And to your question the missing length above is probably encoded inside the
> submitted CDB. (scsi_cmnd->cmnd). When you change the length before
> stage (2) it works.

No, that's not it.  This works (in sd.c):

        if (bio_add_pc_page(q, bio, page, 512, 0) < 512) {
[...]
        rq->cmd_type = REQ_TYPE_BLOCK_PC;
	rq->cmd_len = 10;
	rq->cmd[0] = UNMAP;
	put_unaligned_be16(24, rq->cmd + 7);

So the 24 in the cmd gets ignored.

> I think you should be using the drain mechanisms built into ata 

drain seems only applicable to ATAPI, not to ATA.  The comment says:

 *      ATAPI commands which transfer variable length data to host
 *      might overflow due to application error or hardare bug.  This
 *      function checks whether overflow should be drained and ignored
 *      for @request.

This isn't the case with discard/UNMAP/TRIM.  We know exactly how much
data we want to send.  The problem is that I don't know how to update all
the required places to change the amount of data being sent.  I don't
see any other ATA command which needs to do this, so this is breaking
new ground for libata-scsi.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2009-03-08 16:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-03 19:07 Getting TRIM working Matthew Wilcox
2009-03-04  9:20 ` Boaz Harrosh
2009-03-06 19:16   ` Matthew Wilcox
2009-03-08 10:28     ` Boaz Harrosh
2009-03-08 16:54       ` Matthew Wilcox [this message]
2009-03-08 17:38         ` Boaz Harrosh
2009-03-08 21:24       ` James Bottomley
2009-03-08 21:32         ` James Bottomley
2009-03-09  8:36           ` Matthew Wilcox
2009-03-09 13:52             ` Douglas Gilbert
2009-03-09 14:03               ` INCITS Matthew Wilcox
2009-03-09 14:08               ` Getting TRIM working James Bottomley
2009-03-09 14:04             ` James Bottomley
2009-03-09 14:14               ` Matthew Wilcox
2009-03-09 15:17                 ` 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=20090308165447.GN25995@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=bharrosh@panasas.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tj@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 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).