Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754230Ab3I0Uu6 (ORCPT ); Fri, 27 Sep 2013 16:50:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40277 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751574Ab3I0Uuy (ORCPT ); Fri, 27 Sep 2013 16:50:54 -0400 Date: Fri, 27 Sep 2013 13:50:13 -0700 From: Zach Brown To: "J. Bruce Fields" Cc: Ric Wheeler , Miklos Szeredi , Anna Schumaker , Kernel Mailing List , Linux-Fsdevel , "linux-nfs@vger.kernel.org" , Trond Myklebust , Bryan Schumaker , "Martin K. Petersen" , Jens Axboe , Mark Fasheh , Joel Becker , Eric Wong Subject: Re: [RFC] extending splice for copy offloading Message-ID: <20130927205013.GZ30372@lenny.home.zabbo.net> References: <20130925183828.GA30372@lenny.home.zabbo.net> <20130925190620.GB30372@lenny.home.zabbo.net> <20130925195526.GA18971@fieldses.org> <20130925210742.GG30372@lenny.home.zabbo.net> <20130926185508.GO30372@lenny.home.zabbo.net> <5244A68F.906@redhat.com> <20130927200550.GA22640@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130927200550.GA22640@fieldses.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2452 Lines: 60 > > >Sure. So we'd have: > > > > > >- no flag default that forbids knowingly copying with shared references > > > so that it will be used by default by people who feel strongly about > > > their assumptions about independent write durability. > > > > > >- a flag that allows shared references for people who would otherwise > > > use the file system shared reference ioctls (ocfs2 reflink, btrfs > > > clone) but would like it to also do server-side read/write copies > > > over nfs without additional intervention. > > > > > >- a flag that requires shared references for callers who don't want > > > giant copies to take forever if they aren't instant. (The qemu guys > > > asked for this at Plumbers.) > > Why not implement only the last flag only as the first step? It seems > like the simplest one. So I think that would mean: > > - no worrying about cancelling, etc. > - apps should be told to pass the entire range at once (normally > the whole file). > - The NFS server probably shouldn't do the internal copy loop by > default. > > We can't prevent some storage system from implementing a high-latency > copy operation, but we can refuse to provide them any help (providing no > progress reports or easy way to cancel) and then they can deal with the > complaints from their users. I can see where you're going with that, yeah. It'd make less sense as a splice extension, then, perhaps. It'd be more like a generic entry point for the existing ioctls. Maybe even just defining the semantics of a common ioctl. Hmm. > Also, I don't get the first option above at all. The argument is that > it's safer to have more copies? How much safety does another copy on > the same disk really give you? Do systems that do dedup provide > interfaces to turn it off per-file? Yeah, got me. It's certainly nonsense on a lot of FTL logging implementations (which are making their way into SMR drives in the future). > But I understand that Zach's tired of the woodshedding and I could live > with the above I guess.... No, it's fine. At least people are expressing some interest in the interface! That's a marked improvement over the state of things in the past. - z -- 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/