[LSF/MM TOPIC] Copy offload

[LSF/MM TOPIC] Copy offload

[Hannes Reinecke]

Quite a lot of discussion has come up recently on supporting Copy
Offload (aka SCSI XCOPY) with linux.

During the course of this several topics were found which need some
discussion:

- Interface: do we need a new syscall? Should we try to resurrect
  the original sys_copyfile() approach from Joel Becker?
  What are the areas and use-cases this syscall should cover?

- Scope: SCSI XCOPY is not the only possible user here, CIFS and
  NFSv4 have similar needs. We should aim for integrating all of
  these use-cases. However, we need to revisit them to figure out
  if and to what extend they are really compatible.

- Implementation: The new interface is likely to reside on the
  filesystem level. To quote Dave Chinner:
  > e.g. for an array offload, we have to flush the source file
  > page cache first so that the data being copied is known to
  > be on disk, then invalidate the destination page cache if
  > overwriting or extend and pre-allocate blocks if not. Then
  > we have to map both files and hand that off to the array.
  >
  > Then there's a whole bunch of tricky questions about what
  > the state of the destination file should look like while
  > the copy is in progress, whether the source file should be
  > allowed to change (e.g. it can't be truncated and have
  > blocks freed and then reused by other files half way through
  > the copy offload operation), and so on.

- Backends: Should we concentrate on the new 'XCOPY LITE' proposal
  or should we try to implement the original XCOPY command, too?

I guess this'll warrant a joint session, as at least filesystem and
storage people will be involved here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [LSF/MM TOPIC] Copy offload

[Joel Becker]

On Mon, Jan 09, 2012 at 11:27:30AM +0100, Hannes Reinecke wrote:
> Quite a lot of discussion has come up recently on supporting Copy
> Offload (aka SCSI XCOPY) with linux.
> 
> During the course of this several topics were found which need some
> discussion:
> 
> - Interface: do we need a new syscall? Should we try to resurrect
>   the original sys_copyfile() approach from Joel Becker?
>   What are the areas and use-cases this syscall should cover?
> 
> - Scope: SCSI XCOPY is not the only possible user here, CIFS and
>   NFSv4 have similar needs. We should aim for integrating all of
>   these use-cases. However, we need to revisit them to figure out
>   if and to what extend they are really compatible.
> 
> - Implementation: The new interface is likely to reside on the
>   filesystem level. To quote Dave Chinner:
>   > e.g. for an array offload, we have to flush the source file
>   > page cache first so that the data being copied is known to
>   > be on disk, then invalidate the destination page cache if
>   > overwriting or extend and pre-allocate blocks if not. Then
>   > we have to map both files and hand that off to the array.
>   >
>   > Then there's a whole bunch of tricky questions about what
>   > the state of the destination file should look like while
>   > the copy is in progress, whether the source file should be
>   > allowed to change (e.g. it can't be truncated and have
>   > blocks freed and then reused by other files half way through
>   > the copy offload operation), and so on.
> 
> - Backends: Should we concentrate on the new 'XCOPY LITE' proposal
>   or should we try to implement the original XCOPY command, too?
> 
> I guess this'll warrant a joint session, as at least filesystem and
> storage people will be involved here.

	I'll join in for sure.  I've owed code for over a year now
(hanging head in shame).

Joel


-- 

"Lately I've been talking in my sleep.
 Can't imagine what I'd have to say.
 Except my world will be right
 When love comes back my way."

			http://www.jlbec.org/
			jlbec@evilplan.org

Re: [LSF/MM TOPIC] Copy offload

[Martin K. Petersen]

>>>>> "Hannes" == Hannes Reinecke <hare@suse.de> writes:

Hannes> - Backends: Should we concentrate on the new 'XCOPY LITE'
Hannes>   proposal or should we try to implement the original XCOPY
Hannes>   command, too?

I know of very few vendors interested in implementing the original XCOPY
stuff. Only the standards people seem to be excited about it. It's way
too complex, IMHO.

XCOPY lite is a much better fit for how we actually do I/O. So that's
what I'm tracking closely. As we talked about in Prague, I've dabbled a
bit with the design from an I/O stack perspective and it fits nicely.

My gut feeling is that XCOPYv2 might get ratified but companies will
actually end up implementing XCOPY lite. Regardless of whether the lite
proposal gets into the spec or not.

T10 appears to be designing a lot of stuff right now that's an extremely
poor fit for how modern operating systems work. I think we may see a
bigger divergence between what's in the spec and what companies choose
to implement.

-- 
Martin K. Petersen	Oracle Linux Engineering