SSD 是否需要使用特別的文件系統？

01-06

SSD 的工作模式和硬碟不同，是否需要特殊的文件系統，以便更好的適應它的工作方式（提高性能）呢？

首先簡單說一下SSD的特性：在SSD中，Page為最小的讀寫單位，Block為最小的擦除/編程單位，其中1個Page為4KB，1個Block由256個Page組成，1個Plane由2048個Block組成，2個Plane組成1個Die，也就是最小的晶元(4GB)。假如寫入的Page有內容，即使是一個位元組，也需要擦除整個Block，然後再寫入這個Page的內容，這個就是SSD的寫入放大問題；同時，SSD主要使用MLC SSD晶元，該晶元可以擦寫1w次（SLC可以擦寫10w次，但是價格太高使用有限），所以對於頻繁地擦寫很容易造成SSD損壞。

因此根據SSD的特性就決定了SSD的使用方式應該和普通HDD（SATA、SAS）盤有所區別，同時也應該進行相關的優化。這方面有兩個非常值得一看的成果：第一個是三星的F2FS（上面已經有人提到了），F2FS是一個log-structured file system，F2FS針對LFS的結構、wandering tree和cleaning penalty做了很多優化，是一個優秀的針對NAND Flash開發的文件系統，Linux kernel 3.8以後的內核都包含了該文件系統；第二個是俄亥俄州立大學張曉東教授的研究論文「Hystor: making the best usage of Solid State Drives in high performance storage systems」，提出了SSD與HDD的混合優化存儲方案，主體思想就是根據文件訪問頻率和文件大小的關係將文件分別存儲到SSD和HDD中，獲得非常卓越的性價比回報，目前已經應用到了上面提到過的Apple Fusion Storage（News | COLLEGE OF ENGINEERING） @齊亮和NetAPP Fusion Storage（http://www.cse.ohio-state.edu/~zhang/NetApp-hAggregates-2012.pdf）等公司的商用存儲系統中，我們自己開發的文件系統也借鑒了這種思路，效果非常明顯。

SSD是一個好東西，但需要用對用好，才能獲得最大的性價比回報。

SSD 肯定需要特殊的處理。比如 Linux kernel 里有專門處理磁頭預讀的優化（似乎這是中國人貢獻的為數不多的作用比較大的代碼），在 SSD 上可能就沒有用或者需要特殊處理。但是這種特殊處理似乎都在文件系統的級別之下。比如常說的 TRIM 就是在現有的文件系統之下發揮作用的。

個人認為，更好的適應方式必然是從頭實現一些模塊，但是計算機工業對兼容性和成本的考慮，往往傾向於保留現有的模塊，而在底層或者上層做文章。如果像 TRIM 這樣的技術能獲得成功，那麼很可能不會有針對 SSD 的文件系統。

多說一句，目前互聯網應用發展很快，TCP 層協議和應用層協議的發展也很快，但是唯獨 IPv6 步履維艱。為什麼？因為 IPv6 不是那種添加底層或者上層的協議，或者加一個 proxy/gateway 就能搞定的，而是要在巨大的路由基礎設施上搞替換。考慮這些先例，給 SSD 編寫特殊的文件系統不太可能。

理論上應該有，因為SSD的存取方式與機械硬碟有很大的不同，可以簡單歸納為：

寫入最小單位比機械硬碟大很多
數據物理位置比機械硬碟分散很多
寫入壽命比機械硬碟短
不擦除原有數據就無法寫入

目前很多問題都是靠硬體+驅動層面不靠文件系統來實現相對解決，但在文件系統方面下功夫仍然有效很多。很多人提到的F2FS就是目前最有效的解決方案，目前不少手機廠商已經開始進行嘗試。

至於為什麼現有環境下大家仍然採用傳統文件系統來使用SSD，更多的是因為成本、兼容性、穩定性，文件系統對於生產環境來說過於背景化了，帶來的優勢在短期內幾乎是0，自然大家沒有遷移的動力。

最近做了不少flash和文件系統相關的工作，論文也看了一些，試答一下。

這方面的研究其實很多。flash aware fs很多，但是大多數沒得到廣泛的使用。

對於flash，log structured file system(日誌式文件系統？)十分有利於flash上隨機寫的效率低下的問題。但這種fs通常受到garbage collection的制約。目前沒有很好的解決。

在flash以前，二級存儲大多是針對機械磁碟這樣的設備優化的。機械磁碟的連續大塊讀寫性能容易提升，而隨機讀寫受制於磁頭尋道速度，十分緩慢。磁碟的讀寫單位是塊，512位元組到4k不等。早期的文件系統為了性能，把相關的文件和目錄信息盡量聚集到一起，來提升讀寫速度。

flash出現時，這種塊式設備遍地都是，為了能推廣flash的使用，flash就模擬了塊式設備的介面，提供塊式讀寫，但內部組織是完全不同的。在邏輯塊與物理存儲間，加入ftl，進行翻譯。因此基於塊地址的優化其實都沒有用了。

flash最大的問題是大量小塊隨機寫，如果有興趣可以去查看FAST和BAST這兩種ftl。前面說到的log structured fs就很大程度上解決了隨機寫問題，但是仍然受制於垃圾回收。

