我昨天在《FPGA搞不定LDPC?分布式ECC助陣SSD》一文中拋出了“磚”之后，果真引到了“玉”。

一位來自Fusion-io的朋友站出來說：“我們現(xiàn)在的LDPC是FPGA的。”

另一位朋友則表示：“LDPC用軟件實現(xiàn)就可以了，放硬件里不費事么?FPGA中的core就可以處理LDPC了。”

我們再看看昨天那幾位大牛后來怎么說。

J君：“至于FPGA內(nèi)能否放入大邏輯面積的糾錯控制器(如BCH72bit，LDPC等)，那要看你用什么FPGA。”

F君：“現(xiàn)在的FPGA有能實現(xiàn)BCH72帶寬3GB/s的嗎?

原來的Flash出錯概率低，可以很多通道共享一個ECC引擎，現(xiàn)在不行了，需要更多引擎。

比如原來的數(shù)據(jù)帶寬是3GB/s，但因為出錯概率低，可能ECC達到500MB/s的糾錯帶寬就行了。”

L君：“不能用硬盤那套LDPC來套用到SSD，第一是信道模型不同，第二是出錯BER和糾錯要求不一樣，第三是帶寬和性能差了1-2個數(shù)量級。

所以現(xiàn)在是ECC帶寬限制SSD帶寬。

提高ECC帶寬主要有集中思路，硬件上就是

1. 提升ECC硬件芯片頻率;

2. 提升譯碼并行度，增大矩陣計算量64*64 –128*128等;

3. 針對LDPC算法和計算邏輯進行深度優(yōu)化，譯碼QoS，負載均衡調(diào)度等。高性能LDPC本身就是并行分布式的，放不同邏輯上面做還是由于性能高后邏輯資源不夠。

軟件層面考慮，就是和FTL深度整合了，后期用容量換性能，要求彈性FTL，占用戶存儲空間，不過這個相當(dāng)復(fù)雜，涉及用戶數(shù)據(jù)搬移，以及非結(jié)構(gòu)化FTL，沒見真正做出來。”

S君：“是說FTL在host端么?我認(rèn)為這是趨勢。”

L君：“其實并不一定是在host，SSD主控本身功能做強也能實現(xiàn)彈性FTL，不過要加CPU，純FPGA搞不定。

如果算法全做host，對硬件控制器公司就是災(zāi)難。

按照這種做法，就是白牌服務(wù)器的做法。用戶直接找個代工廠，用標(biāo)準(zhǔn)解決方案就行，SSD只提供讀寫擦，ECC三種基本功能，其它全軟件做。”

P君：“要把一些CPU計算放進ASIC里面。”

L君：“沒錯，要跟CPU搶業(yè)務(wù)才能提高門檻，學(xué)術(shù)性講就是降低CPU負載。”

S君：“我的觀點是充分利用CPU，以后多路服務(wù)器CPU的能力根本用不完，內(nèi)存都可能爆過外設(shè)。盡量去用CPU而不是降低CPU使用。

將FTL放到host，還可以綁定應(yīng)用，使得用戶程序更快。”

Q君：“有點軟件定義閃存的概念。”

看著看著，以我的水平根本插不上嘴，剩下的只會叫好了。于是就干脆把以上的討論分享給大家。

翻了翻之前寫過的東西，我在上一次討論Host-based與Device-based之爭時，就提出過“越接近CPU越有利于軟件定義”。

所謂軟件定義閃存，之前我也看到百度提出過這個概念，不過那個還不屬于通用的商業(yè)產(chǎn)品。具體到PCIeSSD上，偏“軟”的——即Host-Based架構(gòu)的代表Fusion-io，支持Atomic-write(原子寫，參考《十億IOPS不是夢?Fusion-io閃存API另類分析》一文);后來還推出那個專門針對MySQL數(shù)據(jù)庫優(yōu)化，壓縮并且還提高性能的文件系統(tǒng)(見下圖)。

回到今天的主題，在《破解PCIeSSD進化：從踩坑到解決方案》一文中，筆者并沒有討論Host-Based和Device-Based。當(dāng)時不是沒考慮過這一點，但對于普通用戶來說，這個架構(gòu)差異對實際使用體驗的直接影響并不是很大。但對于業(yè)內(nèi)專業(yè)人士則不同了，比如在本月16日舉行的《存儲技術(shù)之巔》第一次線下交流活動中，大家就展開了熱烈的討論。

