From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758945AbcLPCkx (ORCPT ); Thu, 15 Dec 2016 21:40:53 -0500 Received: from mail-oi0-f54.google.com ([209.85.218.54]:36685 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754171AbcLPCkp (ORCPT ); Thu, 15 Dec 2016 21:40:45 -0500 MIME-Version: 1.0 In-Reply-To: References: <148143770485.10950.13227732273892953675.stgit@dwillia2-desk3.amr.corp.intel.com> From: Dan Williams Date: Thu, 15 Dec 2016 18:33:50 -0800 Message-ID: Subject: Re: [PATCH 0/8] device-dax: sub-division support To: Jeff Moyer Cc: linux-nvdimm , "linux-kernel@vger.kernel.org" , Dave Hansen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 15, 2016 at 3:48 PM, Dan Williams wrote: > On Thu, Dec 15, 2016 at 8:50 AM, Jeff Moyer wrote: [..] > As for sub-division it was designed for the volatile case, I've heard > feedback that some want it for the pmem case. You and I agree that > it's *not* a good interface for the pmem case, so I'm fine disabling > sub-division and telling them that they need to override a kernel > default to use this mechanism for pmem, but otherwise say "just use > libnvdimm namespace labels" for storage use cases. So I went to go add support for making sub-division default off and zero-size the initial device when sub-division is enabled. However, if the policy is that the initial device is zero-sized for safety then, for safety, we need to remember if the dax-region was *ever* in dynamic mode to make sure that moving to dynamic mode is a one way street. If we're persisting the region setting then we might as well be persisting the device-dax sub-division decisions. At that point we might as well just wait for libnvdimm to grow namespace label support for all NVDIMM types and let the provisioning happen at the level that we agree is the right level for pmem. Long story short, you're right, a volatile provisioning mechanism is only tenable for volatile media. This enabling should wait until a volatile consumer of device-dax surfaces, the dax_pmem driver should never use it.