On 12/19/2011 02:57 PM, Dave Chinner wrote: > > That was my immediate thought, but sendfile has plumbing that is > page cache based and we require completely different infrastructure > and semantics for an array offload. > The plumbing is internal to the kernel and doesn't mean we have to use the same VFS methods. > 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. > > sendfile() has well known, fixed semantics that we can't change to > suit what is needed for an offload operation that could potentially > take hours to complete. Hence I think an new syscall is the way to > go.... Perhaps what we need first in an explicit enumeration of the semantics you're looking for. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
