On Jun 14, 2017, at 10:04 AM, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > Christoph, > >> I think what Martin wants (or at least what I'd want him to want) is >> to define a few REQ_* bits that mirror the RWF bits, use that to >> transfer the information down the stack, and then only translate it >> to stream ids in the driver. > > Yup. If we have enough space in the existing flags that's perfect (I > lost count after your op/flag shuffle). Just to clarify, does this mean that Jens' "lifetime" hints are going to be independent of separate "stream ID" values in the future (needing a similar, but independent, set of fields for stream IDs, or will they both be implemented using a common transport in the kernel (i.e. both share a single set of fields in the inode/bio/etc? I can imagine applications using either the lifetime hints (mapped to stream IDs internally), or explicitly managing stream IDs, but it seems unlikely that both would be in use at the same time, unless the "lifetime" hints are intended to also indirectly map to HSM-like tiered cache/storage hints internally to the storage stack (e.g. whether writes should be put into local cachefs vs remote network storage, or bcache NVRAM vs. HDD)? Jens' patches were moving in the direction of allowing up to 16 stream IDs, with the default being IDs 1-4 are intended to reflect different data lifetimes, but allowing up to 15 unique IDs to be specified "per device"* if userspace wants to manage this more explicitly. Martin, how many stream IDs do you think are needed? If we need too many, then we wouldn't be able to pack them into the existing pwritev2() flags and would need another new API to specify the stream IDs. [*] more work is needed to handle this on multiple filesystems, MDRAID/LVM, etc. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
