linux-kernel - Re: [PATCH v2] Support for write stream IDs

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]

Date:	Tue, 5 May 2015 14:31:34 -0600
From:	Jens Axboe <axboe@...com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	<linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
	<adilger@...ger.ca>, <david@...morbit.com>
Subject: Re: [PATCH v2] Support for write stream IDs

On 05/05/2015 02:20 PM, Christoph Hellwig wrote:
> On Tue, May 05, 2015 at 02:12:01PM -0600, Jens Axboe wrote:
>> We can't merge the NVMe bits until the proposal is included/finalized. But
>> this is a problem. I don't want to add this to the Facebook kernel until we
>> know the API is stable, while I have no problem adding experimental NVMe
>> changes since those can be easily updated without impacting applications.
>> The latter is not true for the user interface.
>
> They might never be finalized, and even if they are mere mortals might
> never get this hardware.

The likelihood of not getting streams support is minuscule. The benefits 
are just too large to ignore. It might not look like the current 
proposal, but it will get there. It's not like this is just one NVMe 
member wanting to push this, the only disagreement is whether this is 
going to be implemented as direct write tagging or through queue pairs.

Even outside of that, there are use cases for caching that need not have 
hardware assist.

> Merging infrastructure without any users is a
> bad idea in general, and merging infrastructure with no user that
> exposes untestable user interface and bloats core data structures is
> even worse.  I don't think this has any merit at all at this point.

There is a user, we are using it. And there's no data structure 
bloating, both the file and inode additions are filling existing holes. 
I'll strongly disagree with your statement that it has no merit at all. 
In fact, the merit is quite clear.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/