From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f199.google.com (mail-ot0-f199.google.com [74.125.82.199]) by kanga.kvack.org (Postfix) with ESMTP id A63F26B0279 for ; Thu, 22 Jun 2017 00:08:20 -0400 (EDT) Received: by mail-ot0-f199.google.com with SMTP id o27so3525787otd.15 for ; Wed, 21 Jun 2017 21:08:20 -0700 (PDT) Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id j8si115030otb.384.2017.06.21.21.08.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 21:08:19 -0700 (PDT) Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CDF1A22B66 for ; Thu, 22 Jun 2017 04:08:18 +0000 (UTC) Received: by mail-ua0-f172.google.com with SMTP id g40so4603531uaa.3 for ; Wed, 21 Jun 2017 21:08:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170622000235.GN17542@dastard> References: <20170619132107.GG11993@dastard> <20170620004653.GI17542@dastard> <20170620101145.GJ17542@dastard> <20170621014032.GL17542@dastard> <20170622000235.GN17542@dastard> From: Andy Lutomirski Date: Wed, 21 Jun 2017 21:07:57 -0700 Message-ID: Subject: Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Dave Chinner Cc: Andy Lutomirski , Dan Williams , Ross Zwisler , "Rudoff, Andy" , Andrew Morton , Jan Kara , linux-nvdimm , Linux API , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Jeff Moyer , Linux FS Devel , Christoph Hellwig On Wed, Jun 21, 2017 at 5:02 PM, Dave Chinner wrote: > > You seem to be calling the "fdatasync on every page fault" the It's the opposite of fdatasync(). It needs to sync whatever metadata is needed to find the data. The data doesn't need to be synced. > "lightweight" option. That's the brute-force-with-big-hammer > solution - it's most definitely not lightweight as every page fault > has extra overhead to call ->fsync(). Sure, the API is simple, but > the runtime overhead is significant. It's lightweight in terms of its impact on the filesystem. It doesn't need any persistent setup -- you can just use it. > Even if you are considering the complexity of the APIs, it's hardly > a "heavyweight" when it only requires a single call to fallocate() > before mmap() to set up the immutable extents on the file... So what would the exact semantics be? In particular, how can it fail? If I do the fallocate(), is it absolutely promised that the extent map won't get out of sync between what mmap sees and what's on disk? Do user programs need to worry about colliding with each other when one does fallocate() to DAXify a file and the other does fallocate() to unDAXify a file? Does this particular fallocate() call still keep its effect after a reboot? These issues are why I think it would be nicer to have an API that makes a particular mapping or fd be unconditionally *correct* and then to provide something else that makes it avoid latency spikes. Is there an actual concrete proposal that's reviewable? -- 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