Re: [LSF/MM TOPIC] The end of the DAX experiment

On 2/6/19 4:12 PM, Dan Williams wrote: Before people get too excited this isn't a proposal to kill DAX. The topic proposal is a discussion to resolve lingering open questions that currently motivate ext4 and xfs to scream "EXPERIMENTAL" when the current DAX facilities are enabled. The are 2

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/16/2016 06:23 PM, Chris Mason wrote: On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: On 3/15/16 7:06 PM, Linus Torvalds wrote: On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: It is

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/16/2016 06:23 PM, Chris Mason wrote: On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: On 3/15/16 7:06 PM, Linus Torvalds wrote: On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: It is pretty clear that the

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/17/2016 01:47 PM, Linus Torvalds wrote: On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: So we've not asked for NO_HIDE_STALE on the mailing lists, but I think it was one of the problems Sage had using xfs in his BlueStore implementation and was a big part of why

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/17/2016 01:47 PM, Linus Torvalds wrote: On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: So we've not asked for NO_HIDE_STALE on the mailing lists, but I think it was one of the problems Sage had using xfs in his BlueStore implementation and was a big part of why it moved to pure

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/13/2016 07:30 PM, Dave Chinner wrote: On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: At the end of the day it's about whether you trust the userspace program or not. There's a big difference between

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/13/2016 07:30 PM, Dave Chinner wrote: On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: At the end of the day it's about whether you trust the userspace program or not. There's a big difference between "give the user

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/11/2016 12:03 AM, Linus Torvalds wrote: On Thu, Mar 10, 2016 at 6:58 AM, Ric Wheeler <ricwhee...@gmail.com> wrote: What was objectionable at the time this patch was raised years back (not just to me, but to pretty much every fs developer at LSF/MM that year) centered on the c

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/11/2016 12:03 AM, Linus Torvalds wrote: On Thu, Mar 10, 2016 at 6:58 AM, Ric Wheeler wrote: What was objectionable at the time this patch was raised years back (not just to me, but to pretty much every fs developer at LSF/MM that year) centered on the concern that this would be viewed

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

was that people like Ric Wheeler threatened to have distro-specific patches to disable the feature, and at the end of the day, I didn't care that much. After all, if it makes it harder for large scale cloud companies besides Google to create more efficient userspace cluster file systems, it's

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

was that people like Ric Wheeler threatened to have distro-specific patches to disable the feature, and at the end of the day, I didn't care that much. After all, if it makes it harder for large scale cloud companies besides Google to create more efficient userspace cluster file systems, it's

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

I would like to nominate Sage Weil with his consent. Sage has lead the ceph project since its inception, contributed to the kernel as well as had an influence on projects like openstack. thanks! Ric On 10/06/2015 01:06 PM, Grant Likely wrote: [Resending because I messed up the first one]

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

