Re: [RFC PATCH 0/5] Enable use of Solid State Hybrid Drives

[Dan Williams]

On Thu, Oct 30, 2014 at 7:53 AM, Jens Axboe <axboe@xxxxxx> wrote:
> On 2014-10-29 21:28, Martin K. Petersen wrote:
>> The notion of telling the storage *why* you're doing I/O instead of
>> telling it how to manage its cache and where to put stuff is closely
>> aligned with our internal experiences with I/O hints over the last
>> decade. But it's a bit of a departure from where things are going in the
>> standards bodies. In any case I thought it was interesting that pretty
>> much every use case that people came up with could be adequately
>> described by a handful of I/O classes.
>
>
> Definitely agree on this, it's about notifying storage on what type of IO
> this is, or why we are doing it. I'm just still worried that this will then
> end up being unusable by applications, since they can't rely on anything.
> Say one vendor treats WONTNEED in a much colder fashion than others, the
> user/application will then complain about the access latencies for the next
> IO to that location. "Yes it's cold, but I didn't expect it to be THAT cold"
> and then come to the conclusion that they can't feasibly use these hints as
> they don't do exactly what they want.
>
> It'd be nice if we could augment this with a query interface of some sort,
> that could give the application some idea of what happens for each of the
> passed in hints. That would improve the situation from a "lets set this hint
> and hope it does what we think it does" to a more predictable and robust
> environment.
>

I'm skeptical we (Linux kernel) can ever get this right.  If an
application wants strict determinism in the meaning of hints it seems
it will need to qualify them against component-vendor /
platform-vendor provided transport-translation.  For this RFC we had
consumer platforms in mind where "mostly better than baseline" is the
acceptance criteria vs "hard QOS".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/