Re: [PATCH v2] Support for write stream IDs

[Jens Axboe <axboe@fb.com>]

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