linux-kernel - Re: [PATCH v2 2/2] dm unstripe: Add documentation for unstripe target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 12 Dec 2017 12:02:51 -0700
From:   Scott Bauer <scott.bauer@...el.com>
To:     Mike Snitzer <snitzer@...hat.com>
Cc:     dm-devel@...hat.com, agk@...hat.com, linux-kernel@...r.kernel.org,
        keith.busch@...el.com, jonathan.derrick@...el.com
Subject: Re: [PATCH v2 2/2] dm unstripe: Add documentation for unstripe target

On Tue, Dec 12, 2017 at 01:10:13PM -0500, Mike Snitzer wrote:
> On Mon, Dec 11 2017 at 11:00am -0500,
> Scott Bauer <scott.bauer@...el.com> 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.