Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755919Ab3I3P5v (ORCPT ); Mon, 30 Sep 2013 11:57:51 -0400 Received: from mail-qe0-f41.google.com ([209.85.128.41]:39143 "EHLO mail-qe0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755794Ab3I3P5o (ORCPT ); Mon, 30 Sep 2013 11:57:44 -0400 MIME-Version: 1.0 X-Originating-IP: [86.59.245.170] In-Reply-To: <52498F68.8050200@redhat.com> References: <20130925210742.GG30372@lenny.home.zabbo.net> <20130926185508.GO30372@lenny.home.zabbo.net> <5244A68F.906@redhat.com> <20130927200550.GA22640@fieldses.org> <20130927205013.GZ30372@lenny.home.zabbo.net> <4FA345DA4F4AE44899BD2B03EEEC2FA9467EF2D7@SACEXCMBX04-PRD.hq.netapp.com> <52474839.2080201@redhat.com> <20130930143432.GG16579@fieldses.org> <52499026.3090802@redhat.com> <52498AA8.2090204@redhat.com> <52498DB6.7060901@redhat.com> <52498F68.8050200@redhat.com> Date: Mon, 30 Sep 2013 17:57:41 +0200 Message-ID: Subject: Re: [RFC] extending splice for copy offloading From: Miklos Szeredi To: Ric Wheeler Cc: "J. Bruce Fields" , "Myklebust, Trond" , Zach Brown , Anna Schumaker , Kernel Mailing List , Linux-Fsdevel , "linux-nfs@vger.kernel.org" , "Schumaker, Bryan" , "Martin K. Petersen" , Jens Axboe , Mark Fasheh , Joel Becker , Eric Wong Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1553 Lines: 43 On Mon, Sep 30, 2013 at 4:49 PM, Ric Wheeler wrote: > On 09/30/2013 10:46 AM, Miklos Szeredi wrote: >> >> On Mon, Sep 30, 2013 at 4:41 PM, Ric Wheeler wrote: >>> >>> The way the array based offload (and some software side reflink works) is >>> not a byte by byte copy. We cannot assume that a valid count can be >>> returned >>> or that such a count would be an indication of a sequential segment of >>> good >>> data. The whole thing would normally have to be reissued. >>> >>> To make that a true assumption, you would have to mandate that in each of >>> the specifications (and sw targets)... >> >> You're missing my point. >> >> - user issues SIZE_MAX splice request >> - fs issues *64M* (or whatever) request to offload >> - when that completes *fully* then we return 64M to userspace >> - if it completes partially, then we return an error to userspace >> >> Again, wouldn't that work? >> >> Thanks, >> Miklos > > > Yes, if you send a copy offload command and it works, you can assume that it > worked fully. It would be pretty interesting if that were not true :) > > If it fails, we cannot assume anything about partial completion. Sure, that was my understanding from the start. Maybe I wasn't precise enough in my explanation. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/