From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: [LSF/MM TOPIC] Future direction of DAX Date: Tue, 17 Jan 2017 09:54:27 -0500 Message-ID: References: <20170114002008.GA25379@linux.intel.com> <20170114082621.GC10498@birch.djwong.org> <20170117015033.GD10498@birch.djwong.org> <20170117075735.GB19654@infradead.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20170117075735.GB19654@infradead.org> (Christoph Hellwig's message of "Mon, 16 Jan 2017 23:57:35 -0800") Sender: linux-block-owner@vger.kernel.org To: Christoph Hellwig Cc: "Darrick J. Wong" , Ross Zwisler , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org, linux-block@vger.kernel.org, linux-mm@kvack.org List-Id: linux-nvdimm@lists.01.org Christoph Hellwig writes: > On Mon, Jan 16, 2017 at 05:50:33PM -0800, Darrick J. Wong wrote: >> I wouldn't consider it a barrier in general (since ext4 also prints >> EXPERIMENTAL warnings for DAX), merely one for XFS. I don't even think >> it's that big of a hurdle -- afaict XFS ought to be able to achieve this >> by modifying iomap_begin to allocate new pmem blocks, memcpy the >> contents, and update the memory mappings. I think. Ah, I wasn't even thinking about non PMEM_IMMUTABLE usage. > Yes, and I have a working prototype for that. I'm just way to busy > with lots of bugfixing at the moment but I plan to get to it in this > merge window. I also agree that we can't mark a feature as fully > supported until it doesn't conflict with other features. Fair enough. > And I'm not going to get start on the PMEM_IMMUTABLE bullshit, please > don't even go there folks, it's a dead end. I spoke with Dave before the holidays, and he indicated that PMEM_IMMUTABLE would be an acceptable solution to allowing applications to flush data completely from userspace. I know this subject has been beaten to death, but would you mind just summarizing your opinion on this one more time? I'm guessing this will be something more easily hashed out at LSF, though. Thanks, Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Jeff Moyer To: Christoph Hellwig Cc: "Darrick J. Wong" , Ross Zwisler , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org, linux-block@vger.kernel.org, linux-mm@kvack.org Subject: Re: [LSF/MM TOPIC] Future direction of DAX References: <20170114002008.GA25379@linux.intel.com> <20170114082621.GC10498@birch.djwong.org> <20170117015033.GD10498@birch.djwong.org> <20170117075735.GB19654@infradead.org> Date: Tue, 17 Jan 2017 09:54:27 -0500 In-Reply-To: <20170117075735.GB19654@infradead.org> (Christoph Hellwig's message of "Mon, 16 Jan 2017 23:57:35 -0800") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: Christoph Hellwig writes: > On Mon, Jan 16, 2017 at 05:50:33PM -0800, Darrick J. Wong wrote: >> I wouldn't consider it a barrier in general (since ext4 also prints >> EXPERIMENTAL warnings for DAX), merely one for XFS. I don't even think >> it's that big of a hurdle -- afaict XFS ought to be able to achieve this >> by modifying iomap_begin to allocate new pmem blocks, memcpy the >> contents, and update the memory mappings. I think. Ah, I wasn't even thinking about non PMEM_IMMUTABLE usage. > Yes, and I have a working prototype for that. I'm just way to busy > with lots of bugfixing at the moment but I plan to get to it in this > merge window. I also agree that we can't mark a feature as fully > supported until it doesn't conflict with other features. Fair enough. > And I'm not going to get start on the PMEM_IMMUTABLE bullshit, please > don't even go there folks, it's a dead end. I spoke with Dave before the holidays, and he indicated that PMEM_IMMUTABLE would be an acceptable solution to allowing applications to flush data completely from userspace. I know this subject has been beaten to death, but would you mind just summarizing your opinion on this one more time? I'm guessing this will be something more easily hashed out at LSF, though. Thanks, Jeff -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org