在本文的標(biāo)題之前，似乎應(yīng)該加個定語“使用FPGA主控的PCIeSSD”，因為目前ASIC控制器的卡，以PMC/IDT系和Intel為主基本都是Device-Based，不存在與Host-Based兩條技術(shù)路線之爭。

所謂Host-Based，即SSD的FTL——包括地址轉(zhuǎn)換/塊分配(通常所說的LBA)、磨損平衡和垃圾回收在OS驅(qū)動層實現(xiàn)。

而Device-Based則利用卡上FPGA控制器的處理資源來實現(xiàn)FTL，操作系統(tǒng)上安裝的驅(qū)動應(yīng)該不包含這部分工作。

在國內(nèi)最早宣傳Device-Based PCIeSSD的大約就是Memblaze，下面我們也來看看另外一家Shannon寶存科技是如何來對比二者的。

Host-Based的缺點是需要PCIeSSD容量1/1000的內(nèi)存來放元數(shù)據(jù)，比如6.4TB的卡大約就是6.4GB，這一點上Device-Based完勝。那么容量、效率和靈活性這幾點，我覺得可以歸結(jié)為一點——Device-Based卡上的FPGA需要干更多工作，功耗和發(fā)熱也許會大些?另外可能會受其處理能力的限制。

Device-Based溫度會不會更高?

關(guān)于這個問題，我曾聽說國外一家大品牌PCIeSSD的工作溫度能達到90多攝氏度(注：應(yīng)該不是Device-Based架構(gòu)，這里指主控散熱片表面溫度)，也就是說沒有必然性?

但到了SFF-8639和NVMe時代之后，F(xiàn)PGA的處理性能和散熱確實成為不可忽視的因素了(至少在Device-Based卡上如此)，因此我們看到了PMCASIC主控的PBlaze4。

Host-Based能否實現(xiàn)NVMe?

由于NVMe在操作系統(tǒng)中集成標(biāo)準(zhǔn)驅(qū)動，那么Host-Based在驅(qū)動中實現(xiàn)FTL這種方式還可行嗎?寶存表示他們有“曲線救國”的方法，具體還不方便透露。據(jù)我所知，NVMe也允許個性化驅(qū)動，比如像希捷/LSINytro那樣的方案，SAS控制器也是能夠支持NVMe的。

RAID如何實現(xiàn)?

為了讓PCIeSSD像硬盤那樣支持RAID保護，Memblaze和寶存分別提出了自己的方案。

上圖來自寶存在Flash Memory Summit2014上的演講《Buildingefficient RAID-5 systems across SSDs at the FTLLayer》，我們看到這個跨盤的RAID還帶有硬件加速，可能是使用FPGA的加速單元來做RAID5 XOR計算吧。

另一方面，我聽說Memblaze的RAID實現(xiàn)有點類似于Linux下的LVM(鏡像)?而且他們這款產(chǎn)品(應(yīng)該還是FPGA)已經(jīng)帶有一些Host-Based的色彩了。

不知大家有沒有Host-Based和Device-Based向融合發(fā)展的感覺?

提起HostRAID，筆者又想起了自己在10年前踩過的坑。

2003年，Adaptec在Ultra320SCSI上引入HostRAID0/1的支持，無需硬件RAID卡就能做簡單的陣列級別。我當(dāng)時推薦銷售在2個客戶的機器上用29320卡分別做的RAID0和1，結(jié)果在Windows下都出現(xiàn)了死機的問題，經(jīng)過反復(fù)排查才發(fā)現(xiàn)是卡的問題——確切說應(yīng)該是當(dāng)時HostRAID驅(qū)動還不成熟。

注意：Adaptec要支持那個HostRAID就不能使用普通的SCSI驅(qū)動，而LSI的SCSI卡(53C1020/1030)同樣的功能則對驅(qū)動程序透明。他們2個真的有點像今天的Host-Based和Device-Based，雖說做RAID0/1對CPU等資源的占用基本可以忽略不計。

還是那句話，穩(wěn)定的產(chǎn)品不是測出來的，但也少不了測試。

我又班門弄斧地寫了以上這些，不專業(yè)之處還望大家多指正。

本文出自黃亮的微信公眾號，企業(yè)存儲技術(shù)（微信號：huangliang_storage），歡迎大家關(guān)注！