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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPcyv4gNwPrcU1CbCfUcnjqFfor5YfX6rynaoZmvEbRQMPvwMA@mail.gmail.com>
Date:	Thu, 30 Oct 2014 09:27:31 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Jens Axboe <axboe@...com>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	"Jason B. Akers" <jason.b.akers@...el.com>,
	"IDE/ATA development list" <linux-ide@...r.kernel.org>,
	"Karkra, Kapil" <kapil.karkra@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] Enable use of Solid State Hybrid Drives

On Thu, Oct 30, 2014 at 7:53 AM, Jens Axboe <axboe@...com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/