另外，還有更徹底的玩法，就是無視ftl，直接暴露flash的內部物理形態給fs，由fs完全管理，這種fs完全不同於傳統fs，完全不兼容。另外，物理介面也是不同的。

希望有幫助。

寫優化的log structured fs可能在ssd上效果更好些: Log-structured file systems: There"s one in every SSD [LWN.net]

簡要地回答：不需要

原因：SSD內部存在一個FTL（Flash Translation Layer），這個FTL向上提供block介面（這的block是指塊設備的block），向下操作SSD內的存儲單元（Package）(這些操作包括但不限於：地址翻譯、損耗均衡、GC等等 )，所以在操作系統看來，SSD與HDD實際上看起來是一樣的，當然了，在kernel需要有一定的模塊作支撐.作為入門可以看一下[1].

-----------------------

扯一下其他的，長期以來，FTL作為SSD內部固件中的軟體，我們外面看不到的，不同廠商的FTL乾的事也不盡相同。OS看到的SSD就是個黑盒子.

最近，有種趨勢就是把FTL放出來，也就是把FTL拿到外面，我們再也不用把SSD當作一個黑盒，可以手動地操作，具體的哪個package、哪個die、哪個block（這的block是指SSD的Erase單位）、哪個page. 這些機制可以稱為OpenChannelSSD，能支持OpenChannelSSD的SSD廠商有Fusion I/O ,CNEX OCSSD SDK等. 反正他們是把FTL提升到OS層，這樣人們可以根據自己的需要定製FTL.目前開源的有CNEX的Lightnvm，可以看一下[2]。

感興趣的話甚至可以去玩一下Qemu，qemu-nvme提供了OCSSD的模擬.我目前也在做相關工作.

如果有了解LevelDB等實現LSM-tree的DB，LSM實際上就是一個FTL.

再稍微介紹一下OCSSD：這玩意兒在kernel上提供支持的就是lightnvm，可以看這的最近實現的一個feature：pblk target。這個target做的事就是把OCSSD Device做成一個塊設備，然後你可以在這個塊設備上進一步格式化成你喜歡的File System.

[1] Coding for SSDs - Part 1: Introduction and Table of Contents

[2] Open-Channel Solid State Drives

新的ssd讀寫速度都在原有機械硬碟的10倍左右。

windows有一個部件叫cache manager，負責和系統文件系統交互，控制緩存的。

因為交互比較多，這個部件比較複雜。

文件系統收到的寫請求，上面帶有標誌的，當出現0x43標誌時，才會認為是分頁寫請求，如果不帶0x43，則是寫緩存。

所以，要想針對ssd作優化，比較可行的方式是修改cache manager的策略。

可以看看三星開發的F2FS，專為SSD這種快閃記憶體優化的文件系統，現在已經進入linux內核樹裡面了

也許文件系統一級並不需要改變。OS X上的Fusion Drive應該是Core Storage的一個特性，特別針對SSD+HDD進行了優化，但目前還不清楚實現細節。

http://en.wikipedia.org/wiki/Fusion_drive

過去用flash做文件存貯的時候好像都用特殊的文件系統來管理這類存儲介質，像jffs,yaffs,但現在ssd硬碟都是用主控晶元來處理針對flash的操作了，應該對於操作系統而言是透明的，直接當成普通硬碟用就可以了。

我認為需要針對ssd進行優化

SSD的特點

1. 快，這個特點根本不用針對其進行什麼特殊的文件系統優化

2. 隨機讀取，不是像磁帶一樣轉到那裡才能讀，這也是跟傳統機械硬碟最大的區別，傳統文件系統為了降低轉到那裡所耗費的時間，將各個應用發起的讀寫請求（在一個很短的時間內）們，按照位置排了個順序，這樣走一趟將他們都執行了，這樣來降低機械磁碟不必要的往複轉動，SSD是隨機存取，轉到那裡的時間消耗相當於0，也就是說再進行任務排隊就是無畏的浪費了，我想這就是文件系統需要優化的地方，也就是去掉讀寫隊列，另外文件記錄結構和緩存的調整也能提高文件系統的性能

3. 寫次數的壽命短，也就是說寫的次數受限，這方面就要看文件系統的側重，統一高效的降低寫的次數貌似可能性不是很大，或者大家可以補充

that『s all thanks

一般來說是不用的。消費級的SSD為了提高性能基本上都針對4k粒度讀寫做了優化，也就是常說的4k IOPS。而一般的文件系統的粒度也是4kb，同樣在x86平台下，內存的頁也是4kb的。所以不用特別的文件系統。

如有不對請方家不吝指出。

讀寫速度快，但是有兩個問題：

1. 擦寫的放大問題，隨機寫性能下滑嚴重

2. 寫入次數壽命問題

針對第一個問題，就是一次寫入盡量滿足ssd的塊大小，也就是log structure，針對第二個問題，就是垃圾回收的策略了。

從物理特性的角度看，如果有特別優化/處理過的文件系統/資料庫系統，可以更好的發揮SSD的特性。這也是很多學術界人士在最近這些年做了很多研究的原因。正如前面一個回答所說，工業界做產品要考慮兼容性（以及成本等）的問題，短期內很難出現一個專門優化過的通用系統。但是針對某些特性應用提供特定優化的系統在互聯網等行業內應該是越來越多了。