linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Mike Christie <michaelc@cs.wisc.edu>,
	Hannes Reinecke <hare@suse.de>,
	James Bottomley <James.Bottomley@suse.de>,
	Boaz Harrosh <bharrosh@panasas.com>, Jens Axboe <axboe@kernel.dk>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Douglas Gilbert <dgilbert@interlog.com>,
	Richard Sharpe <realrichardsharpe@gmail.com>
Subject: Re: [PATCH 4/5] tcm: Unify UNMAP and WRITE_SAME w/ UNMAP=1 subsystem plugin handling
Date: Thu, 14 Oct 2010 02:03:41 +0200	[thread overview]
Message-ID: <20101014000341.GA15583@lst.de> (raw)
In-Reply-To: <1287003368.7334.64.camel@haakon2.linux-iscsi.org>

On Wed, Oct 13, 2010 at 01:56:08PM -0700, Nicholas A. Bellinger wrote:
> > The parsing of the WRITE SAME and UNMAP CDBs is something the generic
> > CDB parsing code should do,
> 
> Ok, so you are thinking about a seperate transport_emulate_write_same()
> and transport_emulate_unmap() called from
> transport_emulate_control_cdb(), right..?

More or less yes.

> >  and just give a range of lists of lba/len
> > pairs to the ->discard method in the backed.
> 
> Yes, these are already available from the passed struct
> se_task->task_lba and ->task_size values.

Not for UNMAP.  WRITE SAME in it's various incarnations uses the
standard LBA/LEN encoding and you seem to parse it nicely.  But for
UNMAP the lba/len pairs are in the command payload.  To support things
genericly you'd need a standard way to pass them.  If you want to
limit yourself to one lba/len pair for one the scheme could work,
though.

> Yes, so the problem of trying to make this code generic (eg: outside of
> TCM subsystem plugins) is that blk_issue_discard() takes struct
> block_device, which means we the subsystem plugin has to locate struct
> block_device inside of non generic cide.

blk_issue_discard is in no way generic.  It's 100% iblock code and
really doesn't belong into any other backend.  And btw,
blk_issue_discard is rather suboptimal even in iblock - it's a
synchronous function that will stall progress of the thread handling it.
If you want better performance you'll need to opencode the content of
it to allow an asynchronous completion handler.  But given that discard
isn't really a critical feature at this point this could easily be
left for later with a comment.

> So, then the main issue becomes FILEIO + block level discard and how to
> issue an blk_issue_discard() from struct fileio in the most sane way.
> If there is no sane way then I will just drop this bit, or just do the
> file level 'hole punch' that you are speaking about.

Right now there is no good way to do a block device discard or file
hole punch at the level where the file backend operates.


  reply	other threads:[~2010-10-14  0:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-13  8:48 [PATCH 4/5] tcm: Unify UNMAP and WRITE_SAME w/ UNMAP=1 subsystem plugin handling Nicholas A. Bellinger
2010-10-13 11:19 ` Christoph Hellwig
2010-10-13 20:56   ` Nicholas A. Bellinger
2010-10-14  0:03     ` Christoph Hellwig [this message]
2010-10-14  4:27       ` Nicholas A. Bellinger
2010-10-17 15:52       ` Boaz Harrosh
2010-10-17 20:53         ` Nicholas A. Bellinger

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=20101014000341.GA15583@lst.de \
    --to=hch@lst.de \
    --cc=James.Bottomley@suse.de \
    --cc=axboe@kernel.dk \
    --cc=bharrosh@panasas.com \
    --cc=dgilbert@interlog.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michaelc@cs.wisc.edu \
    --cc=nab@linux-iscsi.org \
    --cc=realrichardsharpe@gmail.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).