Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031316AbbEEUf2 (ORCPT ); Tue, 5 May 2015 16:35:28 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:38689 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757557AbbEEUf0 (ORCPT ); Tue, 5 May 2015 16:35:26 -0400 Message-ID: <554928A6.6030603@fb.com> Date: Tue, 5 May 2015 14:31:34 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christoph Hellwig CC: , , , Subject: Re: [PATCH v2] Support for write stream IDs References: <1430856181-19568-1-git-send-email-axboe@fb.com> <20150505200757.GA23902@infradead.org> <55492411.1010806@fb.com> <20150505202045.GA25695@infradead.org> In-Reply-To: <20150505202045.GA25695@infradead.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.54.13] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-05_06:2015-05-05,2015-05-05,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1786 Lines: 38 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/