From owner-freebsd-scsi@freebsd.org Mon Jan 18 22:37:08 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5E3AA86982 for ; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D10FD1FB3 for ; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id CDC6CA86980; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD279A8697E; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D1C11FB1; Mon, 18 Jan 2016 22:37:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0IMb4DH087661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jan 2016 17:37:04 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0IMb4mE087660; Mon, 18 Jan 2016 17:37:04 -0500 (EST) (envelope-from ken) Date: Mon, 18 Jan 2016 17:37:04 -0500 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160118223704.GA87506@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151118171309.GA3564@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 18 Jan 2016 17:37:04 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 22:37:08 -0000 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.) FreeBSD/head as of SVN revision 294105: https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt FreeBSD stable/10 as of SVN revision 294100: https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt Testing and comments are welcome. Ken On Wed, Nov 18, 2015 at 12:13:09 -0500, Kenneth D. Merry wrote: > > I have work in progress patches to add SMR (Shingled Magnetic Recording) > support to CAM and GEOM here: > > FreeBSD/head as of SVN revision 290997: > > https://people.freebsd.org/~ken/cam_smr.head.20151117.1.txt > > FreeBSD stable/10 as of SVN revision 290995: > > https://people.freebsd.org/~ken/cam_smr.stable10.20151117.1.txt > > This includes support for Host Managed, Host Aware and Drive Managed SMR > drives that are either SCSI (ZBC) or ATA (ZAC) attached via a SAS > controller. This does not include support for SMR ATA drives attched via > an ATA controller. Also, I have not yet figured out how to properly detect > a Host Managed ATA drive, so this code won't do that. > > The big drive vendors are moving to SMR for at least some of their drives. > The primary challenge with SMR is that it requires writing a relatively > large zone sequentially starting at the beginning of the zone. The usual > zone size is 256MB. It is conceptually almost like having a 256MB sector > size. > > We (Spectra Logic) are working on ZFS changes that will use this CAM and > GEOM infrastructure to make ZFS play well with SMR drives. Those changes > aren't yet done. > > The patches linked above include: > o A new 'camcontrol zone' command that allows displaying and managing > drive zones via SCSI/ATA passthrough. > o A new zonectl(8) utility that uses the new DIOCZONECMD ioctl to display > and manage zones via the da(4) (and later ada(4)) driver. > o Changes to diskinfo -v to display the zone mode of a drive. > o A new disk zone API, sys/sys/disk_zone.h. > o A new bio type, BIO_ZONE, and modifications to GEOM to support it. This > new bio will allow filesystems to query zone support in a drive and > manage zoned drives. > o Extensive modifications to the da(4) driver to handle probing SCSI and > SATA behind SAS SMR drives. > o Additional CAM CDB building functions for zone commands. > > The current issues that need to be addressed are: > o The da(4) driver now has 6 additional probe states, 5 of which are > needed for probing ATA drives behind SAS controllers. I have not yet > added support for BIO_ZONE bios to ada(4), but it will be very similar > to the da(4) driver version. The ATA probe code needs to be pulled > out of the da(4) driver and changed into a form that will allow it to > work for either the ada(4) or da(4) driver. Otherwise we'll have a fair > amount of code duplication between the two drivers. > > o There is a reasonable amount of code duplication between 'camcontrol zone' > and zonectl(8). This was done for speed / expediency's sake, but it may > be possible to make more of the code common there. > > o In order to add the new BIO_ZONE bio command, I had to change the bio_cmd > field in struct bio from a uint8_t to a uint16_t. This will cause > binary compatibility problems with any 3rd party loadable modules. > Advice on how to handle this would be welcome. > > o In the process of developing these changes, I discovered that the > dxfer_len paramter for scsi_ata_pass_16() was too small (uint16_t, and > it needed to be uint32_t). I increased it, but that will potentially > cause a binary incompatibility problem with any existing applications > that use the current API via libcam. Advice on how to handle that > would be welcome. > > If you look through the code, you'll notice that the disk_zone.h API is > separate from the SCSI and ATA APIs. The intent is to allow filesystems > and other consumers of the API to just talk to the disk zone API without > dealing with the SCSI and ATA specifics. Another reason behind all of this > is that even though the SCSI ZBC and ATA ZAC specs were developed in > concert, and are intended to be functionally identical, they are still SCSI > and ATA. As usual, SCSI is big endian and ATA is little endian. So to > present a common API to the filesystem, we give all of the zone data back > in native byte order, regardless of the underlying device protocol. > > Another thing to note is the extensive use of ATA passthrough in the da(4) > driver. This is necessary because the SCSI SAT (SCSI to ATA Translation) > specification has not yet caught up with translating SCSI zone commands > (ZBC) to ATA zone commands (ZAC). So, until the spec is updated and LSI > and other vendors update their SCSI to ATA translation layers, we'll have > to use the ATA version of the commands when talking to ATA drives via SAS > controllers. > > I have only tested the code so far with Seagate SATA Drive Managed and Host > Aware drives. I would appreciate testing with any drives. (And testing to > make sure that the patches don't cause problems with existing hardware.) > Right now, all you can really do is manage the zones manually using > camcontrol(8) or zonectl(8). Automatic management will come with the ZFS > changes. (Or changes to other filesysems if people want to do it.) > > If you have a SATA Host Aware drive, in theory camcontrol(8) should allow > you to manage the drive if you have it attached to a SATA controller. > > Here is an example of some of the commands. > > Get general zoning information: > > [root@sm4u-1 ~]# zonectl -c params -d /dev/da21 > Zone Mode: Host Aware > Command support: Report Zones, Open, Close, Finish, Reset Write Pointer > Unrestricted Read in Sequential Write Required Zone (URSWRZ): No > Optimal Number of Open Sequential Write Preferred Zones: 128 > Optimal Number of Non-Sequentially Written Sequential Write Preferred Zones: 8 > Maximum Number of Open Sequential Write Required Zones: Unlimited > > Look at information from the da(4) driver: > > [root@sm4u-1 ~]# sysctl kern.cam.da.21 > kern.cam.da.21.delete_method: NONE > kern.cam.da.21.delete_max: 1081344 > kern.cam.da.21.minimum_cmd_size: 6 > kern.cam.da.21.sort_io_queue: -1 > kern.cam.da.21.zone_mode: Host Aware > kern.cam.da.21.zone_support: Report Zones, Open, Close, Finish, Reset Write Pointer > kern.cam.da.21.optimal_seq_zones: 128 > kern.cam.da.21.optimal_nonseq_zones: 8 > kern.cam.da.21.max_seq_zones: 4294967295 > kern.cam.da.21.error_inject: 0 > > Display all of the zones with zonectl(8): > > [root@sm4u-1 ~]# zonectl -d /dev/da21 -c rz > 29809 zones, Maximum LBA 0x3a3812aaf (15628053167) > Zone lengths and types may vary > Start LBA Length WP LBA Zone Type Condition Sequential Reset > 0, 524288, 0x80000, Conventional, NWP, Sequential, No Reset Needed > 0x80000, 524288, 0x100000, Conventional, NWP, Sequential, No Reset Needed > 0x100000, 524288, 0x180000, Conventional, NWP, Sequential, No Reset Needed > 0x180000, 524288, 0x200000, Conventional, NWP, Sequential, No Reset Needed > 0x200000, 524288, 0x280000, Conventional, NWP, Sequential, No Reset Needed > 0x280000, 524288, 0x300000, Conventional, NWP, Sequential, No Reset Needed > 0x300000, 524288, 0x380000, Conventional, NWP, Sequential, No Reset Needed > 0x380000, 524288, 0x400000, Conventional, NWP, Sequential, No Reset Needed > 0x400000, 524288, 0x480000, Conventional, NWP, Sequential, No Reset Needed > 0x480000, 524288, 0x500000, Conventional, NWP, Sequential, No Reset Needed > 0x500000, 524288, 0x580000, Conventional, NWP, Sequential, No Reset Needed > 0x580000, 524288, 0x600000, Conventional, NWP, Sequential, No Reset Needed > 0x600000, 524288, 0x680000, Conventional, NWP, Sequential, No Reset Needed > 0x680000, 524288, 0x700000, Conventional, NWP, Sequential, No Reset Needed > 0x700000, 524288, 0x780000, Conventional, NWP, Sequential, No Reset Needed > [ ... ] > 0x1f00000, 524288, 0x1f80000, Conventional, NWP, Sequential, No Reset Needed > 0x1f80000, 524288, 0x2000000, Conventional, NWP, Sequential, No Reset Needed > 0x2000000, 524288, 0x2080000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2080000, 524288, 0x2100000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2100000, 524288, 0x2180000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2180000, 524288, 0x2200000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2200000, 524288, 0x2280000, Seq Preferred, Full, Sequential, No Reset Needed > 0x2280000, 524288, 0x2300000, Seq Preferred, Full, Sequential, No Reset Needed > [ ... ] > > Use camcontrol zone to reset the write pointer for the first shingled zone > listed above: > > [root@sm4u-1 ~]# camcontrol zone da21 -v -c rwp -l 0x2000000 > > Use camcontrol zone to ask the drive to report empty zones: > > [root@sm4u-1 ~]# camcontrol zone da21 -v -c rz -o empty > 1 zones, Maximum LBA 0x3a3812aaf (15628053167) > Zone lengths and types may vary > Start LBA Length WP LBA Zone Type Condition Sequential Reset > 0x2000000, 524288, 0x2000000, Seq Preferred, Empty, Sequential, No Reset Needed > > Get information on a Host Aware drive: > > root@sm4u-1 ~]# diskinfo -v da21 > da21 > 512 # sectorsize > 8001563222016 # mediasize in bytes (7.3T) > 15628053168 # mediasize in sectors > 4096 # stripesize > 0 # stripeoffset > 972801 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > Z84008NY # Disk ident. > enc@5003048001f311fd/elmtype@array_device/slot@22 # Physical path > Host Aware # Zone Mode > > Get information on a drive managed drive: > > [root@sm4u-1 ~]# diskinfo -v da20 > da20 > 512 # sectorsize > 8001563222016 # mediasize in bytes (7.3T) > 15628053168 # mediasize in sectors > 4096 # stripesize > 0 # stripeoffset > 972801 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > Z8405938 # Disk ident. > enc@5003048001f311fd/elmtype@array_device/slot@21 # Physical path > Drive Managed # Zone Mode > > Get information on a non-zoned drive: > > [root@sm4u-1 ~]# diskinfo -v da4 > da4 > 512 # sectorsize > 100030242816 # mediasize in bytes (93G) > 195371568 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 12161 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 124903574F36 # Disk ident. > enc@5003048001f311fd/elmtype@array_device/slot@5 # Physical path > Not Zoned # Zone Mode > > Testing and comments are welcome. > > Thanks, > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@freebsd.org Tue Jan 19 00:50:38 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90AEBA869A9 for ; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9D21012 for ; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 68E60A869A7; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E8F9A869A4 for ; Tue, 19 Jan 2016 00:50:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25EE1100B for ; Tue, 19 Jan 2016 00:50:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-pa0-x22a.google.com with SMTP id cy9so441803000pac.0 for ; Mon, 18 Jan 2016 16:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=aEphZJJ3jxGXp3xgtnMKJ827HqY0OFgxE7fQOIiHUW0=; b=KugDHZmdP0+WIV8JCvHIzuDB0wqXLj9tnu+u/okjKDrtLB3yrMnyhyTN5VgHrhXCn9 q1s6JLVlHmZcLBLhkBHtK+6nTEvv5mk0K9eiIm8tvoQ7B09FcTHWK9IQhBsZ94n6lTD2 Eq4CfC9lchpnDi/q4hhYLxADq3m2S0b/a+V1JXRNkd/PcvN6QguaBnxGKDGxFbnC5g/Y sm5SzmhmYPVt6HDOf6gJ7YuvMu5KGgSq4Q4FNQ0jFNaBWKZmfl45/C5xNehwY0UlBZkk F70eHKZPNiC9COm5R8HuVTorpU70zidxByrWiLF0NGJAc6bMcbkqTgwoLaGvMN8Jus3e Ygjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=aEphZJJ3jxGXp3xgtnMKJ827HqY0OFgxE7fQOIiHUW0=; b=VMmU0QR9yKnVJJNojc0J6VJLcwPoVnOZtpmX5c+PJl5EteCyBOdh5NVK0+VQni5wjG qRWywKKr5AcZBCQQH4q9+/ZaFuSrwqsVHxU2/mtiHbce/ZfYHq3wqY6ZFjvVxcVYEJe2 fQIUQui7hr0fMkgege0THVuweDJt7tMxRD+HANHgl6rL8Rky3IBlt4s5nuWlGUsOqDN5 XGzNHVt5bsDgitWGUlZj71qF3ZnkgujXShTMm/ri2Eju+Am0pEh73H3b/simr3x+Dowg Kc5j6Ms0bUjNAZJqIIkFPU7CnFYLYzBKcZOufEeUNtj8/WSCKy9pnEkfoZ9Bb1s5ISTV X5TA== X-Gm-Message-State: ALoCoQmTboyalZ/g43KgczBA5X16drhDnuiZ9ZbWWZe8EcIsv0gcRuR09GXvD1wqEcByBaDlMZC2EZCas2dNpnsw8THguyHgiA== X-Received: by 10.66.142.201 with SMTP id ry9mr41050287pab.89.1453164637357; Mon, 18 Jan 2016 16:50:37 -0800 (PST) Received: from [100.127.145.62] ([69.53.245.26]) by smtp.gmail.com with ESMTPSA id p20sm36580169pfi.86.2016.01.18.16.50.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Jan 2016 16:50:36 -0800 (PST) Sender: Warner Losh Subject: Re: CAM Shingled Disk support patches available Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <20160118223704.GA87506@mithlond.kdm.org> Date: Mon, 18 Jan 2016 16:50:34 -0800 Cc: scsi@freebsd.org, current@freebsd.org Message-Id: <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 00:50:38 -0000 --Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 18, 2016, at 2:37 PM, Kenneth D. Merry wrote: >=20 > I have a new set of SMR patches available. See below for the full > explanation. >=20 > 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. >=20 > So, although the ideas are similar, the probe logic is separate. >=20 > 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. I=E2=80=99ve plumbed it down, but in a gross, kludgy way to make NCQ = Trim work where the only value in the Auxiliary register needs to be 1. It only = takes up one bit, but it doesn=E2=80=99t change the size of the CCB. If the = NCQ Trim work wasn=E2=80=99t based on the I/O scheduler, I=E2=80=99d have pushed = it into head and would be happy to share code. AHCI can send it, but it turns out that LSI=E2=80=99s drivers (mpt, mps, = etc) can=E2=80=99t do it due to firmware inadequacies. The ability to send a = FIS in these firmwares looked promising, but it requires a full draining of other requests, which kind of defeats the purpose of NCQ. > 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). I believe that changes the size of the CCB, so I tried to avoid that since I didn=E2=80=99t want to force a recompile of camcontrol(8). Adding it to the atacmd structure wasn=E2=80=99t so bad, and the CCB = size didn=E2=80=99t completely change. The problem was that the atacmd = changed size and pushed all the other fields. > 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.) I looked to implement things here, but didn=E2=80=99t want to invent = something that the T-10 would later reinvent. > FreeBSD/head as of SVN revision 294105: >=20 > https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt >=20 > FreeBSD stable/10 as of SVN revision 294100: >=20 > https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt >=20 > Testing and comments are welcome. So having said all that, I=E2=80=99m totally open to something better. Warner --Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWnYhbAAoJEGwc0Sh9sBEA8twQANJz9qBAsb9LsDw9OAD2j0YG 9/AICl2TX2KEYtVEjobIPzNGtAlsQVNzGquP7SrC6KXLwr6QJb7S92tUpQJczC+I JMx2/ggiA7jlzURlNOjaJCPaBTIMsgtG5RKQWebvElS6K9Iigm25DlbNcL/3b7VR 0WGRGSSmznomtYd8c6IEr3AjzMZlpiLF8Oqsftd080Sd+GpTCj6bEZfIbB++IUSW MxlufkbeWR2nq/LalFoJOTvX7zSOyZ68+1SDawz2A9RgugLkpa1TAdINEDJ0YlqJ 9qr5RJr05tPNnuDyJIeQWrReYBEUqasYefG3TEg3s73DIvvDMPfsWs6ablcKOjYV FXMozxVUHX94/WToMjYzZ65bFuDQv5U7SzF2Pl9KGg2aRpHrudkI8luFPEg6yVCU aHB8Jder83bp0UN1Ta+MPpVwiyq7JPlys4Bco2Bk7p2peR2hkjKIDQMtuOrKNPQB Hn3pgyUu5HfBXRPd3xtIDvBx68G0ezc84MXJZPf+BBffIBI4HKK7bCMMc5NJv74/ +u5eiSumhlPibETKiYChjSvZxUc3EQHv5Q8qYquXu81mxRAuWTIQbD6zkYz8nZOc 0rD70Acm/y8wTPjdik4b2TnYw8i0WqY25u0zBwXzILGa8lR6SrWbB/l8g52ZnDWE t4FbBBXkx8V2MaUh2/TM =xUcY -----END PGP SIGNATURE----- --Apple-Mail=_D9B23743-1797-4D51-856D-5A96F7555BA3-- From owner-freebsd-scsi@freebsd.org Tue Jan 19 11:45:33 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9EB7A88F8A for ; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 99D381024 for ; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 954FCA88F85; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94896A88F80; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 555BF1020; Tue, 19 Jan 2016 11:45:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aLUiy-00072l-0q; Tue, 19 Jan 2016 14:45:24 +0300 Date: Tue, 19 Jan 2016 14:45:23 +0300 From: Slawa Olhovchenkov To: "Kenneth D. Merry" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119114523.GD37895@zxy.spb.ru> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160118223704.GA87506@mithlond.kdm.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:45:33 -0000 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). From owner-freebsd-scsi@freebsd.org Tue Jan 19 16:25:59 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6988A8910C for ; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B9E3110FF for ; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id B5BB7A8910A; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4E7DA89108; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 71BA110FD; Tue, 19 Jan 2016 16:25:59 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0JGPuip001151 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 11:25:56 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0JGPu1L001150; Tue, 19 Jan 2016 11:25:56 -0500 (EST) (envelope-from ken) Date: Tue, 19 Jan 2016 11:25:56 -0500 From: "Kenneth D. Merry" To: Warner Losh Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119162555.GA99885@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 19 Jan 2016 11:25:56 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:26:00 -0000 On Mon, Jan 18, 2016 at 16:50:34 -0800, Warner Losh wrote: > > > On Jan 18, 2016, at 2:37 PM, 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. > > I???ve plumbed it down, but in a gross, kludgy way to make NCQ Trim work > where the only value in the Auxiliary register needs to be 1. It only takes > up one bit, but it doesn???t change the size of the CCB. If the NCQ Trim > work wasn???t based on the I/O scheduler, I???d have pushed it into head > and would be happy to share code. Yeah, for SMR, we'll need to pass the full register down. That is how you specify the service action (open, close, finish, reset write pointer, report zones). > AHCI can send it, but it turns out that LSI???s drivers (mpt, mps, etc) > can???t do it due to firmware inadequacies. The ability to send a FIS > in these firmwares looked promising, but it requires a full draining of > other requests, which kind of defeats the purpose of NCQ. Yeah, that would kinda defeat the purpose. I'm sending a SCSI command (ATA PASS-THROUGH) to get the SATA zone commands down there. Those are treated like an ordered tag by the LSI firmware as well. Which is just as well, since there is no way to specify the Auxiliary register via that SCSI command, and so we can't do NCQ anyway. LSI/Avago said they're planning to support the zone commands in the SAT layer in the HBAs in the 12Gb boards. Phase 10 doesn't have it from what I understand, but hopefully that'll show up soon. The translation is in the latest SAT draft, and it is very straightforward to map from one to the other, because the SCSI and ATA commands and semantics are pretty much identical. > > 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). > > I believe that changes the size of the CCB, so I tried to avoid > that since I didn???t want to force a recompile of camcontrol(8). > Adding it to the atacmd structure wasn???t so bad, and the CCB size > didn???t completely change. The problem was that the atacmd changed > size and pushed all the other fields. Yes. In order to do it, we'll need to add it to struct atacmd, and add compatibility shims. I don't see another way to do it unfortunately. > > 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.) > > I looked to implement things here, but didn???t want to invent something that > the T-10 would later reinvent. Yeah. Is NCQ trim a new thing? Is that why you were looking at sending it down via a FIS? If so, it is likely that LSI will add it to the SCSI Unmap translation in the firmware. Of course if it isn't already in there, they're only going to put it in their 12Gb controllers and not in the 6Gb controllers at this point. Since the SAT spec has the mapping for the SCSI ZBC -> ZAC commands, it sounds like that'll make it into the LSI 12Gb firmware at some point. > > FreeBSD/head as of SVN revision 294105: > > > > https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt > > > > FreeBSD stable/10 as of SVN revision 294100: > > > > https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt > > > > Testing and comments are welcome. > > So having said all that, I???m totally open to something better. I think that for the ATA side, we'll just have to add the register to the CCB, bump the version and add compatibility shims. For the SCSI side, we just need a way to probe and see whether the translation is supported in the SAT layer (at least for the ZBC commands, I don't know about trim) and use the SCSI command if it is supported, otherwise use the ATA PASS-THROUGH command if it is not. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@freebsd.org Tue Jan 19 16:38:36 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01463A894C2 for ; Tue, 19 Jan 2016 16:38:36 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DA4691897 for ; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id D5BBDA894BF; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB400A894BE; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 964E91895; Tue, 19 Jan 2016 16:38:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0JGcXBp001283 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 11:38:33 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0JGcVuh001282; Tue, 19 Jan 2016 11:38:31 -0500 (EST) (envelope-from ken) Date: Tue, 19 Jan 2016 11:38:31 -0500 From: "Kenneth D. Merry" To: Slawa Olhovchenkov Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119163831.GB99885@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160119114523.GD37895@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119114523.GD37895@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 19 Jan 2016 11:38:33 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:38:36 -0000 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. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@freebsd.org Tue Jan 19 17:02:56 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB987A89C7E for ; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B0B201ADD for ; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id ADEC5A89C7C; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93726A89C7A; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51E091AD9; Tue, 19 Jan 2016 17:02:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aLZgC-000EMi-S8; Tue, 19 Jan 2016 20:02:52 +0300 Date: Tue, 19 Jan 2016 20:02:52 +0300 From: Slawa Olhovchenkov To: "Kenneth D. Merry" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119170252.GC88527@zxy.spb.ru> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160119114523.GD37895@zxy.spb.ru> <20160119163831.GB99885@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119163831.GB99885@mithlond.kdm.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:02:57 -0000 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? From owner-freebsd-scsi@freebsd.org Tue Jan 19 17:06:44 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F4165A89D8C for ; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DE0D71D6A for ; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id D98A3A89D89; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D900CA89D88; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B3E521D68; Tue, 19 Jan 2016 17:06:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u0JH6fEf001714 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 12:06:41 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u0JH6fXv001713; Tue, 19 Jan 2016 12:06:41 -0500 (EST) (envelope-from ken) Date: Tue, 19 Jan 2016 12:06:41 -0500 From: "Kenneth D. Merry" To: Slawa Olhovchenkov Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119170252.GC88527@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 19 Jan 2016 12:06:41 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:06:44 -0000 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. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@freebsd.org Tue Jan 19 17:20:02 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6FCEA86581 for ; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C8E5217F7 for ; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id C3D74A8657F; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AACB5A8657D for ; Tue, 19 Jan 2016 17:20:01 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm43-vm5.bullet.mail.gq1.yahoo.com (nm43-vm5.bullet.mail.gq1.yahoo.com [67.195.87.220]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7182C17F2 for ; Tue, 19 Jan 2016 17:20:00 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1453223618; bh=U8yG3IpWN4ie+PyrYQU3nDZa+4DZUEGe1+IY7/loVNo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=RJIbnmay/tI+J2qJgNLsKSq0C5IBHURpJKMc8CbmX6sJ0ZSS1FTTR7bRehXfuXoHOuHMHSa4e8Y2s80FIQWhlqlp0qoMHMTNFX3rFT1T13BfomAPMZVDnj/Ca4naNEI8YjQF8GsrnIpKRwXCr8LM7g14hjDh3n49I6LsiHqGqW/93tT3NeufmSm9GEnWtq58+emQe++2kbSTQ1iWrJeQw9PH5MTq0mavR61Sbr7WObHG3PGNgWPKf/jPU5VGEC8TjZ47FKcY9JTK8H3KDo59sNDLgC8k7VYOsWdnpFYDYiJ1L5LXpIjbH4QQ0tQAI/Ium501OGk0yQLLLwqenm9wyQ== Received: from [127.0.0.1] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:13:38 -0000 Received: from [98.137.12.57] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:10:51 -0000 Received: from [98.136.164.78] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:10:51 -0000 Received: from [127.0.0.1] by smtp240.mail.gq1.yahoo.com with NNFMP; 19 Jan 2016 17:10:51 -0000 X-Yahoo-Newman-Id: 762227.92472.bm@smtp240.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: SUv.dT4VM1miuUV9Jva.u5fdfRVO3UeJqZTEFFvRqlT9BDz 2pMwid5EApaVaSOEUNzUr8nB0.Fu6g1V5DQMbasAb8_TQLFmnF84s5IE3TQl fadHcDogXiZUzHWaBW.dYz_oY88rHWjAoBZYA.RD78RvbFu0yvxnP2kvGqmL hZNw6Cgj8EcfrWGiMMfACzUAKDpbfoSgRKTdy2xVMpoPTDfVKxKN0kH2wVE6 wFg3LBMp8jGLY9HOMPd0p.BkaX3QwubMpmjA.3uRWanZ_pvjk4X6Oin03xG5 98WtH2W8tJbZgoiyZtIm6t2KkueB_8jawtE0q2FCprSRc6JxJ0ZB29wWjZLb ekFOOqPpJBEDYhBxlLU2N90gp6JmPgQmWrq2yTJrR9j6NxGd9p.rfA5P4Grb F115OYjDI8eG_7Vzrbwf9qxT_kiAU4N_dZcv0gemLgetnuUs6uWdnp_uYIxo 2.3pd0PV5e8ErB2Lhvvh9g13sPCtnTR.PD14FZdx8ZbGalFyIYbtGQ4VT0o8 63Ozmw1P_B2DYEbl5itV54fM921X.lNSzNkr0o5hit7dUW5Kux9p9 X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: CAM Shingled Disk support patches available From: Scott Long In-Reply-To: <20160119162555.GA99885@mithlond.kdm.org> Date: Tue, 19 Jan 2016 09:10:48 -0800 Cc: Warner Losh , current@freebsd.org, scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <07A5702E-86FB-488C-92E8-850457DD8C17@yahoo.com> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <349FCA2B-8346-4EC2-8459-B174FDC2CDB3@bsdimp.com> <20160119162555.GA99885@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:20:02 -0000 > On Jan 19, 2016, at 8:25 AM, Kenneth D. Merry wrote: >=20 >=20 >>> 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). >>=20 >> I believe that changes the size of the CCB, so I tried to avoid >> that since I didn???t want to force a recompile of camcontrol(8). >> Adding it to the atacmd structure wasn???t so bad, and the CCB size >> didn???t completely change. The problem was that the atacmd changed >> size and pushed all the other fields. >=20 > Yes. In order to do it, we'll need to add it to struct atacmd, and = add > compatibility shims. I don't see another way to do it unfortunately. >=20 No, I object to changing the structure sizes and contents. It should be = a new CCB, XPT_ATA_IO_EXT, ccb_ataio_ext. If you want to add more future-looking fields than just the AUX register, maybe a way to define un-typed command and response register objects, that=E2=80=99s fine and = probably a good idea. The periph drivers can probe for the proper command to send based on whether the SIM returning CAM_FUNC_NOTAVAIL or via a PIM flag, or even better, via a KVP capability CCB. However I=E2=80=99m = firmly against changing the existing data structures; compat shims have been a pain and are a poor solution. Warner and I are pounding out a proposal for this, will share a diff = shortly. Scott From owner-freebsd-scsi@freebsd.org Tue Jan 19 17:59:29 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B328FA87A66 for ; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A11E913D8 for ; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 9D13EA87A64; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 824C1A87A61; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40E7813D5; Tue, 19 Jan 2016 17:59:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aLaYx-000Fbz-7s; Tue, 19 Jan 2016 20:59:27 +0300 Date: Tue, 19 Jan 2016 20:59:27 +0300 From: Slawa Olhovchenkov To: "Kenneth D. Merry" Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160119175927.GE37895@zxy.spb.ru> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119170641.GA1669@mithlond.kdm.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:59:29 -0000 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!