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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2015-08-03 at 09:24 +0200, Hannes Reinecke wrote:
> On 08/02/2015 06:11 PM, James Bottomley wrote:
> > On Fri, 2015-07-31 at 15:02 +0200, Hannes Reinecke wrote:
> >> 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