linux-kernel - Re: [PATCH v8 05/10] block: Add core atomic write support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZnHDCYiRA9EvuLTc@kbusch-mbp.dhcp.thefacebook.com>
Date: Tue, 18 Jun 2024 11:25:29 -0600
From: Keith Busch <kbusch@...nel.org>
To: John Garry <john.g.garry@...cle.com>
Cc: Christoph Hellwig <hch@....de>, axboe@...nel.dk, sagi@...mberg.me,
	jejb@...ux.ibm.com, martin.petersen@...cle.com,
	viro@...iv.linux.org.uk, brauner@...nel.org, dchinner@...hat.com,
	jack@...e.cz, djwong@...nel.org, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
	linux-fsdevel@...r.kernel.org, tytso@....edu, jbongio@...gle.com,
	linux-scsi@...r.kernel.org, ojaswin@...ux.ibm.com,
	linux-aio@...ck.org, linux-btrfs@...r.kernel.org,
	io-uring@...r.kernel.org, nilay@...ux.ibm.com,
	ritesh.list@...il.com, willy@...radead.org, agk@...hat.com,
	snitzer@...nel.org, mpatocka@...hat.com, dm-devel@...ts.linux.dev,
	hare@...e.de, Himanshu Madhani <himanshu.madhani@...cle.com>
Subject: Re: [PATCH v8 05/10] block: Add core atomic write support

On Tue, Jun 18, 2024 at 08:46:31AM +0100, John Garry wrote:
> 
> About NVMe, the spec says that NABSN and NOIOB may not be related to one
> another (command set spec 1.0d 5.8.2.1), but I am wondering if people really
> build HW which would have different NABSN/NABSPF and NOIOB. I don't know.

The history of NOIOB is from an nvme drive that had two back-end
controllers with their own isolated storage, and then striped together
on the front end for the host to see. A command crossing the stripe
boundary takes a slow path to split it for each backend controller's
portion and merge the results. Subsequent implementations may have
different reasons for advertising this boundary, but that was the
original.

Anyway, there was an idea that the stripe size could be user
configurable, though that never shipped as far as I know. If it had,
then the optimal NOIOB could be made larger, but the atomic write size
doesn't change.