On Fri, Mar 18, 2016 at 10:37 AM, Jens Axboe <axboe@xxxxxx> wrote: > On 03/17/2016 07:39 PM, Martin K. Petersen wrote: >>>>>>> >>>>>>> "Jens" == Jens Axboe <axboe@xxxxxx> writes: >> >> >> Jens> You are not missing anything, that's exactly how it is intended, >> Jens> and that's how the interface is designed as well. If you want to >> Jens> tie extra meaning to this for specific drivers or transports, >> Jens> that's fine, and there's nothing that prevents that from >> Jens> happening. As it stands, and as it is proposed, it's just a write >> Jens> tag/stream ID that we can set on a file or inode, and have passed >> Jens> to the driver. Nothing more, nothing less. >> >> Yep. I'm fine with having the option of letting applications request an >> ID from the kernel and being able to tag I/Os. But it is also imperative >> that we are able to tag all remaining I/Os automatically. Hashing inode >> and device/partition is fine, it does not have to be particularly >> clever. >> >> There are several types of non-flash storage in the pipeline that depend >> on being able to identify blocks to disjoint LBA ranges as belonging to >> the same "file". So as long as we don't go down the 10-channel flash >> controller rat hole I'm perfectly happy... > > > So where do we go from here? Seems to me like the core parts we all agree > on, what do we do about the user interface? I can split the patchset into 2 > so we can get the core bits merged, and start further discussion on the > interface part, if we need to. I think the ability to set a stream-id on an inode is interesting, but the use cases we went through for enabling host-hinted SSHDs [1] found that a good amount of benefit could be had by specifying per-process stream-ids. It seems in the inode case we're worried about communicating permanent placement hints to the controller, while in the per-process hint we can communicate some amount of temporal and access pattern based differentiation. [1]: https://lkml.org/lkml/2014/10/29/805 -- 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
