今天碰到一例給虛擬機分完共享磁盤后，用戶反映虛擬機掛載共享磁盤速度比較慢的問題。SAN交換機是brocade的ds5300（FOS 6.4.2a），排除了陣列、交換機配置、SFP模塊和光纖線等的問題后，排查發現交換機上連主機的端口的er_bad_os計數器一直在持續增大，甚至會溢出后重新從0開始計數。在網上查詢后，通過修改fillword的為mode3后，er_bad_os錯誤停止。
以下是網上搜到的信息：
Brocade交換機上很多端口顯示狀態異常，通常怎樣做初步的故障排查呢？答案是通過porterrshow的輸出結果初步了解端口報錯。
但在此之前，還有一項非常重要的內容需要檢查，那就是計數器的有效性。什么是計數器的有效性？
舉個簡單的例子，倘若故障發生點為2015年12月12日，但是交換機上計數器的最后一次清空時間為2014年12月12日，那么該計數器便是無效的，因為該值為累計值，整一年的時間，滄海桑田，今非昔比，大量的歷史累積值對當前的故障排查是沒有幫助的。
那么是不是說清空計數器的時間點距離故障發生時間點越近越好？非也。若是客戶在2015年12月11日清空過計數器，可是之后客戶為了排查故障又執行過其它操作，如重啟相關主機/重置交換機端口/更換光纖模塊/光纖線等，那么該計數器也是無效的。因為此時我們看到的porterrshow輸出結果中除包含故障報錯增長外，還包含外界操作帶來的計數器增長。
另外一種情況是在發生故障之后，計數器被清空了，若是此時的清空計數器行為是為了監測之后的故障重現，這一定是高級工程師會執行的操作，更有經驗的工程師會建議先收日志再清計數器然后監測故障。若是在2015年12月12日故障發生后清空了計數器，再之后收集了日志交給工程師調查初始故障發生原因，那工程師只能含怨問蒼天了。
當計數器有效時，porterrshow的輸出結果才有了意義。
通常porterrshow輸出內容如下：
DS_5300B_1:admin> porterrshowframes enc crc crc too too bad enc disc link loss loss frjt fbsy
tx rx in err g_eof shrt long eof out c3 fail sync sig
=========================================================================================================
0: 72.6m 712.0m 0 0 0 0 0 0 0 0 0 0 0 0 0
1: 72.8m 209.5m 0 0 0 0 0 0 0 0 0 0 0 0 0
2: 4.7m 874.0k 0 0 0 0 0 0 0 0 0 0 0 0 0
3: 546.9k 335.2k 0 0 0 0 0 0 0 0 0 0 0 0 0
4: 856.1k 488.8k 0 0 0 0 0 0 0 0 0 0 0 0 0
5: 704.7k 412.6k 0 0 0 0 0 0 0 0 0 0 0 0 0
6: 72.6m 712.1m 0 0 0 0 0 0 0 0 0 0 0 0 0
7: 72.8m 209.4m 0 0 0 0 0 0 0 0 0 0 0 0 0
8: 17.9m 12.2m 0 0 0 0 0 0 238 0 0 1 0 0 0
接下來我們解釋一下各項指標代表的含義，以及我們在看到該項指標時都在關注些什么。
frames tx/rx: tx代表端口發送的數據幀，rx代表端口收到的數據幀。這兩個值反映了通過該端口的數據流量，通常可用來粗略判斷哪些端口為使用中，哪些端口為閑置狀態。
enc_in: 8bit/10bit數據幀幀內的編碼錯誤。數據的損壞會造成該值增長，因此該項指標用於標記數據幀內的編碼錯誤。有時相連末端設備重置/重啟也會造成該值增長。
crc_err: 數據幀 CRC 校驗錯誤。數據幀在Payload之后，在EOF (end of frame)之前會添加一個可用於接收端口校驗所接收數據是否損壞的校驗碼。若數據幀損壞，接收端會發現該值不一致，繼而該報錯值增長。
crc_g_eof: 數據幀 CRC 校驗錯誤，且數據幀 EOF是好的。當數據幀首次被交換機檢測到CRC錯誤時，交換機在轉發該幀時，會把EOF置為bad(EOFni)；所以后續接收該幀的交換機的端口上，只會有crc_err增長，而crc_g_eof的值保持不變，這樣就能很直觀的找到產生CRC錯誤的源頭。
too_long: 通常FC數據幀最大為 2148 字節。若EOF損壞或數據幀生成不正確，則該值隨之增長。
too_short: 如果在SOF (start of frame) 和EOF間的長度小於28(24 Header+ 4 CRC)個字節，則該值隨之增長。數據發送方故障和鏈路的不穩定均可能造成該計數器的增長。
bad_eof: 數據幀 EOF 報錯。
enc_out: 8bit/10bit 數據幀幀外編碼錯誤造成的錯誤值累積，通常反映了線纜質量問題，或末端設備異常。此外，由於末端設備的重啟帶來的端口上下線也可能會引起enc_out的增長。
disc c3: Class 3數據幀被交換機丟棄。若目標地址不可達或者源端口還沒有登錄到交換機，以及由於擁塞產生超時丟幀(timeout discards)后，該值均會增長。這個參數僅僅代表有丟包發生，但不能說是這個端口本身存在故障。
在Brocade Fabric OS微碼版本v6.3.1之前，c3 timeout discards值是不分方向的，v6.3.1之后被分為er_rx_c3_timeout和er_tx_c3_timeout兩項，rx表示接收數據，tx表示發送數據。當端口發送或者接收幀之后，會消耗掉相應的方向上的緩存，Buffer-to-Buffer credit值減少。如果超過500毫秒（默認情況下，依配置不同可能會有改變）credit值始終為0，則認為后續分發動作無法完成，丟棄尚在緩存中的幀，計數器值增加。有大量er_tx_c3_timeout數值累積的F_Port通常為性能問題的故障點，也就是我們常說的瓶頸設備。關於瓶頸設備的檢查，請參照之前的Blog“如何在博科交換機的SAN環境中排查瓶頸設備（Slow Drain Device）？”：https://community.emc.com/community/support/chinese/storagehw/blog
link fail: 當交換機端口在 LR (Link Reset)接收狀態的時間超過 R_A_TOV值時，該錯誤計數器增長。Link Reset的超時通常會導致Link Failure，且該狀態通常說明端口loss of signal 或loss of sync的時長大於R_A_TOV。
loss sync: bit 或者 transmission-word無法被准確區分確認時會引起信號同步失敗。末端設備的重啟，光纖線的拔插，或交換機端口的上下線均可能帶來該問題。
loss sig: 接收方沒有成功收到信號。與loss sync類似，末端設備的重啟，光纖線的拔插，或交換機端口的上下線都有可能信號的丟失。
link fail, loss sync, loss sig這三個報錯在鏈路初始化的過程中都會產生。而當鏈路不穩定時，這些錯誤計數值通常也會隨之增長。
frjt: class 2數據幀無法處理時會返回F_RJT報錯。
fbsy: class 2數據幀無法在E_D_TOV時間內處理時會被丟棄並返回F_BSY報錯。
frjt和fbsy用於 class 2。通常說來，FC SAN多用class 3數據幀，因此這兩類錯誤較少見，一般多出現在FICON環境中。
porterrshow的輸出結果能夠使我們對當前網絡中的所有端口報錯有一個全局性的了解，當遇到具體問題時，還需查看日志中的其它輸出以定位故障點。
#############
# 擴展：er_bad_os #
#############
在Brocade交換機中，另外一種常見的問題是不正確的填充字(fillword)配置。當該值設置有悖於最佳實踐時，我們用portstatsshow命令可以在端口上觀察到大量的er_bad_os。
對於8G及以上速率的FC鏈路，為了減少電磁干擾，T11協議組織在FC-PI-4和FC-FS-3 標准里規定了應用arb(ff)信號作為填充字。當末端設備以F_Port/8G速率連入Brocade 8G平台(Condor 2或GoldenEye2 ASIC)時，在交換機上需對fillword模式做修改。
Brocade交換機的fillword配置方式為以下4種(8G平台，Fabric OS 6.3及后續版本)：
0 | -idle-idle （默認）
使用idle信號作為端口初始化信號，使用idle作為端口填充字
1 | -arbff-arbff
使用arb(ff)信號作為端口初始化信號，使用arb(ff)作為端口填充字
2 | -idle-arbff
使用idle信號作為端口初始化信號，使用arb(ff)作為端口填充字
3 | -aa-then-ia
先嘗試模式1再嘗試模式2
EMC的最佳實踐是將fillword模式設置為3，此模式下交換機首先會嘗試先用arb(ff)信號作為端口初始化信號，並使用arb(ff)作為端口填充字；若此法不通，則嘗試用idle信號作為端口初始化信號，並使用arb(ff)作為端口填充字。
這里面提到了SAN交換機端口的一個參數fillword。大體了解一下這個參數，也不知道理解的是否正確。
Fill-Word是一種primitive signal，用於在兩個端口間傳輸狀態消息，在端口沒有用戶數據傳輸的時候，端口就會發送fillword，用來保持端口間的位和字同步。
Fillwords主要有三種，分別為IDLE、ARB（F0）和ARB（FF）。
在1G/2G/4G標准中，鏈接初始化和發送fillword，Brocade SAN交換機都用IDLE primitive signal。隨着端口速率升級到8Gbps，時鍾速度的增加，這種IDLE的模式會造成高消耗，影響了端口的鏈接問題。為了解決這個問題，在FC-PI-4和FC-FS-3標准中使用了ARB（FF）這種模式作為8G FC的fillword。
但是可惜的是，有些8Gbps的設備在ARB/ARB或IDLE/ARB模式下不能與8G FC交換機建立起正常的鏈接，因此存儲廠商和交換機廠商都有針對性的建議。
IBM針對這種情況給了類似的一些tips
http://www-947.ibm.com/support/entry/portal/docdisplay?brand=5000028&lndocid=MIGR-5083089
http://www-01.ibm.com/support/docview.wss?rs=591&uid=ssg1S1003699
HP也有這方面的說明：
Brocade公司也有類似的文檔，例如 FOS 8G Link Init Fillword Behavior v1.pdf
總結這些內容如下：
1. 在Brocade SAN交換機FOS版本為6.2.x的時候，使用IDLE也就是mode 0。
查看當前端口的工作模式，假設查看端口14，portCfgShow <PortNumber>
>portcfgshow 14
Area Number: 14
Speed Level: AUTO(HW)
Fill Word: 1(Arbff-Arbff)
修改為mode 0，portCfgFillWord <PortNumber> <Mode>
>portcfgfillword 14 0
portcfgshow 14
Area Number: 14
Speed Level: AUTO(HW)
Fill Word: 0(Idle-Idle)
2. 在FOS版本6.3.1或以上時，Brocade提供了4種fillword模式，如下：
| MODE |
MEANING |
| Mode 0 |
Use IDLE in link init and IDLE as fill word |
| Mode 1 |
Use ARB in link init and ARB as fill word |
| Mode 2 |
Use IDLE in link init and ARB as fill word |
| Mode 3 |
Try mode 1 first; if it fails then try mode 2 |
在8Gbps接口的時候，選擇使用Mode 3是合理的一個參數，至少Brocade是這么建議的，這種模式更靈活能夠適應大部分環境，與大量設備相兼容，如果還是有問題，那就需要聯系存儲廠商了。
> portcfgshow 14
Area Number: 14
Speed Level: AUTO(HW)
Fill Word: 3(A-A then SW I-A)
需要注意的是，該參數的修改都會引起端口通訊中斷，所以要注意安全哦。
參考：
http://www.aixchina.net/home/space.php?uid=39199&do=blog&id=32107
http://bbs.watchstor.com/thread-235731-1-2.html