>>>>> "Jens" == Jens Axboe <axboe@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
