支持多磁盘PIO命令并发的STP传输层实现方法与流程

本发明属于磁盘连接技术领域，特别涉及一种支持多磁盘pio命令并发的stp传输层实现方法。

背景技术：

sata(serialata)是一种高速串行总线，采用点对点的传输方式，内置数据/命令校验单元，纠错能力强，支持热插拔，具有管脚数量少、数据传输速率快、可靠性高、兼容性好等特性，目前被业界广泛用于存储设备和主机之间的主要i/o接口。

sas(串行连接scsi)作为新一代scsi技术，类似sata技术同样采用串行接口以获得更高的传输速度。同时，sas设计考虑向下兼容sata技术，通过stp协议(sata通道协议)实现sas控制器和sata设备之间的互联和数据传输。sas协议标准中的stp协议规范定义了sas系统和sata设备通信技术细节，其中stp的传输层采用sata标准协议定义的传输层实现为基础。

典型的sas数据存储拓扑结构中，sas控制器通过一级或多级expander(磁盘扩展器)扩展支持大规模磁盘的管理。sasexpander中通常集成了stp/sata桥，完成sas协议到sata协议的转换，以兼容sata磁盘设备连接。

图1描述了sas控制器和多个sata设备互联时的主要组件。其中sas控制器作为控制命令和数据读写命令的发起者，负责管理整个存储系统的拓扑结构，发出磁盘数据读写命令，接收设备响应；sasexpander用于扩展存储系统的拓扑结构，内部集成stp/sata桥以兼容sata设备连接；stp/sata桥完成sas标准中stp协议到sata协议的转换，帮助sata设备接入sas系统；sata磁盘存储设备，存储业务数据。

然而，sata标准协议在制定之初，并未充分考虑对sas应用场景的支持，在sas控制器并发访问多个sata设备的应用场景下，sata标准协议的传输层无法正确、高效的完成sas标准中定义的数据交互过程，导致数据通信失败。

为了说明sata标准传输层在支持sas的stp应用场景时存在的问题，如图2所示，从传输层角度出发，以pio写命令为例，描述一个sas控制器并发访问两个sata磁盘设备时传输层消息交互的典型场景。当两个sata设备并发pio写命令时：

h1.1:sas控制器请求向sata设备#1写入数据，发送pio写命令，传输层发送host-deviceregisterfis(frameinformationstructure，sata传输层数据结构)；

h1.2:sas控制器请求向sata设备#2写入数据，发送pio写命令，传输层发送host-deviceregisterfis；

d1.1：sata设备#1就绪，准备接收来自sas控制器的数据，传输层发送piosetupfis；

d2.1：sata设备#2就绪，准备接收来自sas控制器的数据，传输层发送piosetupfis；

h2.1：sas控制器发送数据给sata设备#1，传输层发送一帧datafis；

d1.2：sata设备#1数据接收完毕，传输层发送d-hregisterfis，返回pio写命令完成状态；

h2.2：sas控制器发送数据给sata设备#2，传输层发送一帧datafis；

d2.2：sata设备#2数据接收完毕，传输层发送d-hregisterfis，返回pio写命令完成状态。

容易看出，目前sata标准传输层在支持多磁盘pio命令并发的应用场景时存在缺陷。因为根据标准sata传输层状态机的描述，控制器的传输层由ht_hostidle状态进入ht_piootrans2状态，实施pio数据发送的前提条件是前一个接收到的fis类型为piosetupfis。然而，如图2所示两个sata设备并发pio写命令的典型场景，在步骤d1.2，sas控制器收到sata设备#1的d-hregisterfis后，开始步骤h2.2，即发送数据至sata设备#2。此时状态机检测到前一个收到的fis并非piosetupfis，无法启动datafis的发送过程，导致状态机持续停留于ht_hostidle状态，发生死循环。

类似地，对于pio读命令，标准sata传输层状态机由ht_chktyp状态进入ht_pioitrans1状态，实施pio数据接收的前提条件是前一个接收到的fis类型为piosetupfis。然而，在多个sata设备并发pio读命令场景下，同样会导致状态机持续停留于ht_chktyp状态，发生死循环。

除图2所描述的多磁盘场景下pio写命令并发情况之外，在真实应用场景中，由于d-hregisterfis、h-dregisterfis、piosetupfis、rx方向datafis、tx方向datafis的交织，导致sata传输层实际存在多重缺陷。

技术实现要素：

本发明的目的在于针对现有sata标准协议传输层存在的缺陷，提出支持多磁盘pio命令并发的stp传输层实现方法，完善sas场景下多sata磁盘并发访问的支持。

本发明在第一方面提供了一种支持多磁盘pio命令并发的stp传输层实现方法，包括：

当sas控制器满足第一条件时，将所述sata传输层状态机从ht_hostidle状态迁移到ht_dmaotrans2状态；以及

当sas控制器满足第二条件时，将所述sata传输层状态机从ht_chktyp状态迁移到所述ht_dmaitrans状态。

优选地，所述第一条件进一步包括：

