lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2015-05-05 23:21    [W:0.049 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site