lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] Support for write stream IDs
From
Date
>>>>> "Jens" == Jens Axboe <axboe@fb.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?

Having storage micromanage the stream IDs is a non-starter. And it'll
also break things like software RAID, btrfs, LVM, anything that involves
multiple devices. ID X on first RAID disk then needs to be mapped to ID
Y on the second, etc.

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.

Jens> The current API doesn't have any real limits (it'll work from
Jens> 1..MAX_UINT), and the transport part handles 255 streams at the
Jens> moment. The latter can be easily extended, we can just steal a few
Jens> more bits. Making it 1023 would be a one liner.

I'm not so worried about the implementation. I'm more worried about it
being conducive to the broken proposal that's on the table.

--
Martin K. Petersen Oracle Linux Engineering


\
 
 \ /
  Last update: 2015-05-06 00:41    [W:2.015 / U:0.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site