在所述sata传输层状态机的ht_hostidle状态下，检测到应用层数据发送请求。

优选地，所述将状态迁移到ht_dmaotrans2状态之后，进一步包括：

启动控制器内部dma，发送datafis至sata设备。

优选地，方法还包括：

在所述ht_dmaotrans2状态下，当数据传输结束时，将状态机迁移到ht_dmaend状态，并检查sas控制器dma模块是否结束。

优选地，所述第二条件进一步包括：

在所述sata传输层状态机的ht_chktyp状态下，接收到的fis类型为datafis，且前一个接收到的fis类型为piosetupfis。

优选地，在将状态机迁移到所述ht_dmaitrans状态之后，进一步包括：

启动sas控制器内部dma模块，接收datafis到控制器内部存储单元。

优选地，方法还包括：

在ht_dmaitrans状态下，当数据传输结束；将所述状态机迁移到迁移到ht_dmaend状态，并检查sas控制器dma模块是否结束。

相比于现有技术，本发明具有以下优点：

本发明改进标准sata传输层状态机的运转机制，解决pio命令并发中的各类异常，提供对sas控制器并发控制多sata设备场景的正确支持，提升系统的吞吐率。

本发明的其它特征和优点将在随后的说明书中阐述，并且部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所指出的结构来实现和获得。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来说，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据现有技术的sas控制器与多sata设备互联的结构图。

图2示出了根据现有技术的stp传输层消息通信的典型流程图。

图3示出了根据本发明的优选实施例的传输层多个状态及迁移片段的示意图。

图4-1和图4-2分别示出了本发明状态机优化方法应用前后的效果对比时序图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地说明，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供一种支持多磁盘pio命令并发的stp传输层状态机优化方法，通过定义新的sata传输层状态机迁移条件和目的状态，改进标准sata传输层状态机的运转机制，解决pio命令并发中的各类异常，提供对sas控制器并发控制多sata设备场景的正确支持。

本发明的方案首先需要对sata标准传输层状态机中两个状态进行优化，包括：

1.hti1：ht_hostidle状态优化

表1以对照形式示出了hti1状态下的状态迁移表(应当注意的是，在表1-2中，删除线部分表示从标准sata传输层状态定义中移除的部分，粗体字部分表示在标准sata传输层状态定义基础上新增的部分，其余为继承了标准sata传输层状态定义的部分)。如表4第6项，在hti1状态已有状态转移表的基础上增加以下转移条件：如果检测到应用层数据发送请求，则将sata传输层状态机的状态迁移到ht_dmaotrans2(htda3)状态。

表1

2.hti2：ht_chktyp状态优化

如表2第8项，在ht_chktyp态下，如果检测发现接收到的fis类型为datafis，且前一个接收到的fis类型为piosetupfis，则sata标准传输层状态机不再迁移到ht_pioitrans1状态，而是统一将状态迁移到ht_dmaitrans(htda5)状态。

表2

本发明优化后的传输层状态机，有效解决了多磁盘pio命令并发时的各类异常问题，提供对sas控制器并发控制多sata设备的正确支持。

在本发明优选的实施例中，优化后的传输层相关状态迁移过程如图3所示，该状态迁移过程同样适用于sata标准业务场景。通过对sata标准传输层hti1和hti2状态机的优化，包涵了pio读命令和写命令的典型业务场景，解决背景技术所描述的状态机死循环问题。

图3所示的具体状态和迁移条件如下：

状态s1：ht_hostidle(hti1)状态，传输层空闲，等待接收sata设备发送fis，或者应用层下发命令或数据；

事件t1：sas控制器命令层配置命令寄存器，请求传输层下发pio命令给sata设备，迁移到状态s2；

状态s2：ht_cmdfis(htcm1)状态，传输层依据命令寄存器构造host-deviceregisterfis，通知链路层(link层)发送fis；

事件t2：在处于htcm1状态时，链路层将pio命令fis发送完成，迁移到状态s3；

状态s3：ht_cmdtransstatus(htcm2)状态，检查链路层和物理层fis发送是否正确结束；

事件t3：在处于htcm2状态时，pio命令h-dregisterfis正确发送，传输层返回空闲状态hti1；

事件t4：在处于传输层空闲状态hti1时，链路层检测到sata设备发送fis帧的请求(对应表1第3项)，迁移到状态s4；

状态s4：ht_chktyp(hti2)状态，传输层检查接收到的fis帧类型；

事件t5：在处于状态hti2时，传输层收到piosetupfis帧，迁移到状态s5；

状态s5：ht_ps_fis(htps1)状态，判断pio请求的数据传输方向；

事件t6：在处于htps1状态时，数据传输方向为sas控制器到sata设备，未检测到错误，fis帧内d比特为“0”，迁移到状态s6；

事件t7：在处于htps1状态时，数据传输方向为sata设备到sas控制器，未检测到错误，fis帧内d比特为“1”，传输层返回空闲状态hti1；

状态s6：ht_piootrans1(htps2)状态，将piosetupfis帧内部的寄存器内容信息保存到sas控制器内部的shadow寄存器；

