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:	Wed, 6 May 2015 11:25:05 -0600
From:	Jens Axboe <axboe@...com>
To:	Peter Zijlstra <peterz@...radead.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>
CC:	Jeff Moyer <jmoyer@...hat.com>, <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/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 <axboe@...com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/