I would like to nominate Sage Weil with his consent. Sage has lead the ceph project since its inception, contributed to the kernel as well as had an influence on projects like openstack. thanks! Ric On 10/06/2015 01:06 PM, Grant Likely wrote: [Resending because I messed up the first one]

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 01:37 PM, Chris Mason wrote: > Circling back to what we might talk about at the conference, Ric do you > have any ideas on when these drives might hit the wild? > > -chris I will poke at vendors to see if we can get someone to make a public statement, but I cannot do that for them.

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 01:35 PM, James Bottomley wrote: On Wed, 2014-01-22 at 13:17 -0500, Ric Wheeler wrote: On 01/22/2014 01:13 PM, James Bottomley wrote: On Wed, 2014-01-22 at 18:02 +, Chris Mason wrote: On Wed, 2014-01-22 at 09:21 -0800, James Bottomley wrote: On Wed, 2014-01-22 at 17:02

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 01:13 PM, James Bottomley wrote: On Wed, 2014-01-22 at 18:02 +, Chris Mason wrote: On Wed, 2014-01-22 at 09:21 -0800, James Bottomley wrote: On Wed, 2014-01-22 at 17:02 +, Chris Mason wrote: [ I like big sectors and I cannot lie ] I think I might be sceptical, but I

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 11:03 AM, James Bottomley wrote: On Wed, 2014-01-22 at 15:14 +, Chris Mason wrote: On Wed, 2014-01-22 at 09:34 +, Mel Gorman wrote: On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote: One topic that has been lurking forever at the edges is the current 4k

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 09:34 AM, Mel Gorman wrote: On Wed, Jan 22, 2014 at 09:10:48AM -0500, Ric Wheeler wrote: On 01/22/2014 04:34 AM, Mel Gorman wrote: On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote: One topic that has been lurking forever at the edges is the current 4k limitation

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 04:34 AM, Mel Gorman wrote: On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote: One topic that has been lurking forever at the edges is the current 4k limitation for file system block sizes. Some devices in production today and others coming soon have larger sectors

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 04:34 AM, Mel Gorman wrote: On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote: One topic that has been lurking forever at the edges is the current 4k limitation for file system block sizes. Some devices in production today and others coming soon have larger sectors

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 09:34 AM, Mel Gorman wrote: On Wed, Jan 22, 2014 at 09:10:48AM -0500, Ric Wheeler wrote: On 01/22/2014 04:34 AM, Mel Gorman wrote: On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote: One topic that has been lurking forever at the edges is the current 4k limitation

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 11:03 AM, James Bottomley wrote: On Wed, 2014-01-22 at 15:14 +, Chris Mason wrote: On Wed, 2014-01-22 at 09:34 +, Mel Gorman wrote: On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote: One topic that has been lurking forever at the edges is the current 4k

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 01:13 PM, James Bottomley wrote: On Wed, 2014-01-22 at 18:02 +, Chris Mason wrote: On Wed, 2014-01-22 at 09:21 -0800, James Bottomley wrote: On Wed, 2014-01-22 at 17:02 +, Chris Mason wrote: [ I like big sectors and I cannot lie ] I think I might be sceptical, but I

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 01:35 PM, James Bottomley wrote: On Wed, 2014-01-22 at 13:17 -0500, Ric Wheeler wrote: On 01/22/2014 01:13 PM, James Bottomley wrote: On Wed, 2014-01-22 at 18:02 +, Chris Mason wrote: On Wed, 2014-01-22 at 09:21 -0800, James Bottomley wrote: On Wed, 2014-01-22 at 17:02

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

On 01/22/2014 01:37 PM, Chris Mason wrote: Circling back to what we might talk about at the conference, Ric do you have any ideas on when these drives might hit the wild? -chris I will poke at vendors to see if we can get someone to make a public statement, but I cannot do that for them. Ric

[LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

One topic that has been lurking forever at the edges is the current 4k limitation for file system block sizes. Some devices in production today and others coming soon have larger sectors and it would be interesting to see if it is time to poke at this topic again. LSF/MM seems to be pretty

[LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

One topic that has been lurking forever at the edges is the current 4k limitation for file system block sizes. Some devices in production today and others coming soon have larger sectors and it would be interesting to see if it is time to poke at this topic again. LSF/MM seems to be pretty

Re: status of block-integrity

On 12/23/2013 09:35 PM, Martin K. Petersen wrote: "Christoph" == Christoph Hellwig writes: Christoph> We have the block integrity code to support DIF/DIX in the Christoph> the tree for about 5 and a half years, and we still don't Christoph> have a single consumer of it. What do you mean? If

Re: status of block-integrity

On 12/23/2013 09:35 PM, Martin K. Petersen wrote: Christoph == Christoph Hellwig h...@infradead.org writes: Christoph We have the block integrity code to support DIF/DIX in the Christoph the tree for about 5 and a half years, and we still don't Christoph have a single consumer of it. What do

[LSF/MM TOPIC] [ATTEND] persistent memory progress, management of storage & file systems

I would like to attend this year and continue to talk about the work on enabling the new class of persistent memory devices. Specifically, very interested in talking about both using a block driver under our existing stack and also progress at the file system layer (adding xip/mmap tweaks to

[LSF/MM TOPIC] [ATTEND] persistent memory progress, management of storage file systems

I would like to attend this year and continue to talk about the work on enabling the new class of persistent memory devices. Specifically, very interested in talking about both using a block driver under our existing stack and also progress at the file system layer (adding xip/mmap tweaks to

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/23/2013 07:22 PM, Pavel Machek wrote: On Sat 2013-11-23 18:01:32, Ric Wheeler wrote: On 11/23/2013 03:36 PM, Pavel Machek wrote: On Wed 2013-11-20 08:02:33, Howard Chu wrote: Theodore Ts'o wrote: Historically, Intel has been really good about avoiding this, but since they've moved

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/23/2013 03:36 PM, Pavel Machek wrote: On Wed 2013-11-20 08:02:33, Howard Chu wrote: Theodore Ts'o wrote: Historically, Intel has been really good about avoiding this, but since they've moved to using 3rd party flash controllers, I now advise everyone who plans to use any flash storage,

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/23/2013 01:27 PM, Stefan Priebe wrote: Hi Ric, Am 22.11.2013 21:37, schrieb Ric Wheeler: On 11/22/2013 03:01 PM, Stefan Priebe wrote: Hi Christoph, Am 21.11.2013 11:11, schrieb Christoph Hellwig: 2. Some drives may implement CMD_FLUSH to return immediately i.e. no guarantee the data

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/23/2013 01:27 PM, Stefan Priebe wrote: Hi Ric, Am 22.11.2013 21:37, schrieb Ric Wheeler: On 11/22/2013 03:01 PM, Stefan Priebe wrote: Hi Christoph, Am 21.11.2013 11:11, schrieb Christoph Hellwig: 2. Some drives may implement CMD_FLUSH to return immediately i.e. no guarantee the data

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/23/2013 03:36 PM, Pavel Machek wrote: On Wed 2013-11-20 08:02:33, Howard Chu wrote: Theodore Ts'o wrote: Historically, Intel has been really good about avoiding this, but since they've moved to using 3rd party flash controllers, I now advise everyone who plans to use any flash storage,

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/23/2013 07:22 PM, Pavel Machek wrote: On Sat 2013-11-23 18:01:32, Ric Wheeler wrote: On 11/23/2013 03:36 PM, Pavel Machek wrote: On Wed 2013-11-20 08:02:33, Howard Chu wrote: Theodore Ts'o wrote: Historically, Intel has been really good about avoiding this, but since they've moved

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/22/2013 03:01 PM, Stefan Priebe wrote: Hi Christoph, Am 21.11.2013 11:11, schrieb Christoph Hellwig: 2. Some drives may implement CMD_FLUSH to return immediately i.e. no guarantee the data is actually on disk. In which case they aren't spec complicant. While I've seen countless data

Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

On 11/22/2013 03:01 PM, Stefan Priebe wrote: Hi Christoph, Am 21.11.2013 11:11, schrieb Christoph Hellwig: 2. Some drives may implement CMD_FLUSH to return immediately i.e. no guarantee the data is actually on disk. In which case they aren't spec complicant. While I've seen countless data

Re: [PATCH] update xfs maintainers

On 11/08/2013 05:17 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 05:07:45PM -0500, Ric Wheeler wrote: On 11/08/2013 05:03 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: On 11/08/2013 03:46 PM, Ben Myers wrote: Hey Christoph, On Fri, Nov

Re: [PATCH] update xfs maintainers

On 11/08/2013 05:03 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: On 11/08/2013 03:46 PM, Ben Myers wrote: Hey Christoph, On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote

Re: XFS leadership and a new co-maintainer candidate

On 11/08/2013 03:46 PM, Ben Myers wrote: Hey Christoph, On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: Mark is replacing Alex as my backup because Alex is really busy at Linaro and asked to be taken off awhile ago.

Re: XFS leadership and a new co-maintainer candidate

On 11/08/2013 02:34 PM, Christoph Hellwig wrote: On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: Mark is replacing Alex as my backup because Alex is really busy at Linaro and asked to be taken off awhile ago. The holiday season is coming up and I fully intend to go off my meds, turn

Re: XFS leadership and a new co-maintainer candidate

On 11/08/2013 01:03 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 06:03:41AM -0500, Ric Wheeler wrote: In the XFS community, we have 2 clear leaders in terms of contributions of significant feaures and depth of knowledge - Christoph and Dave. If you look at the number of patches

XFS leadership and a new co-maintainer candidate

are going to add a co-maintainer for XFS, we really need to have one of our two leading developers in that role. Best regards, Ric On 11/07/2013 09:23 PM, Ric Wheeler wrote: Hi Ben, How exactly did we decide to add a new co-maintainer? Shouldn't we have some discussion on the list and see some

XFS leadership and a new co-maintainer candidate

for XFS, we really need to have one of our two leading developers in that role. Best regards, Ric On 11/07/2013 09:23 PM, Ric Wheeler wrote: Hi Ben, How exactly did we decide to add a new co-maintainer? Shouldn't we have some discussion on the list and see some substantial history

Re: XFS leadership and a new co-maintainer candidate

On 11/08/2013 01:03 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 06:03:41AM -0500, Ric Wheeler wrote: In the XFS community, we have 2 clear leaders in terms of contributions of significant feaures and depth of knowledge - Christoph and Dave. If you look at the number of patches

Re: XFS leadership and a new co-maintainer candidate

On 11/08/2013 02:34 PM, Christoph Hellwig wrote: On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: Mark is replacing Alex as my backup because Alex is really busy at Linaro and asked to be taken off awhile ago. The holiday season is coming up and I fully intend to go off my meds, turn

Re: XFS leadership and a new co-maintainer candidate

On 11/08/2013 03:46 PM, Ben Myers wrote: Hey Christoph, On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote: Mark is replacing Alex as my backup because Alex is really busy at Linaro and asked to be taken off awhile ago.

Re: [PATCH] update xfs maintainers

On 11/08/2013 05:03 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: On 11/08/2013 03:46 PM, Ben Myers wrote: Hey Christoph, On Fri, Nov 08, 2013 at 11:34:24AM -0800, Christoph Hellwig wrote: On Fri, Nov 08, 2013 at 12:03:37PM -0600, Ben Myers wrote

Re: [PATCH] update xfs maintainers

On 11/08/2013 05:17 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 05:07:45PM -0500, Ric Wheeler wrote: On 11/08/2013 05:03 PM, Ben Myers wrote: Hey Ric, On Fri, Nov 08, 2013 at 03:50:21PM -0500, Ric Wheeler wrote: On 11/08/2013 03:46 PM, Ben Myers wrote: Hey Christoph, On Fri, Nov

Re: [RFC] extending splice for copy offloading

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.

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

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/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

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

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, Sep 30, 2013 at 4:34 PM, J. Bruce Fields bfie...@fieldses.org wrote: My other worry is about interruptibility

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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.

Re: [RFC] extending splice for copy offloading

On 09/28/2013 11:20 AM, Myklebust, Trond wrote: -Original Message- From: Miklos Szeredi [mailto:mik...@szeredi.hu] Sent: Saturday, September 28, 2013 12:50 AM To: Zach Brown Cc: J. Bruce Fields; Ric Wheeler; Anna Schumaker; Kernel Mailing List; Linux- Fsdevel; linux-...@vger.kernel.org

Re: [RFC] extending splice for copy offloading

On 09/28/2013 11:20 AM, Myklebust, Trond wrote: -Original Message- From: Miklos Szeredi [mailto:mik...@szeredi.hu] Sent: Saturday, September 28, 2013 12:50 AM To: Zach Brown Cc: J. Bruce Fields; Ric Wheeler; Anna Schumaker; Kernel Mailing List; Linux- Fsdevel; linux-...@vger.kernel.org

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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:

Re: [RFC] extending splice for copy offloading

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,

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

Re: [RFC] extending splice for copy offloading

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

Re: [GIT PULL] Btrfs

On 09/12/2013 11:36 AM, Chris Mason wrote: Mark Fasheh's offline dedup work is also here. In this case offline means the FS is mounted and active, but the dedup work is not done inline during file IO. This is a building block where utilities are able to ask the FS to dedup a series of

Re: [GIT PULL] Btrfs

On 09/12/2013 11:36 AM, Chris Mason wrote: Mark Fasheh's offline dedup work is also here. In this case offline means the FS is mounted and active, but the dedup work is not done inline during file IO. This is a building block where utilities are able to ask the FS to dedup a series of

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

On 08/23/2013 05:10 AM, Eiichi Tsukata wrote: (2013/08/21 3:09), Ewan Milne wrote: On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote: (2013/08/19 23:30), James Bottomley wrote: On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote: Hello, This patch adds scsi device failfast mode to

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

On 08/23/2013 05:10 AM, Eiichi Tsukata wrote: (2013/08/21 3:09), Ewan Milne wrote: On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote: (2013/08/19 23:30), James Bottomley wrote: On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote: Hello, This patch adds scsi device failfast mode to

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

On 07/20/2013 01:04 PM, Ben Hutchings wrote: n Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote: >On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar wrote: > > > >* Felipe Contreras wrote: > > >>As Linus already pointed out, not everybody has to work with everybody. > > > >That's not the

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

On 07/20/2013 01:04 PM, Ben Hutchings wrote: n Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote: On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnarmi...@kernel.org wrote: * Felipe Contrerasfelipe.contre...@gmail.com wrote: As Linus already pointed out, not everybody has to work with

Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion

On 07/17/2013 12:52 AM, James Bottomley wrote: On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote: On Tue, Jul 16 2013, Nicholas A. Bellinger wrote: On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote: On 07/12/2013 03:33 AM,

Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion

On 07/17/2013 12:52 AM, James Bottomley wrote: On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote: On Tue, Jul 16 2013, Nicholas A. Bellinger wrote: On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote: On 07/12/2013 03:33 AM,

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

On 07/16/2013 07:53 PM, Myklebust, Trond wrote: On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote: On 07/16/2013 07:12 PM, Sarah Sharp wrote: On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote: On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote: Yes, that's true. Some

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

On 07/16/2013 07:12 PM, Sarah Sharp wrote: On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote: On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote: Yes, that's true. Some kernel developers are better at moderating their comments and tone towards individuals who are "sensitive".

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

On 07/16/2013 07:12 PM, Sarah Sharp wrote: On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote: On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote: Yes, that's true. Some kernel developers are better at moderating their comments and tone towards individuals who are sensitive.

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

On 07/16/2013 07:53 PM, Myklebust, Trond wrote: On Tue, 2013-07-16 at 19:31 -0400, Ric Wheeler wrote: On 07/16/2013 07:12 PM, Sarah Sharp wrote: On Tue, Jul 16, 2013 at 06:54:59PM -0400, Steven Rostedt wrote: On Tue, 2013-07-16 at 15:43 -0700, Sarah Sharp wrote: Yes, that's true. Some

Re: [RFC v0 1/4] vfs: add copy_range syscall and vfs entry point

On 05/15/2013 04:03 PM, Zach Brown wrote: On Wed, May 15, 2013 at 07:44:05PM +, Eric Wong wrote: Why introduce a new syscall instead of extending sys_splice? Personally, I think it's ugly to have different operations use the same syscall just because their arguments match. I agree with

Re: [RFC v0 1/4] vfs: add copy_range syscall and vfs entry point

On 05/15/2013 04:03 PM, Zach Brown wrote: On Wed, May 15, 2013 at 07:44:05PM +, Eric Wong wrote: Why introduce a new syscall instead of extending sys_splice? Personally, I think it's ugly to have different operations use the same syscall just because their arguments match. I agree with

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

On 03/31/2013 07:18 PM, Pavel Machek wrote: Hi! Take a look at how many actively used filesystems out there that have some variant of sillyrename(), and explain what you want to do in those cases. Well. Yes, there are non-unix filesystems around. You have to deal with silly files on them, and

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

On 03/31/2013 06:50 PM, Pavel Machek wrote: On Sun 2013-03-31 18:44:53, Myklebust, Trond wrote: On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote: Hmm. open_deleted_file() will still need to get a directory... so it will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would be

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

On 03/31/2013 06:50 PM, Pavel Machek wrote: On Sun 2013-03-31 18:44:53, Myklebust, Trond wrote: On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote: Hmm. open_deleted_file() will still need to get a directory... so it will still need a path. Perhaps open(/foo/bar/mnt, O_DELETED) would be

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

On 03/31/2013 07:18 PM, Pavel Machek wrote: Hi! Take a look at how many actively used filesystems out there that have some variant of sillyrename(), and explain what you want to do in those cases. Well. Yes, there are non-unix filesystems around. You have to deal with silly files on them, and

Re: New copyfile system call - discuss before LSF?

On 03/30/2013 05:57 PM, Myklebust, Trond wrote: On Mar 30, 2013, at 5:45 PM, Pavel Machek wrote: On Sat 2013-03-30 13:08:39, Andreas Dilger wrote: On 2013-03-30, at 12:49 PM, Pavel Machek wrote: Hmm, really? AFAICT it would be simple to provide an open_deleted_file("directory") syscall.

Re: New copyfile system call - discuss before LSF?

On 03/30/2013 05:57 PM, Myklebust, Trond wrote: On Mar 30, 2013, at 5:45 PM, Pavel Machek pa...@ucw.cz wrote: On Sat 2013-03-30 13:08:39, Andreas Dilger wrote: On 2013-03-30, at 12:49 PM, Pavel Machek wrote: Hmm, really? AFAICT it would be simple to provide an open_deleted_file(directory)

Re: New copyfile system call - discuss before LSF?

On 02/25/2013 04:14 PM, Andy Lutomirski wrote: On 02/21/2013 02:24 PM, Zach Brown wrote: On Thu, Feb 21, 2013 at 08:50:27PM +, Myklebust, Trond wrote: On Thu, 2013-02-21 at 21:00 +0100, Paolo Bonzini wrote: Il 21/02/2013 15:57, Ric Wheeler ha scritto: sendfile64() pretty much already has

Re: New copyfile system call - discuss before LSF?

On 02/25/2013 04:14 PM, Andy Lutomirski wrote: On 02/21/2013 02:24 PM, Zach Brown wrote: On Thu, Feb 21, 2013 at 08:50:27PM +, Myklebust, Trond wrote: On Thu, 2013-02-21 at 21:00 +0100, Paolo Bonzini wrote: Il 21/02/2013 15:57, Ric Wheeler ha scritto: sendfile64() pretty much already has

Re: New copyfile system call - discuss before LSF?

On 02/22/2013 10:47 AM, Paolo Bonzini wrote: Il 21/02/2013 23:24, Zach Brown ha scritto: You could make it work with some locking and out_fd seeking to set the write offset before calling sendfile64()+flags, but ugh. ssize_t sendfile(int out_fd, int in_fd, off_t in_offset, off_t

Re: New copyfile system call - discuss before LSF?

On 02/21/2013 11:13 PM, Myklebust, Trond wrote: On Thu, 2013-02-21 at 23:05 +0100, Ric Wheeler wrote: On 02/21/2013 09:00 PM, Paolo Bonzini wrote: Il 21/02/2013 15:57, Ric Wheeler ha scritto: sendfile64() pretty much already has the right arguments for a "copyfile", however it wou

Re: New copyfile system call - discuss before LSF?

On 02/21/2013 11:13 PM, Myklebust, Trond wrote: On Thu, 2013-02-21 at 23:05 +0100, Ric Wheeler wrote: On 02/21/2013 09:00 PM, Paolo Bonzini wrote: Il 21/02/2013 15:57, Ric Wheeler ha scritto: sendfile64() pretty much already has the right arguments for a copyfile, however it would be nice

Re: New copyfile system call - discuss before LSF?

On 02/22/2013 10:47 AM, Paolo Bonzini wrote: Il 21/02/2013 23:24, Zach Brown ha scritto: You could make it work with some locking and out_fd seeking to set the write offset before calling sendfile64()+flags, but ugh. ssize_t sendfile(int out_fd, int in_fd, off_t in_offset, off_t

Re: New copyfile system call - discuss before LSF?

On 02/21/2013 09:00 PM, Paolo Bonzini wrote: Il 21/02/2013 15:57, Ric Wheeler ha scritto: sendfile64() pretty much already has the right arguments for a "copyfile", however it would be nice to add a 'flags' parameter: the NFSv4.2 version would use that to specify whether or not to

  1   2   >