事件t8：在处于htps2状态时，传输层无条件返回空闲状态hti1；

事件t9：在处于传输层空闲状态hti1时，应用层数据准备完毕，sas控制器请求发送数据到sata设备(对应于表1第6项)，迁移到状态s7；

状态s7：ht_dmaotrans2(htda3)状态，启动控制器内部dma，发送datafis至sata设备；

事件t10：在处于htps3状态时，数据传输结束，迁移到状态s8；

状态s8：ht_dmaend(htda4)状态，检查sas控制器dma模块是否结束；

事件t11：在处于htps4状态时，sas控制器dma传输结束，且未检测到错误，返回空闲状态hti1；

事件t12：在处于ht2状态时，传输层收到datafis帧(对应于表2第8项)，迁移到状态s9；

状态s9：ht_dmaitrans(htda5)状态，启动sas控制器内部dma模块，接收datafis到控制器内部存储单元；

事件t13，在处于htda5状态时，数据传输结束；传输层迁移到状态s8(即ht_dmaend状态)。

上述状态机优化方案通过对sata标准传输层状态机ht_hostidle和ht_chktyp状态的优化，有效解决了多磁盘场景下pio命令并发的各类异常。根据图3所述的状态机迁移过程，结合图2所述sas业务场景的状态机迁移顺序如下：

hti1→htcm1→htcm2→hti1→htcm1→htcm2→hti1→

hti2→htps1→htps2→hti1→hti2→htps1→htps2→hti1→

htda3→htda4→hti1→hti2→htr1→htr2→hti1→htda3→

htda4→hti1→hti2→htr1→htr2→hti1

可见，本发明优化后的状态机确保pio命令操作正常完成后，stp传输层状态机成功回到空闲状态hti1，状态机实现闭环操作。

需要说明的是，图3所示的状态机迁移过程仅用于说明而非限定本发明的技术方案。本领域技术人员应当理解，在本发明基础上可以根据实际需要而对磁盘阵列的结构以及状态机的事件数量、状态数量等做出容易想到的任意调整，而不应将本发明限于上述示例的具体结构或参数。

图4-1和图4-2是针对图2场景下sata传输层状态机的信号时序图，对比了状态机优化前后的效果。如图4-1所示，在传统模式下，从状态s1开始，即ht_hostidle(hti1)，传输层空闲，等待接收sata设备发送的fis，或者应用层下发命令或数据；当通过sas控制器的got_x_rdy信号拉高从而导致事件t1发生时，链路层上报原语接收消息，然后迁移到状态s2即ht_chktyp(hti2)，传输层检查接收到的fis帧类型；当信号got_d2h_fis拉高，即检测到fis帧类型为d-hregisterfis，导致事件t2发生时，依次状态s3和s4：即ht_regfis(htr1)状态和ht_regtransstatus(htr2)状态，成功接收d-hregisterfis的寄存器信息；然后传输层状态机返回空闲状态hti1，当hti1状态下，req_send_data信号拉高，即应用层请求传输层发送piodata导致事件t3发生时，进入状态s5即error错误状态，sata标准传输层状态机异常。因为sata标准协议未定义hti1状态下收到应用层发送piodata请求时的正确处理方式。此后，即使再将req_send_data信号拉低，状态机仍被死锁在error异常状态。

如图4-2所示，在本发明优化后的传输层状态机中，状态s1，s2，s3，s4，事件t1，t2，t3与图4-1完全一致。不同于图4-1的状态s5，采用优化后的状态迁移条件，当传输层处于hti1状态时，应用层请求发送piodata，导致事件t3发生，则状态迁移到s5即ht_dmaotrans2(htda3)状态，sas控制器启动内部dma发送datafis。当数据传输结束时，迁移到s6即ht_dmaend(htda4)状态，检查sas控制器内部dma模块是否结束；在htps4状态下，如果sas控制器dma传输结束，且未检测到错误，导致事件t4发生，则传输层状态机返回空闲状态hti1，避免了死锁状态。

由时序图清晰可见，本发明优化后的stp传输层状态机有效解决了sas控制器和多sata设备通信中，pio写命令并发操作时传输层状态机的异常问题，保证了多设备并发数据业务的正确进行。

除图2所述的一个sas控制器并发控制两个sata设备的场景之外，本发明的构思同样适用于多个sata设备的场景；即每次应用层请求发送piodata，都可通过上述状态迁移闭环回到空闲状态hti1，而不会出现状态死锁。

本领域技术人员可以预见，以类似时序图4.2的方式，优化后状态机可以有效解决pio读和写命令并发时的各类异常场景，保证sas控制器并发控制多个sata设备的数据通信业务正确完成，更加高效地利用物理链路提升了整个存储系统的吞吐率。

综上所述，本发明合理利用sata传输层状态机现有状态，弥补了sata标准协议中传输层状态机的缺陷，在不引入新状态的情况下，以最小成本有效解决了pio命令并发中的各类异常问题，完善了sata传输层对stp场景的支持，对于提升sata协议的可靠性提供了有效支撑。

尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。