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: <5451A3F5.9020903@fb.com>
Date:	Wed, 29 Oct 2014 20:35:33 -0600
From:	Jens Axboe <axboe@...com>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	"Jason B. Akers" <jason.b.akers@...el.com>
CC:	<linux-ide@...r.kernel.org>, <dan.j.williams@...el.com>,
	<kapil.karkra@...el.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] Enable use of Solid State Hybrid Drives

On 2014-10-29 20:05, Martin K. Petersen wrote:
>>>>>> "Jason" == Jason B Akers <jason.b.akers@...el.com> writes:
>
> Jason> The following series enables the use of Solid State hybrid drives
> Jason> ATA standard 3.2 defines the hybrid information feature, which
> Jason> provides a means for the host driver to provide hints to the
> Jason> SSHDs to guide what to place on the SSD/NAND portion and what to
> Jason> place on the magnetic media.
>
> I have been ripping my hair out in this department for a while.
>
> A colleague and I presented our findings at SNIA SDC a few weeks
> ago. I'm trying to find out if there's an embargo on the slides or if I
> can post them.
>
> First of all I completely agree with Dave's comments about hooking into
> fadvise()/madvise().

The problem with xadvise() is that it handles only one part of this - it 
handles the case of tying some sort of IO related priority information 
to an inode. It does not handle the case of different parts of the file, 
at least not without adding specific extra tracking for this on the 
kernel side.

I think we've needed a proper API for passing in appropriate hints on a 
per-io basis for a LONG time.

> My challenge with hints has been trying to bridge all the various
> existing approaches with the new stuff that's coming down the pipe in
> T10/T13 (LBMD hints) and NFS v4.2 ditto. That turned into a huge mapping
> table as well as a few amendments to what's currently being worked on in
> the standards bodies.

That is the big challenge. We've tried (and failed) in the past to 
define a set of hints that make sense. It'd be a shame to add something 
that's specific to a given transport/technology. That said, this set of 
hints do seem pretty basic and would not necessarily be a bad place to 
start. But they are still very specific to this use case. And who knows 
what will happen on the device side. I might assume that WILLNEED is the 
same as HOT, and that DONTNEED is the same as cold. And then 
applications get upset when vendor X and Y treat them somewhat 
differently, because that's how it fit into their architecture.

This is the primary reason that hints never happened previously.

-- 
Jens Axboe

--
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/