From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D989EC388F9 for ; Wed, 21 Oct 2020 16:24:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3EF83222C8 for ; Wed, 21 Oct 2020 16:24:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="qAnN66Pp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3EF83222C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4A2626B005D; Wed, 21 Oct 2020 12:24:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 452AB6B0068; Wed, 21 Oct 2020 12:24:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36A666B006C; Wed, 21 Oct 2020 12:24:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id 096376B005D for ; Wed, 21 Oct 2020 12:24:32 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A1695181AC9C6 for ; Wed, 21 Oct 2020 16:24:32 +0000 (UTC) X-FDA: 77396455584.25.wool71_120e34327249 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id C9E811804E3AD for ; Wed, 21 Oct 2020 16:24:19 +0000 (UTC) X-HE-Tag: wool71_120e34327249 X-Filterd-Recvd-Size: 5096 Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Wed, 21 Oct 2020 16:24:18 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id md26so4075990ejb.10 for ; Wed, 21 Oct 2020 09:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3gOwLOinKxfS8Q7pKCJNt4sF+c6ZgP4dy5YmMvKFVL4=; b=qAnN66PpKcpHn9YzLKihJgVOkQ9RiPSnoahXPav8UFjfvTvYdnOJugMx+Fd4ph9kHp Oro5Qq1x7si+5H+KJWJevoJW2PHn8HhJAqRLzFSXOSgl79BDmY2AGJXBq0iiIUil78+M QysAFxNAXgaq/Mfg5kA/0QDMB4VRDlGFuK1DSc+fErnKb3L0gfZ+4VEFg0V7CyQQ7Myx qeo8gGSTenyT+jW3xqn8pKqyQzwMS+8RqvOWuqowUB5/1uULNeDD9IyXJHsQOwlNL0h6 4SoyROAEGF6wAKzdCiIMKhtkonzXdK+mP6RB+X4yyJd9uj4fp1tIq731Z14sHGErjeC2 4AlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3gOwLOinKxfS8Q7pKCJNt4sF+c6ZgP4dy5YmMvKFVL4=; b=k4jT7n2MWplmywu3ZU9zAXTo+dCEEV7A4gVGJE3oD/gKMYREio7Lq//ctyYHRCgS6+ KKu+vZ83DdLdv2UuuqJ+b0ZGj3ypZFWcmOy+LRNRCnmBMVFRnyh6xdiDndcWMbSU3rg/ i1NnkuZPG4AqpIYmIB2I3VgX/FcdnXvBaPrDlFpS+Mn8pUjZHCm3hzjmkBY9O6S0Id96 UIkVqh8BBMUGGCOTsu1bUN3lvBsL6HZaZTh1OUpNnFSnZD/j+e++mdPcsAKFSDXHujxm ebB1Usmh1rMG+F05F56QU022epyPKd9+Nz5ZCwxv8UQ8tMda3Tdh7TecPgHd4UaZHo0Y gIlw== X-Gm-Message-State: AOAM532p4hJ9INrcyjTMc/g8z0JsoDDDOxQRPKma4+KgbtqEmjSZc7fz hlbfLzmVcua9c9zF2+2JLuYL2sWB4qRUwZ8bUHkpAA== X-Google-Smtp-Source: ABdhPJxdbZlz7qjHcsJyG3VwrTEzzzv1Xnm7a3x75REVedoliNewQfm4hBXe15u3vhqNhzOv2lGigBFvNc+AOMCjKO4= X-Received: by 2002:a17:906:c20f:: with SMTP id d15mr4164002ejz.341.1603297457480; Wed, 21 Oct 2020 09:24:17 -0700 (PDT) MIME-Version: 1.0 References: <20201012162736.65241-1-nmeeramohide@micron.com> <20201015080254.GA31136@infradead.org> In-Reply-To: From: Dan Williams Date: Wed, 21 Oct 2020 09:24:06 -0700 Message-ID: Subject: Re: [EXT] Re: [PATCH v2 00/22] add Object Storage Media Pool (mpool) To: Mike Snitzer Cc: "Nabeel Meeramohideen Mohamed (nmeeramohide)" , Christoph Hellwig , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-nvme@lists.infradead.org" , "linux-mm@kvack.org" , "linux-nvdimm@lists.01.org" , "Steve Moyer (smoyer)" , "Greg Becker (gbecker)" , "Pierre Labat (plabat)" , "John Groves (jgroves)" , device-mapper development Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 21, 2020 at 7:24 AM Mike Snitzer wrote: > > Hey Dan, > > On Fri, Oct 16, 2020 at 6:38 PM Dan Williams wrote: > > > > On Fri, Oct 16, 2020 at 2:59 PM Nabeel Meeramohideen Mohamed > > (nmeeramohide) wrote: > > > > > (5) Representing an mpool as a /dev/mpool/ device file provides a > > > convenient mechanism for controlling access to and managing the multiple storage > > > volumes, and in the future pmem devices, that may comprise an logical mpool. > > > > Christoph and I have talked about replacing the pmem driver's > > dependence on device-mapper for pooling. > > Was this discussion done publicly or private? If public please share > a pointer to the thread. > > I'd really like to understand the problem statement that is leading to > pursuing a pmem native alternative to existing DM. > IIRC it was during the hallway track at a conference. Some of the concern is the flexibility to carve physical address space but not attach a block-device in front of it, and allow pmem/dax-capable filesystems to mount on something other than a block-device. DM does fit the bill for block-device concatenation and striping, but there's some pressure to have a level of provisioning beneath that. The device-dax facility has already started to grow some physical address space partitioning capabilities this cycle, see 60e93dc097f7 device-dax: add dis-contiguous resource support, and the question becomes when / if that support needs to extend across regions is DM the right tool for that?