Thread (24 messages) 24 messages, 3 authors, 2015-08-03

Re: [PATCH 0/6] ZAC host-aware device support

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: 2015-08-03 15:31:42
Also in: linux-scsi

On Mon, 2015-08-03 at 09:24 +0200, Hannes Reinecke wrote:
On 08/02/2015 06:11 PM, James Bottomley wrote:
quoted
On Fri, 2015-07-31 at 15:02 +0200, Hannes Reinecke wrote:
quoted
Hi all,

here is a patchset for adding ZAC host-aware device support to libata.
Main bits are translations for ZBC IN and ZBC OUT; others are the
required plumbing like generating the correct VPD pages.
James, do you require a separate patch for adding ZBC IN and ZBC OUT
or is it okay to have it queued here?
This really belongs in the ZBC patch set, doesn't it? Why isn't it
there.  You can't avoid the dependency.  If it goes with the ZAC patch
set, then the ZBC one depends on ZAC.  If it goes properly with ZBC then
you need an additional patch adding the ATA translations after the ZBC
one.  On the whole, I'd prefer the latter so we always have the required
consumers of the API.

In fact, if I read the dependencies correctly, you need the ZBC patches
first, don't you ... otherwise there's nothing to drive host aware ZAC?
No. These patches just implement a proper SATL for ZAC drives.
So in effect they just bring libata support on par with 'real' ZBC
drives, allowing things like 'sg_rep_zones' to work properly there.
But that was my point: the Linux SATL exists to support our ULDs on ATA
devices.  Until that support exists within SCSI, we don't really need
the SATL to support it.  You can argue it's for SG_IO, but really, if
you're doing user level control of ZAC devices, you'd use ATA commands.
As such I've considered those patches to be a precursor for ZBC support.

But then, I don't mind how it's being handled.
I surely can turn things around, ZBC support first, and ZAC as an
add-on to that.
Just say the word.
Well, um, since there's no ATA ULD, there is no real kernel handling of
ZAC devices, so doesn't that mean we have to at least have the reporting
done via block and sd before the ATA bits will do anything meaningful?

So to me, this looks very like supporting 512e: agree what parameters
block exposes and how userspace uses them, then plumb into block, then
SCSI then ATA (i.e. work down the stack, not up).

James

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help