lkml.org 
[lkml]   [2015]   [May]   [6]   [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 04:09 PM, Martin K. Petersen wrote:
>>>>>> "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.

OK, that does make some sense. That would mean putting the ID management
in the kernel, where devices would register a handler to be a part of
this process. That would need to include mapping between user/kernel
stream IDx and device stream IDx, since they would not necessarily be
the same. This assumes we will have devices that manage their own
streams, which seems to be the safe bet (that's what is currently out
there). That would work for stacked/btrfs setups too.

This wont solve the problem of devices having too few streams. But it'll
work regardless, we'll just have to push them separately to do that.
It's not an easy problem for them either, resource constraints on the
device side could exclude supporting as many streams as we would ideally
want.

> 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.

In some ways I get it, you have to start somewhere. The current proposal
is useful for _some_ cases, it's not great for everything. As long as it
can be expanded to support as many streams as we would want, then it
would work. It's (again) a bit of a chicken and egg problem. We need to
make some progress, or the whole thing is going to go away. And I think
that'd be a shame, since there's definitely merit to passing these
lifetime hints to the device.

--
Jens Axboe



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