CAM Shingled Disk support patches available

[Slawa Olhovchenkov]

On Tue, Jan 19, 2016 at 12:06:41PM -0500, Kenneth D. Merry wrote:

> On Tue, Jan 19, 2016 at 20:02:52 +0300, Slawa Olhovchenkov wrote:
> > On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote:
> > 
> > > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote:
> > > > On Mon, Jan 18, 2016 at 05:37:04PM -0500, Kenneth D. Merry wrote:
> > > > 
> > > > > I have a new set of SMR patches available.  See below for the full
> > > > > explanation.
> > > > > 
> > > > > The primary change here is that I have added SMR support to the ada(4)
> > > > > driver.  I spent some time considering whether to try to make the da(4) and
> > > > > ada(4) probe infrastructure somewhat common, but in the end concluded it
> > > > > would be too involved with not enough code reduction (if any) in the end.
> > > > > 
> > > > > So, although the ideas are similar, the probe logic is separate.
> > > > > 
> > > > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer,
> > > > > etc.) for SATA protocol shingled drives isn't active.  For both the da(4)
> > > > > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary
> > > > > register down to the drive.
> > > > > 
> > > > > In the ada(4) case, we need to add the register to struct ccb_ataio and
> > > > > add support in one or more of the underlying SATA drivers, e.g. ahci(4).
> > > > > 
> > > > > In the da(4) case, it will require an update of the T-10 SAT spec to
> > > > > provide a way to pass the Auxiliary register down via the SCSI ATA
> > > > > PASS-THROUGH command, and then a subsquent update of the SAT layer in
> > > > > various vendors' SAS controller firmware.  At that point, there may be 
> > > > > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and
> > > > > we may be able to just issue the SCSI version of the commands instead of
> > > > > composing ATA commands in the da(4) driver.  (We'll still need to keep the
> > > > > ATA passthrough version for a while at least to support controllers that
> > > > > don't have the updated translation code.)
> > > > 
> > > > Please, check me: currenly SMR lack of support in SCSI devices? On
> > > > [hardvare] vendor level? Currenly only SATA controllers compatible
> > > > with SMR (on command level)? (I am don't talk about FreeBSD support,
> > > > question about common state).
> > > 
> > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC
> > > spec that defines the command set.  I don't know whether any vendors are
> > > shipping SAS/SCSI SMR drives yet.
> > > 
> > > You can use SATA drives (SMR or not) with either a SATA controller or a SAS
> > > controller.  But the way you talk to a SATA drive through a SAS controller
> > > is with SCSI commands.  There is a SCSI spec (SAT) that defines the mapping
> > > of SCSI commands to ATA commands.  It has recently been updated to support
> > > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers
> > > have not caught up with the spec.
> > > 
> > > So to use a SATA SMR drive with a SAS controller that doesn't know how to
> > > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands
> > > through the SCSI ATA PASS-THROUGH command.  That just bypasses the usual
> > > translations, and allows sending ATA commands in something like their
> > > native form.
> > 
> > What in case of expanders an port replicatiors (SATA drives and HBA
> > SAS controllers, of course)? Need expander be compatible with SMR? Or
> > any expander with SATA support automaticly compatible?
> 
> Expanders and port replicators shouldn't matter.  The place where you need
> to know about SMR is the place where the native ATA or SCSI drive commands
> are generated.  Expanders and port replicators typically just pass commands
> through.

Thanks for clarification!