有很多在Linux中調整SSD的技巧，也有很多關於什麼工作什麼不工作的軼事報告。我們運行了自己的基準測試，並做了一些具體的調整，向您展示了真正的區別。

基準

為了對磁碟進行基準測試，我們使用了Phoronix測試套件。它是免費的，並且有一個Ubuntu的儲存庫，所以你不必從頭編譯來執行快速測試。我們在Ubuntu Natty 64位的新安裝之後，使用ext4檔案系統的預設引數測試了我們的系統。

我們的系統規格如下：

• AMD Phenom II四核@3.2 GHz
• MSI 760GM E51主機板
• 3.5 GB記憶體
• AMD Radeon 3000整合，帶512MB RAM
• Ubuntu納蒂

當然，我們以前測試的SSD是64GB OCZ Onyx驅動器（117美元亞馬遜網站在寫作時）。

突出的調整

當升級到SSD時，人們建議做一些改變。在篩選出一些舊的東西后，我們列出了Linux發行版沒有作為SSD預設值的一個小清單。其中三個涉及編輯fstab檔案，因此在繼續執行以下命令之前備份該檔案：

sudo cp /etc/fstab /etc/fstab.bak

如果出現問題，您可以始終刪除新的fstab檔案，並將其替換為備份的副本。如果您不知道這是什麼，或者您想了解它的工作原理，那麼看看HTG解釋：什麼是Linux fstab，它是如何工作的？

避開訪問時間

透過減少作業系統寫入磁碟的量，可以幫助提高SSD的使用壽命。如果需要知道上次訪問每個檔案或目錄的時間，可以將以下兩個選項新增到/etc/fstab檔案中：

noatime,nodiratime

將它們與其他選項一起新增，並確保它們都用逗號分隔，沒有空格。

啟用修剪

您可以啟用TRIM來幫助長期管理磁碟效能。將以下選項新增到fstab檔案：

discard

這對ext4檔案系統很有效，即使是在標準硬碟上。您必須擁有至少2.6.33或更高版本的核心；如果您使用的是Maverick或Natty，或者在Lucid上啟用了backports，那麼您就可以使用了。雖然這並沒有特別改善初始基準測試，但從長遠來看，它應該會讓系統表現得更好，因此它就出現在我們的列表中。

Tmpfs公司

系統快取儲存在/tmp中。我們可以告訴fstab把它作為一個臨時檔案系統安裝在RAM中，這樣你的系統就不會接觸到硬碟了。在/etc/fstab檔案底部的新行中新增以下行：

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

儲存fstab檔案以提交這些更改。

交換IO排程程式

系統不會立即將所有更改寫入磁碟，並且多個請求會排隊。預設的輸入輸出排程器（cfq）可以處理這個問題，但是我們可以將其更改為更適合我們的硬體的排程器。

首先，使用以下命令列出可用的選項，將“X”替換為根驅動器的字母：

cat /sys/block/sdX/queue/scheduler

我的安裝在sda上。你應該看到一些不同的選擇。

如果你有最後期限，你應該用它，因為它給你一個額外的調整進一步線。如果沒有，你應該能夠使用noop沒有問題。我們需要告訴作業系統在每次啟動後使用這些選項，所以我們需要編輯rc.本地檔案。

我們將使用nano，因為我們熟悉命令列，但是您可以使用任何其他您喜歡的文字編輯器（gedit、vim等）。

sudo nano /etc/rc.local

如果您使用的是截止日期，請在“退出0”行上方新增以下兩行：

echo deadline > /sys/block/sdX/queue/scheduler

echo 1 > /sys/block/sdX/queue/iosched/fifo_batch

如果使用noop，請新增以下行：

echo noop > /sys/block/sdX/queue/scheduler

再次，用適當的驅動器號替換“X”，以便安裝。仔細檢查所有的東西，確保它看起來很好。

然後，按CTRL+O儲存，然後按CTRL+X退出。

重新啟動

為了使所有這些更改生效，您需要重新啟動。之後，你應該全部準備好。如果出現問題，無法引導，可以系統地撤消上述步驟，直到您可以再次啟動為止。如果需要，您甚至可以使用LiveCD或LiveUSB進行恢復。

您的fstab更改將貫穿安裝的整個生命週期，即使經過升級，但您的rc.本地每次升級後（版本之間）都必須重新進行更改。

基準測試結果

為了執行基準測試，我們運行了磁碟測試套件。每個測試的頂部影象在調整ext4配置之前，底部影象在調整和重新啟動之後。您將看到測試測量內容的簡要說明以及對結果的解釋。

大檔案操作

此測試用隨機資料壓縮2GB檔案並將其寫入磁碟。這裡的SSD調整顯示了大約40%的改進。

IOzone透過編寫8GB檔案來模擬檔案系統性能。同樣，增長了近50%。

在這裡，一個8GB的檔案被讀取。結果與未調整ext4時幾乎相同。

AIO壓力非同步測試輸入和輸出，使用2GB的測試檔案和64KB的記錄大小。在這裡，與香草ext4相比，效能幾乎提高了200%！

小檔案操作

建立SQLite資料庫，PTS向其新增12500條記錄。SSD的調整實際上使效能降低了10%左右。

apachebenchmark測試對小檔案的隨機讀取。最佳化SSD後，效能提高了25%。

PostMark模擬25000個檔案事務，在任何給定時間同時處理500個，檔案大小在5到512KB之間。這很好地模擬了web和郵件伺服器，我們看到經過調整後效能提高了16%。

FS Mark檢視1000個總大小為1MB的檔案，並測量有多少檔案可以在預定的時間內完全寫入和讀取。我們的調整看到了一個增加，再次，較小的檔案大小。大約45%的增長與ext4調整。

檔案系統訪問

Dbench基準測試客戶機的檔案系統呼叫，有點像Samba的工作方式。在這裡，vanilla ext4的效能降低了75%，這是我們所做更改的主要倒退。

您可以看到，隨著客戶機數量的增加，效能差異也會增加。

有48個客戶機，兩者之間的差距有所縮小，但我們的調整仍然有非常明顯的效能損失。

對於128個客戶端，效能幾乎相同。你可以推斷，我們的調整可能不是理想的家庭使用這種操作，但將提供相當的效能時，客戶數量大大增加。

這個測試依賴於核心的AIO訪問庫。我們這裡提高了20%。

在這裡，我們有一個64MB的多執行緒隨機讀取，效能提高了200%！哇！

雖然使用32個執行緒寫入64MB的資料，但效能仍有75%的提高。

compilebench透過操縱核心樹（建立、編譯、修補等）來模擬檔案系統的年齡效應。在這裡，您可以透過模擬核心的初始建立看到一個顯著的好處，大約40%。

這個基準測試簡單地度量提取Linux核心所需的時間。這裡的表現沒有太大的提高。

總結

我們對Ubuntu的開箱即用ext4配置所做的調整確實產生了相當大的影響。最大的效能提升出現在多執行緒讀寫、小檔案讀寫和大連續檔案讀寫領域。事實上，我們看到的唯一真正的效能提升是在簡單的檔案系統呼叫中，這是Samba使用者應該注意的。總的來說，對於託管網頁和觀看/流式傳輸大型影片等方面來說，這似乎是一個相當穩定的效能提升。

請記住，這是專門針對Ubuntu Natty 64位的。如果您的系統或SSD不同，您的里程數可能會有所不同。總的來說，我們對fstab和IO排程器的調整似乎有助於提高效能，因此在您自己的平臺上可能值得一試。

有你自己的基準，想分享你的成果？還有什麼我們不知道的地方嗎？在評論中發聲！