Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752108AbbEFRZn (ORCPT ); Wed, 6 May 2015 13:25:43 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:51720 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751041AbbEFRZg (ORCPT ); Wed, 6 May 2015 13:25:36 -0400 Message-ID: <554A4E71.2020401@fb.com> Date: Wed, 6 May 2015 11:25:05 -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: Peter Zijlstra , "Martin K. Petersen" CC: Jeff Moyer , , , , Subject: Re: [PATCH v2] Support for write stream IDs References: <1430856181-19568-1-git-send-email-axboe@fb.com> <55493097.6040007@fb.com> <55493AC1.9090408@fb.com> <20150506142624.GM17717@twins.programming.kicks-ass.net> In-Reply-To: <20150506142624.GM17717@twins.programming.kicks-ass.net> 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-06_05:2015-05-05,2015-05-06,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1464 Lines: 33 On 05/06/2015 08:26 AM, Peter Zijlstra wrote: > On Tue, May 05, 2015 at 06:09:18PM -0400, Martin K. Petersen wrote: >>>>>>> "Jens" == Jens Axboe writes: >> >> Jens> I'm not trying to make a shortcut. I deliberately do not want to >> Jens> make ID generation/assignment part of the kernel. There's no >> Jens> reason that can't exist outside of the kernel, in a libstreamid or >> Jens> similar. >> >> That just perpetuates the broken model, though. Why wouldn't we want to >> have stream ids readily available inside the kernel to tag journals, >> filesystem metadata, data migration, who knows what? > >> The only sensible solution is for the kernel to manage the stream >> IDs. And for them to be plentiful. The storage device is free to ignore >> them, do LRU or whatever it pleases to manage them if it has an internal >> limit on number of open streams, etc. > > I agree; one of the primary tasks of an operating system kernel is > arbitrage and control of hardware resources. Sure, that's what the kernel does, but the problem here includes that the IDs space and generation is currently being done by the device. So it's not a simple as divvying out an open space of resources. -- 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/