Received: by 10.223.185.116 with SMTP id b49csp3801619wrg; Tue, 13 Feb 2018 08:00:24 -0800 (PST) X-Google-Smtp-Source: AH8x224j8r1pR8oQPnt/mwACEW1twPG+yxFsrgnf32HvIJpjZ615Vq+CCO486k8hQqUmmRMdInr7 X-Received: by 10.99.139.199 with SMTP id j190mr1377302pge.334.1518537624386; Tue, 13 Feb 2018 08:00:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518537624; cv=none; d=google.com; s=arc-20160816; b=QtmkRrc18bdrrxnY+ybTVVGHeGHr/Iod1gqs5H4fUlbGHJ+aW7b8toxFKnp+hfrf2d LtjlLtT+2V9wVUve4zm9nvR759CkegRVuUgiBHpOK2kK3qRhjDXdF2X7f6kOmAXzTTXw O3qbqI6XhInJw/E1jQ/wGMYT6I2SC5ad8aJjaRc+7kN31xw8kLQb7w1MjaozlGF3ytSc opsKEN4MzLBR5t6mTfP9RTUShd/3txtwfcijsnxMOJC7Ow0HEHZHScyRBya21+87huQi kwFZ/ai4JNqAG+3DhUg2xbqcqmXX5gNRmwcrlIMmNXtVz32/4P1jzFAGdDh7la+6Srx2 N/rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ALEDhoix5oN+N5w4edMIwty1Zk2ENx9aFJx1TbWD85s=; b=JysQRiBDempeYXM01nmjdkdJ3HCk8D8/+Nxayjh1/rbg6YFzIxKXeCLJkUghRjZQ+b T+lVc5a6xpYr47PTcYDWCWb0x7UwFZjhbUt+Q12bUOwo5tbKm04euSQxQB7nHBBzbDoQ i7FO4x7gWUYsCKgBMQR00YGX2S2dd+eNfYwbtydqEhcodFMgfggD25e7zZ7CfjMHCPzC HqFPOy6b25KSGzP5A5Xxnw1y415J5L63q9Am6dWIEmJAS+gJI5tfn5cqLCk66CbCcR1s cU3r5LJ2dgahpzdM016Spd49vUt93ntIVoeUrxK4w7IYrYa9dRThY4XJNgSHHignsPnE aBzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=a5hs+V2f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o2si6704996pgq.565.2018.02.13.08.00.09; Tue, 13 Feb 2018 08:00:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=a5hs+V2f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933974AbeBMP5k (ORCPT + 99 others); Tue, 13 Feb 2018 10:57:40 -0500 Received: from mail-ot0-f169.google.com ([74.125.82.169]:46316 "EHLO mail-ot0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933440AbeBMP5j (ORCPT ); Tue, 13 Feb 2018 10:57:39 -0500 Received: by mail-ot0-f169.google.com with SMTP id w10so4163627ote.13 for ; Tue, 13 Feb 2018 07:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ALEDhoix5oN+N5w4edMIwty1Zk2ENx9aFJx1TbWD85s=; b=a5hs+V2fvwWIrcTteh3A2PqUdW3MEXae3Kl8mwJrFJUihFI9fY1Bnx1sIMwBd32HSP CmF4M10WYaAYWv5FtkEWp/2WaveBgY4SGHT+RmzuCY9OUAkuJ2sT0gFVV0o44fm/dSCl oDE/ciwP11buv57gleQ4lAuQtilAradBKn+ZtWHMkc3ubuOyw2+YAV7NnyWGrpEWLMyn 8vaQ2FezmGjpExU6/7tzSXnSYaz6Uf/znmMkORHIjtDme1SfGJgHvfjtka8ZQ1dTHINU EvohG5CsUhTRXMdhV3WdyViMMCUERoq5J17+1Z65IPvKkeC3sArCDeLl9YY/04Js+FeQ v/kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ALEDhoix5oN+N5w4edMIwty1Zk2ENx9aFJx1TbWD85s=; b=ktTowOHk3LyNCDzjS99oYgdqYRZp942kQiXrKA/ODwpbprWqCGge18v4A/nFIHgFoa MwG+jz4bigSyo1Pg8O5bC42EpQm0pU4l6Xi5m6ffVKOlrQMAEtORgt/ybOwWt2Wmu/ob xJYleIIApuJofMTJM2u/UpFLfoI6ad2GB6JEcLa5AS26vu4vw87xyy/bMYLIQ8uFMhxU YrKZKowbKfckl1O3T/QPUrP+o0J65xFZziYB8x9JcLBXt6dfb1zB1obcNDR2TIoLgvvB Ft6KbItr3Js6UZ62QXEdd9676vtyRlqIiQPWpLF5r3/WApC4sjdWbfRkoPn7GX2y7Eai FHQg== X-Gm-Message-State: APf1xPChpWaORQ22pTrHBdGhfNcuAENhlxDrOBN4ae26l0neuhyK/Xfq cvRTrqfO9tNcOR00SnRcDbttweKgS4WkuqVsC4zf5g== X-Received: by 10.157.37.110 with SMTP id j43mr1140193otd.184.1518537457965; Tue, 13 Feb 2018 07:57:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.17.211 with HTTP; Tue, 13 Feb 2018 07:57:36 -0800 (PST) In-Reply-To: References: <151847194459.58291.11339638808076622981.stgit@djiang5-desk3.ch.intel.com> From: Dan Williams Date: Tue, 13 Feb 2018 07:57:36 -0800 Message-ID: Subject: Re: [PATCH v2] libnvdimm: re-enable deep flush for pmem devices To: Jeff Moyer Cc: Dave Jiang , "Zwisler, Ross" , Linux Kernel Mailing List , linux-nvdimm@lists.01.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 13, 2018 at 5:17 AM, Jeff Moyer wrote: > Dan Williams writes: > >> On Mon, Feb 12, 2018 at 2:53 PM, Jeff Moyer wrote: >>> Dave Jiang writes: >>> >>>> Re-enable deep flush so that users always have a way to be sure that a write >>>> does make it all the way out to the NVDIMM. The PMEM driver writes always >>>> make it "all the way to the NVDIMM", and it relies on the ADR mechanism to >>>> flush the write buffers on power failure. Deep flush is there to explicitly >>>> flush those write buffers to protect against (rare) ADR failure. >>>> This change prevents a regression in deep flush behavior so that applications >>>> can continue to depend on fsync() as a mechanism to trigger deep flush in the >>>> filesystem-dax case. >>> >>> That's still very confusing text. Specifically, the part where you say >>> that pmem driver writes always make it to the DIMM. I think the >>> changelog could start with "Deep flush is there to explicitly flush >>> write buffers...." Anyway, the fix looks right to me. >> >> I ended up changing the commit message to this, let me know if it reads better: > > Thanks. It's still unclear to me what the text, "The PMEM driver writes > always arrive at the NVDIMM" means. However, it's good enough. Yeah, Dave, had similar feedback. A better way of saying it is that the writes always arrive at the persistence domain, but deep flush pushes them to the smallest platform failure domain. On current platforms that's to the ADR domain and past the ADR domain.