On Fri, Jun 16, 2017 at 08:35:07AM -0600, Jens Axboe wrote: > > Agreed. In fact I'd go a little further: we should have a > > > > u16 hints; > > > > that goes all the way down from fcntl to the driver, right now > > we'll allocate the first 3 bits for the write lifetime hints (2.5, > > so we have one value spare, as they don't need to flags but can be > > enum values), leaving more space for other kinds of hints. > > Did you see v5? It adds enum write_hint and passes it all the way down, > until we transform them into rq/bio flags. Yes. But with all the way down I mean all the way down to the driver :) > Mess? The NVMe code seems pretty straight forward to me. Is it purely > the lazy alloc part you're referring to? Yes. > I'm fine with bubbling down the > hint and setting everything up inline from the fcntl() call, but that > means we need to make things like btrfs and md/dm aware of it and > resolve all mappings. That sort-of sucks, especially since they don't > otherwise need to know about it. True, that sucks. But taking the hint and doing things behind the scenes sounds nasty. > If another driver needs similar setup like NVMe, I'd much rather just > fix it up there. From the API point of view, there would be no changes. Ok..
