On 12/18/2013 12:10 PM, Zach Brown wrote:
> On Wed, Dec 18, 2013 at 04:41:26AM -0800, Christoph Hellwig wrote:
>> On Wed, Sep 11, 2013 at 10:06:47AM -0700, Zach Brown wrote:
>>> When I first started on this stuff I followed the lead of previous
>>> work and added a new syscall for the copy operatio
On Wed, Dec 18, 2013 at 04:41:26AM -0800, Christoph Hellwig wrote:
> On Wed, Sep 11, 2013 at 10:06:47AM -0700, Zach Brown wrote:
> > When I first started on this stuff I followed the lead of previous
> > work and added a new syscall for the copy operation:
> >
> > https://lkml.org/lkml/2013/5/14/6
On Wed, Sep 11, 2013 at 10:06:47AM -0700, Zach Brown wrote:
> When I first started on this stuff I followed the lead of previous
> work and added a new syscall for the copy operation:
>
> https://lkml.org/lkml/2013/5/14/618
>
> Towards the end of that thread Eric Wong asked why we didn't just
> e
On 09/26/2013 01:06:41 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 5:34 PM, J. Bruce Fields
wrote:
> On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
>> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown
wrote:
>> >> A client-side copy will be slower, but I guess it does hav
On Wed, 2 Oct 2013, Jan Kara wrote:
On Tue 01-10-13 12:58:17, Zach Brown wrote:
- app calls splice(from, 0, to, 0, SIZE_MAX)
1) VFS calls ->direct_splice(from, 0, to, 0, SIZE_MAX)
1.a) fs reflinks the whole file in a jiffy and returns the size of the file
1 b) fs does copy offload of,
On Tue 01-10-13 12:58:17, Zach Brown wrote:
> > - app calls splice(from, 0, to, 0, SIZE_MAX)
> > 1) VFS calls ->direct_splice(from, 0, to, 0, SIZE_MAX)
> > 1.a) fs reflinks the whole file in a jiffy and returns the size of the
> > file
> > 1 b) fs does copy offload of, say, 64MB and retu
> - app calls splice(from, 0, to, 0, SIZE_MAX)
> 1) VFS calls ->direct_splice(from, 0, to, 0, SIZE_MAX)
> 1.a) fs reflinks the whole file in a jiffy and returns the size of the
> file
> 1 b) fs does copy offload of, say, 64MB and returns 64M
> 2) VFS does page copy of, say, 1MB and retu
On Mon, Sep 30, 2013 at 05:46:38PM +0200, 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 co
On Mon, 2013-09-30 at 16:08 -0400, Ric Wheeler wrote:
> On 09/30/2013 04:00 PM, Bernd Schubert wrote:
> > pNFS, FhGFS, Lustre, Ceph, etc., all of them shall implement their own
> > interface? And userspace needs to address all of them differently?
>
> The NFS and SCSI groups have each defined a
On Mon, 2013-09-30 at 22:00 +0200, Bernd Schubert wrote:
> On 09/30/2013 09:34 PM, Myklebust, Trond wrote:
> > On Mon, 2013-09-30 at 20:49 +0200, Bernd Schubert wrote:
> >> On 09/30/2013 08:02 PM, Myklebust, Trond wrote:
> >>> On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote:
> On 09/30
On 09/30/2013 04:00 PM, Bernd Schubert wrote:
pNFS, FhGFS, Lustre, Ceph, etc., all of them shall implement their own
interface? And userspace needs to address all of them differently?
The NFS and SCSI groups have each defined a standard which Zach's proposal
abstracts into a common user API.
On 09/30/2013 09:34 PM, Myklebust, Trond wrote:
On Mon, 2013-09-30 at 20:49 +0200, Bernd Schubert wrote:
On 09/30/2013 08:02 PM, Myklebust, Trond wrote:
On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote:
On 09/30/2013 07:44 PM, Myklebust, Trond wrote:
On Mon, 2013-09-30 at 19:17 +0200,
On Mon, 2013-09-30 at 20:49 +0200, Bernd Schubert wrote:
> On 09/30/2013 08:02 PM, Myklebust, Trond wrote:
> > On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote:
> >> On 09/30/2013 07:44 PM, Myklebust, Trond wrote:
> >>> On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote:
> It would
On 09/30/2013 08:02 PM, Myklebust, Trond wrote:
On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote:
On 09/30/2013 07:44 PM, Myklebust, Trond wrote:
On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote:
It would be nice if there would be way if the file system would get a
hint that the
On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote:
> On 09/30/2013 07:44 PM, Myklebust, Trond wrote:
> > On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote:
> >> It would be nice if there would be way if the file system would get a
> >> hint that the target file is supposed to be copy of
On 09/30/2013 07:44 PM, Myklebust, Trond wrote:
On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote:
It would be nice if there would be way if the file system would get a
hint that the target file is supposed to be copy of another file. That
way distributed file systems could also create the
On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote:
> It would be nice if there would be way if the file system would get a
> hint that the target file is supposed to be copy of another file. That
> way distributed file systems could also create the target-file with the
> correct meta-infor
On 09/30/2013 06:31 PM, Miklos Szeredi wrote:
Here's an example "cp" app using direct splice (and without fallback to
non-splice, which is obviously required unless the kernel is known to support
direct splice).
Untested, but trivial enough...
The important part is, I think, that the app must n
Here's an example "cp" app using direct splice (and without fallback to
non-splice, which is obviously required unless the kernel is known to support
direct splice).
Untested, but trivial enough...
The important part is, I think, that the app must not assume that the kernel can
complete the reque
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 vali
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
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
On 09/30/2013 10:38 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:28 PM, Ric Wheeler wrote:
On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields
On Mon, Sep 30, 2013 at 4:28 PM, Ric Wheeler wrote:
> On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
>>
>> On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler wrote:
>>>
>>> On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields
wrote:
>>
>>
; Schumaker, Bryan;
> Martin K. Petersen; Jens Axboe; Mark Fasheh; Joel Becker; Eric Wong
> Subject: Re: [RFC] extending splice for copy offloading
>
> On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
> > On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler
> wrote:
> >> On 09/30/2
On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields
wrote:
My other worry is about interruptibility/restartability. Ideas?
What happens on splice(fro
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler wrote:
> On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
>>
>> On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields
>> wrote:
My other worry is about interruptibility/restartability. Ideas?
What happens on splice(from, to, 4G) and it's a
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields wrote:
My other worry is about interruptibility/restartability. Ideas?
What happens on splice(from, to, 4G) and it's a non-reflink copy?
Can the page cache copy be made restartable? Or should spli
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields wrote:
>> My other worry is about interruptibility/restartability. Ideas?
>>
>> What happens on splice(from, to, 4G) and it's a non-reflink copy?
>> Can the page cache copy be made restartable? Or should splice() be
>> allowed to return a short c
On 09/30/2013 10:34 AM, J. Bruce Fields wrote:
On Mon, Sep 30, 2013 at 02:20:30PM +0200, Miklos Szeredi wrote:
On Sat, Sep 28, 2013 at 11:20 PM, Ric Wheeler wrote:
I don't see the safety argument very compelling either. There are real
semantic differences, however: ENOSPC on a write to a
(ap
On Mon, Sep 30, 2013 at 02:20:30PM +0200, Miklos Szeredi wrote:
> On Sat, Sep 28, 2013 at 11:20 PM, Ric Wheeler wrote:
>
> >>> I don't see the safety argument very compelling either. There are real
> >>> semantic differences, however: ENOSPC on a write to a
> >>> (apparentlíy) already allocated
On Sat, Sep 28, 2013 at 11:20 PM, Ric Wheeler wrote:
>>> I don't see the safety argument very compelling either. There are real
>>> semantic differences, however: ENOSPC on a write to a
>>> (apparentlíy) already allocated block. That could be a bit unexpected.
>>> Do we
>>> need a fallocate ext
; Myklebust, Trond; Schumaker, Bryan;
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'
; Schumaker, Bryan;
> 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
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 pe
> > >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
On Thu, Sep 26, 2013 at 05:26:39PM -0400, Ric Wheeler wrote:
> On 09/26/2013 02:55 PM, Zach Brown wrote:
> >On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
> >>On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
> A client-side copy will be slower, but I guess it does have the
On Fri, Sep 27, 2013 at 4:00 PM, Ric Wheeler wrote:
> I think that you are an order of magnitude off here in thinking about the
> scale of the operations.
>
> An enabled, synchronize copy offload to an array (or one that turns into a
> reflink locally) is effectively the cost of the call itself.
On 09/27/2013 12:47 AM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler wrote:
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote:
But I'm not sure it's worth the effort; 99% of the use of this
interface will be copying whole
On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler wrote:
> On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
>>
>> On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote:
>>
But I'm not sure it's worth the effort; 99% of the use of this
interface will be copying whole files. And for that perhaps we
On 09/26/2013 02:55 PM, Zach Brown wrote:
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the application can track progress to some degree, and
ab
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote:
But I'm not sure it's worth the effort; 99% of the use of this
interface will be copying whole files. And for that perhaps we need a
different API, one which has been discussed some time ago:
asyn
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote:
>> But I'm not sure it's worth the effort; 99% of the use of this
>> interface will be copying whole files. And for that perhaps we need a
>> different API, one which has been discussed some time ago:
>> asynchronous copyfile() returns immediate
On Thu, Sep 26, 2013 at 08:06:41PM +0200, Miklos Szeredi wrote:
> On Thu, Sep 26, 2013 at 5:34 PM, J. Bruce Fields wrote:
> > On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
> >> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
> >> >> A client-side copy will be slower, but I g
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
> >> A client-side copy will be slower, but I guess it does have the
> >> advantage that the application can track progress to some degree, and
> >> abort it fairly quickly without
On Thu, Sep 26, 2013 at 5:34 PM, J. Bruce Fields wrote:
> On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
>> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
>> >> A client-side copy will be slower, but I guess it does have the
>> >> advantage that the application can track pro
On 09/26/2013 11:34 AM, J. Bruce Fields wrote:
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the application can track progress to some degree, a
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
> >> A client-side copy will be slower, but I guess it does have the
> >> advantage that the application can track progress to some degree, and
> >> abort it fairly quickly without
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
>> A client-side copy will be slower, but I guess it does have the
>> advantage that the application can track progress to some degree, and
>> abort it fairly quickly without leaving the file in a totally undefined
>> state--and both might be use
> A client-side copy will be slower, but I guess it does have the
> advantage that the application can track progress to some degree, and
> abort it fairly quickly without leaving the file in a totally undefined
> state--and both might be useful if the copy's not a simple constant-time
> operation.
On Wed, Sep 25, 2013 at 12:06:20PM -0700, Zach Brown wrote:
> On Wed, Sep 25, 2013 at 03:02:29PM -0400, Anna Schumaker wrote:
> > On Wed, Sep 25, 2013 at 2:38 PM, Zach Brown wrote:
> > >
> > > Hrmph. I had composed a reply to you during Plumbers but.. something
> > > happened to it :). Here's an
On Wed, Sep 25, 2013 at 03:02:29PM -0400, Anna Schumaker wrote:
> On Wed, Sep 25, 2013 at 2:38 PM, Zach Brown wrote:
> >
> > Hrmph. I had composed a reply to you during Plumbers but.. something
> > happened to it :). Here's another try now that I'm back.
> >
> >> > Some things to talk about:
> >
On Wed, Sep 25, 2013 at 2:38 PM, Zach Brown wrote:
>
> Hrmph. I had composed a reply to you during Plumbers but.. something
> happened to it :). Here's another try now that I'm back.
>
>> > Some things to talk about:
>> > - I really don't care about the naming here. If you do, holler.
>> > - We
Hrmph. I had composed a reply to you during Plumbers but.. something
happened to it :). Here's another try now that I'm back.
> > Some things to talk about:
> > - I really don't care about the naming here. If you do, holler.
> > - We might want different flags for file-to-file splicing and acc
On Wed, Sep 11, 2013 at 7:06 PM, Zach Brown wrote:
>
> When I first started on this stuff I followed the lead of previous
> work and added a new syscall for the copy operation:
>
> https://lkml.org/lkml/2013/5/14/618
>
> Towards the end of that thread Eric Wong asked why we didn't just
> extend sp
On Wed, 11 Sep 2013 21:17:23 +
Eric Wong wrote:
> Zach Brown wrote:
> > Towards the end of that thread Eric Wong asked why we didn't just
> > extend splice. I immediately replied with some dumb dismissive
> > answer. Once I sat down and looked at it, though, it does make a
> > lot of sense
On 09/11/2013 04:17:23 PM, Eric Wong wrote:
Zach Brown wrote:
> Towards the end of that thread Eric Wong asked why we didn't just
> extend splice. I immediately replied with some dumb dismissive
> answer. Once I sat down and looked at it, though, it does make a
> lot of sense. So good job, Er
Zach Brown wrote:
> Towards the end of that thread Eric Wong asked why we didn't just
> extend splice. I immediately replied with some dumb dismissive
> answer. Once I sat down and looked at it, though, it does make a
> lot of sense. So good job, Eric. +10 Dummie points for me.
Thanks for rev
58 matches
Mail list logo
