Re: [PATCH-v2 0/9] target: Add support for EXTENDED_COPY (VAAI)offload emulation

[Nicholas A. Bellinger]

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@xxxxxxxxxxxxx>
> > 
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/