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
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:
> >
> >
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
>
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
extend
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/618
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 operation:
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
On 09/26/2013 01:06:41 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 5:34 PM, J. Bruce Fields
bfie...@fieldses.org 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 z...@redhat.com
wrote:
A client-side copy will be
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
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
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 returns 64M
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,
> - 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
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
On Mon, Sep 30, 2013 at 05:46:38PM +0200, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:41 PM, Ric Wheeler rwhee...@redhat.com 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
- 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 returns
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Sat, Sep 28, 2013 at 11:20 PM, Ric Wheeler rwhee...@redhat.com 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
On Mon, Sep 30, 2013 at 02:20:30PM +0200, Miklos Szeredi wrote:
On Sat, Sep 28, 2013 at 11:20 PM, Ric Wheeler rwhee...@redhat.com 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
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 rwhee...@redhat.com wrote:
I don't see the safety argument very compelling either. There are real
semantic differences, however: ENOSPC
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields bfie...@fieldses.org 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
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields bfie...@fieldses.org 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
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields bfie...@fieldses.org
wrote:
My other worry is about interruptibility/restartability. Ideas?
What happens on splice(from,
On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields bfie...@fieldses.org
wrote:
My other worry is about
. 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 rwhee...@redhat.com
wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon
On Mon, Sep 30, 2013 at 4:28 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:34 PM, J. Bruce Fields
On 09/30/2013 10:38 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:28 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/30/2013 10:24 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:52 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/30/2013 10:51 AM, Miklos Szeredi wrote:
On Mon,
On Mon, Sep 30, 2013 at 4:41 PM, Ric Wheeler rwhee...@redhat.com 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
On 09/30/2013 10:46 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:41 PM, Ric Wheeler rwhee...@redhat.com 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
On Mon, Sep 30, 2013 at 4:49 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/30/2013 10:46 AM, Miklos Szeredi wrote:
On Mon, Sep 30, 2013 at 4:41 PM, Ric Wheeler rwhee...@redhat.com wrote:
The way the array based offload (and some software side reflink works) is
not a byte by byte copy. We
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
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
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
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
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 another
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 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 be nice if
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 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 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/2013 07:44
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
; 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's safer
; 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
&
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 z...@redhat.com wrote:
Also, I don't get the first option above at all. The argument is
that it's safer to have more copies? How
; 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 z...@redhat.com 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
> > >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 09/27/2013 12:47 AM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown z...@redhat.com wrote:
But I'm not sure it's worth the effort; 99% of the use of
On Fri, Sep 27, 2013 at 4:00 PM, Ric Wheeler rwhee...@redhat.com 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
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 z...@redhat.com wrote:
A client-side copy will be slower, but I guess it does have
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
On Fri, Sep 27, 2013 at 10:50 PM, Zach Brown z...@redhat.com 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
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
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
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:
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
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
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
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
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,
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
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
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown z...@redhat.com 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
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown z...@redhat.com 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
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 z...@redhat.com wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the application can track progress
On Thu, Sep 26, 2013 at 5:34 PM, J. Bruce Fields bfie...@fieldses.org 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 z...@redhat.com wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown z...@redhat.com 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
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 bfie...@fieldses.org 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 z...@redhat.com wrote:
A client-side
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown z...@redhat.com 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
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown z...@redhat.com 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
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 z...@redhat.com wrote:
A client-side copy will be slower, but I guess it does have the
advantage that the application can track progress to
On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown z...@redhat.com wrote:
But I'm not sure it's worth the effort; 99% of the use of this
interface will be copying whole files. And
> 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
>
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
1 - 100 of 118 matches
Mail list logo
