Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752375AbdLLTYr (ORCPT ); Tue, 12 Dec 2017 14:24:47 -0500 Received: from mga18.intel.com ([134.134.136.126]:39141 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752102AbdLLTYq (ORCPT ); Tue, 12 Dec 2017 14:24:46 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,395,1508828400"; d="scan'208";a="15432900" Date: Tue, 12 Dec 2017 12:02:51 -0700 From: Scott Bauer To: Mike Snitzer Cc: dm-devel@redhat.com, agk@redhat.com, linux-kernel@vger.kernel.org, keith.busch@intel.com, jonathan.derrick@intel.com Subject: Re: [PATCH v2 2/2] dm unstripe: Add documentation for unstripe target Message-ID: <20171212190250.y2wxdyfcb2kgr32d@sbauer-Z170X-UD5> References: <20171211160019.20518-1-scott.bauer@intel.com> <20171211160019.20518-3-scott.bauer@intel.com> <20171212181012.GA31127@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171212181012.GA31127@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1565 Lines: 33 On Tue, Dec 12, 2017 at 01:10:13PM -0500, Mike Snitzer wrote: > On Mon, Dec 11 2017 at 11:00am -0500, > Scott Bauer wrote: > > OK, but I'm left wondering: why doesn't the user avoid striping across > the cores? > > Do the Intel NVMe drives not provide the ability to present 1 device per > NVMe core? > > This DM target seems like a pretty nasty workaround for what should be > fixed in the NVMe drive's firmware. > > Mainly because there is no opportunity to use both striped and unstriped > access to the same NVMe drive. So why impose striped on the user in the > first place? > > Mike Unfortunately, the NVMe drives do not currently support exposing each core as seperate drives or namespaces. While it would be preferable if the controllers did expose such features, firmware development informed us there are sufficient reasons why it isn't possible for the existing generation of drives. The NVMe working group just finalized a standard that presents isolated storage sets for users who wish to use them. As the standard was just recently finalized the use case was created well after the targeted drives were created. The Intel drives just so happen to have independent back-ends that align with the isolated storage sets use case. We would like to provide a way to exploit the independent back-ends to expose isolated storage in a way that is generic across all the Intel NVMe drive familes. The implementation is generic enough that it can be applied to any storage that has physical seperation at known block boundaries.