From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937076AbdDZUjO (ORCPT ); Wed, 26 Apr 2017 16:39:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59568 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936718AbdDZUjF (ORCPT ); Wed, 26 Apr 2017 16:39:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0265380044 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jmoyer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0265380044 From: Jeff Moyer To: Dan Williams Cc: linux-nvdimm@ml01.01.org, Masayoshi Mizuma , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush() References: <149307780135.7155.11108531648914675756.stgit@dwillia2-desk3.amr.corp.intel.com> <149315140303.23340.14688142799059150805.stgit@dwillia2-desk3.amr.corp.intel.com> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Wed, 26 Apr 2017 16:38:54 -0400 In-Reply-To: <149315140303.23340.14688142799059150805.stgit@dwillia2-desk3.amr.corp.intel.com> (Dan Williams's message of "Tue, 25 Apr 2017 13:17:37 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 26 Apr 2017 20:39:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dan Williams writes: > The nvdimm_flush() mechanism helps to reduce the impact of an ADR > (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing > platform WPQ (write-pending-queue) buffers when power is removed. The > nvdimm_flush() mechanism performs that same function on-demand. > > When a pmem namespace is associated with a block device, an > nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH > request. These requests are typically associated with filesystem > metadata updates. However, when a namespace is in device-dax mode, > userspace (think database metadata) needs another path to perform the > same flushing. In other words this is not required to make data > persistent, but in the case of metadata it allows for a smaller failure > domain in the unlikely event of an ADR failure. > > The new 'flush' attribute is visible when the individual DIMMs backing a > given interleave-set are described by platform firmware. In ACPI terms > this is "NVDIMM Region Mapping Structures" and associated "Flush Hint > Address Structures". Reads return "1" if the region supports triggering > WPQ flushes on all DIMMs. Reads return "0" the flush operation is a > platform nop, and in that case the attribute is read-only. I can make peace with exposing this to userspace, though I am mostly against its use. However, sysfs feels like the wrong interface. Believe it or not, I'd rather see this implemented as an ioctl. This isn't a NACK, it's me giving my opinion. Do with it what you will. Cheers, Jeff