Date: Tue, 19 Jan 2016 20:59:27 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: "Kenneth D. Merry" <ken@FreeBSD.ORG> Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119175927.GE37895@zxy.spb.ru> In-Reply-To: <20160119170641.GA1669@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160119114523.GD37895@zxy.spb.ru> <20160119163831.GB99885@mithlond.kdm.org> <20160119170252.GC88527@zxy.spb.ru> <20160119170641.GA1669@mithlond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160119175927.GE37895>