From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: [RFC] extending splice for copy offloading Date: Sat, 28 Sep 2013 17:20:57 -0400 Message-ID: <52474839.2080201@redhat.com> 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> <20130927205013.GZ30372@lenny.home.zabbo.net> <4FA345DA4F4AE44899BD2B03EEEC2FA9467EF2D7@SACEXCMBX04-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Miklos Szeredi , Zach Brown , "J. Bruce Fields" , 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 To: "Myklebust, Trond" Return-path: In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA9467EF2D7@SACEXCMBX04-PRD.hq.netapp.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 09/28/2013 11:20 AM, Myklebust, Trond wrote: >> -----Original Message----- >> From: Miklos Szeredi [mailto:miklos@szeredi.hu] >> Sent: Saturday, September 28, 2013 12:50 AM >> To: Zach Brown >> Cc: J. Bruce Fields; Ric Wheeler; Anna Schumaker; Kernel Mailing Lis= t; Linux- >> Fsdevel; linux-nfs@vger.kernel.org; Myklebust, Trond; Schumaker, Bry= an; >> Martin K. Petersen; Jens Axboe; Mark Fasheh; Joel Becker; Eric Wong >> Subject: Re: [RFC] extending splice for copy offloading >> >> On Fri, Sep 27, 2013 at 10:50 PM, Zach Brown wrote: >>>> 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? >> I don't see the safety argument very compelling either. There are r= eal >> semantic differences, however: ENOSPC on a write to a >> (apparentl=C3=ADy) already allocated block. That could be a bit une= xpected. Do we >> need a fallocate extension to deal with shared blocks? > The above has been the case for all enterprise storage arrays ever si= nce the invention of snapshots. The NFSv4.2 spec does allow you to set = a per-file attribute that causes the storage server to always prealloca= te enough buffers to guarantee that you can rewrite the entire file, ho= wever the fact that we've lived without it for said 20 years leads me t= o believe that demand for it is going to be limited. I haven't put it t= op of the list of features we care to implement... > > Cheers, > Trond I agree - this has been common behaviour for a very long time in the ar= ray=20 space. Even without an array, this is the same as overwriting a block = in btrfs=20 or any file system with a read-write LVM snapshot. Regards, Ric