On Jun 14, 2017, at 9:26 PM, Jens Axboe <axboe@xxxxxxxxx> wrote: > On Wed, Jun 14, 2017 at 5:39 PM, Andreas Dilger <adilger@xxxxxxxxx> wrote: >> 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? > > There's no reason they can't coexist. Now that bio->bi_stream is gone > and we just have the flags, if we want to expose separate "real" stream > IDs, then we could later re-introduce that. It'd be pretty trivial to > just use the most pertinent information on the driver side. > > From my perspective, all I really care about is the 4 hints. It's a > simple enough interface that applications can understand and use it, and > we don't need any management of actual stream IDs. I think that has the > highest chance of success. Modifying an application to use it is > trivial, even something like RocksDB (if you havehad to make changes > to RocksDB, you'll get this). If this is really to be only flags, rather than a hybrid of flags and IDs (as I had thought), then it probably makes sense to limit the inode usage to a few bits in i_flags using S_LIFETIME_* values rather than a separate 16-bit i_stream field, which can be used for the actual stream IDs later. >> 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)? > > Agree, both would be viable solutions, and they can coexist. Explicitly > managing stream IDs is a lot more advanced, and the 4 hints will get > most people 95% of the way there. For explicit streams, we'd need > something similar to my previous versions of this patchset, where a full > API is provided. > >> 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. > > I don't think we should mix the two up. As mentioned above, one will > require a full API and kernel management of the streams. I had a lot of > push back on that approach previously, which is why I've now gone for > the simpler version. If we want to expose stream IDs explicitly to user > space, that's a lot more involved. > > -- > Jens Axboe Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
