From: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
To: Zach Brown <zab@redhat.com>
Cc: "Nicholas A. Bellinger" <nab@daterainc.com>,
target-devel <target-devel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@suse.de>,
Martin Petersen <martin.petersen@oracle.com>,
Chris Mason <chris.mason@fusionio.com>,
Roland Dreier <roland@purestorage.com>,
Kent Overstreet <kmo@daterainc.com>, Theodore Tso <tytso@mit.edu>,
James Bottomley <JBottomley@Parallels.com>
Subject: Re: [PATCH-v2 0/9] target: Add support for EXTENDED_COPY (VAAI) offload emulation
Date: Mon, 26 Aug 2013 17:02:21 -0700 [thread overview]
Message-ID: <1377561741.32763.205.camel@haakon3.risingtidesystems.com> (raw)
In-Reply-To: <20130826224628.GJ26818@lenny.home.zabbo.net>
On Mon, 2013-08-26 at 15:46 -0700, Zach Brown wrote:
> On Mon, Aug 26, 2013 at 10:02:59PM +0000, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger <nab@daterainc.com>
> >
> > Hi folks,
> >
> > This -v2 series adds support to target-core for generic EXTENDED_COPY offload
> > emulation as defined by SPC-4 using virtual (IBLOCK, FILEIO, RAMDISK)
> > backends.
>
> Cool, thanks for sending this out. I'll just stare blankly but
> supportively at the SCSI details.
>
> I've been experimenting with the reasonable suggestion of using splice
> as the entry point into the high level fs methods that'd be backed by
> this stuff. Let me get it cleaned up and sent out for review.
>
> Hopefully with a few iterations of that we could test some block file
> systems on top of this.
Looking forward to seeing your copy offload work at the fs level, along
with the block -> SCSI client copy offload pieces from MKP.
Along with having proper VAAI support in target-core for ESX clients,
the larger intention behind getting this upstream is to seed the KVM
ecosystem with storage primitives previously out of reach to most users.
>
> > This implemenation fully supports copy offload between the same device
> > backend, and across multiple device backends. It supports copy offload
> > transparently across multiple target ports of different fabrics, eg:
> > iSCSI -> FC, FC -> iSER, iSER -> FCoE and so on.
>
> That's exciting! I doubt that we want to be derailed by getting this
> working in the first pass, but it'd be fun to enable cross-fs copying
> once we got the fundamentals worked out
>
Indeed, a single filesystem -> single device case is a reasonable place
to start.
For the multiple filesystem -> multiple device case, a potential
interface needs to plumb the block device and it's underlying NAA IEEE
WWNs down to SCSI. The target side EXTENDED_COPY logic uses this
information in target descriptors of type 0xe4 to locate destination /
source devices, depending on if the PUSH / PULL copy method is employed.
For using physical SCSI devices below the filesystem, this would seem
straight-forward enough. For the stacking raw block device cases
however, this poses alot more interesting set of problems..
MKP, have you thought about how copy offload might work with stacking
block devices..?
--nab
prev parent reply other threads:[~2013-08-26 23:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-26 22:02 Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 1/9] target: Make target_core_subsystem defined as non static Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 2/9] target: Make spc_parse_naa_6h_vendor_specific " Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 3/9] target: Make helpers non static for EXTENDED_COPY command setup Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 4/9] target: Add global device list for EXTENDED_COPY Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 5/9] target: Avoid non-existent tg_pt_gp_mem in target_alua_state_check Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 6/9] target: Add support for EXTENDED_COPY copy offload emulation Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 7/9] target: Enable EXTENDED_COPY setup in spc_parse_cdb Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 8/9] target: Add Third Party Copy (3PC) bit in INQUIRY response Nicholas A. Bellinger
2013-08-26 22:03 ` [PATCH-v2 9/9] target: Enable global EXTENDED_COPY setup/release Nicholas A. Bellinger
2013-08-26 22:46 ` [PATCH-v2 0/9] target: Add support for EXTENDED_COPY (VAAI) offload emulation Zach Brown
2013-08-27 0:02 ` Nicholas A. Bellinger [this message]
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=1377561741.32763.205.camel@haakon3.risingtidesystems.com \
--to=nab@linux-iscsi.org \
--cc=JBottomley@Parallels.com \
--cc=chris.mason@fusionio.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kmo@daterainc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=nab@daterainc.com \
--cc=roland@purestorage.com \
--cc=target-devel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=zab@redhat.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
all inboxes | Powered by JetHome®