Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753295AbdF2UmX (ORCPT ); Thu, 29 Jun 2017 16:42:23 -0400 Received: from mail-yw0-f182.google.com ([209.85.161.182]:33122 "EHLO mail-yw0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752850AbdF2UmU (ORCPT ); Thu, 29 Jun 2017 16:42:20 -0400 MIME-Version: 1.0 In-Reply-To: <595552F5.5040008@hpe.com> References: <149875877608.10031.17813337234536358002.stgit@dwillia2-desk3.amr.corp.intel.com> <149875884190.10031.6179599135820559644.stgit@dwillia2-desk3.amr.corp.intel.com> <595552F5.5040008@hpe.com> From: Dan Williams Date: Thu, 29 Jun 2017 13:42:19 -0700 Message-ID: Subject: Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges To: Linda Knippers Cc: "linux-nvdimm@lists.01.org" , Jan Kara , Matthew Wilcox , X86 ML , "linux-kernel@vger.kernel.org" , Al Viro , linux-fsdevel , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1637 Lines: 31 On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote: > On 06/29/2017 01:54 PM, Dan Williams wrote: >> Allow volatile nfit ranges to participate in all the same infrastructure >> provided for persistent memory regions. > > This seems to be a bit more than "other rework". It's part of the rationale for having a "write_cache" control attribute. There's only so much I can squeeze into the subject line, but it is mentioned in the cover letter. >> A resulting resulting namespace >> device will still be called "pmem", but the parent region type will be >> "nd_volatile". > > What does this look like to a user or admin? How does someone know that > /dev/pmemX is persistent memory and /dev/pmemY isn't? Someone shouldn't > have to weed through /sys or ndctl some other interface to figure that out > in the future if they don't have to do that today. We have different > names for BTT namespaces. Is there a different name for volatile ranges? No, the block device name is still /dev/pmem. It's already the case that you need to check behind just the name of the device to figure out if something is actually volatile or not (see memmap=ss!nn configurations), so I would not be in favor of changing the device name if we think the memory might not be persistent. Moreover, I think it was a mistake that we change the device name for btt or not, and I'm glad Matthew talked me out of making the same mistake with memory-mode vs raw-mode pmem namespaces. So, the block device name just reflects the driver of the block device, not the properties of the device, just like all other block device instances.