使用 SSD 上的 BtrFS 驗證 TRIM 支持
我們正在研究在 SSD 磁碟陣列上使用 BtrFS，並且有人要求我驗證 BtrFS 確實在刪除文件時執行 TRIM 操作。到目前為止，我無法驗證 TRIM 命令是否已發送到磁碟。
我知道 BtrFS 不被認為是生產就緒的，但我們喜歡最前沿，因此我正在測試它。伺服器是 Ubuntu 11.04 伺服器 64 位版本（mkfs.btrfs 版本 0.19）。我已經安裝了 Linux 3.0.0 核心，因為BtrFS 更改日誌指出批量 TRIM 在 Ubuntu 11.04 (2.6.38) 附帶的核心中不可用。
這是我的測試方法（最初從http://andyduffell.com/techblog/?p=852採用，經過修改以使用 BtrFS）：
- 在開始之前手動修剪磁碟：
for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done- 驗證驅動器是否已修剪：
./sectors.pl |grep + | tee sectors-$(date +%s)- 分區驅動器：
fdisk /dev/sda- 製作文件系統：
mkfs.btrfs /dev/sda1- 山：
sudo mount -t btrfs -o ssd /dev/sda1 /mnt- 創建一個文件：
dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct- 驗證文件是否在磁碟上：
./sectors.pl | tee sectors-$(date +%s)- 刪除測試文件：
rm /mnt/testfile- 看到測試文件是從磁碟修剪的：
./sectors.pl | tee sectors-$(date +%s)- 驗證 TRIM’d 塊：
diff兩個最近的sectors-*文件此時，刪除前和刪除後驗證仍然顯示相同的磁碟塊正在使用中。相反，我應該看到正在使用的塊數量減少。在刪除測試文件後等待一個小時（如果需要一段時間才能發出 TRIM 命令）仍然顯示相同的塊正在使用中。
我也嘗試過使用這些
-o ssd,discard選項進行安裝，但這似乎根本沒有幫助。從上面創建
fdisk的分區（我保持分區很小，以便驗證更快）：root@ubuntu:~# fdisk -l -u /dev/sda Disk /dev/sda: 512.1 GB, 512110190592 bytes 255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x6bb7542b Device Boot Start End Blocks Id System /dev/sda1 63 546209 273073+ 83 Linux我的
sectors.pl腳本（我知道這是低效的，但它完成了工作）：#!/usr/bin/perl -w use strict; my $device = '/dev/sda'; my $start = 0; my $limit = 655360; foreach ($start..$limit) { printf "\n%6d ", $_ if !($_ % 50); my @sector = `/sbin/hdparm --read-sector $_ $device`; my $status = '.'; foreach my $line (@sector) { chomp $line; next if $line eq ''; next if $line =~ /$device/; next if $line =~ /^reading sector/; if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) { $status = '+'; } } print $status; } print "\n";我的測試方法有缺陷嗎？我在這裡錯過了什麼嗎？
謝謝您的幫助。
因此，經過多天的努力，我能夠證明 BtrFS 確實使用了 TRIM。我無法在我們將部署這些 SSD 的伺服器上成功地進行 TRIM 工作。但是，當使用插入筆記型電腦的同一驅動器進行測試時，測試會成功。
用於所有這些測試的硬體：
- Crucial 英睿達 m4 SSD 512GB
- 惠普 DL160se G6
- LSI LSISAS9200-8e HBA
- 通用 SAS 機櫃
- 戴爾 XPS m1210 筆記型電腦
在多次嘗試驗證伺服器上的 BtrFS 失敗後，我決定使用舊筆記型電腦嘗試相同的測試（移除 RAID 卡層）。在膝上型電腦上使用 Ext4 和 BtrFS 進行此測試的初始嘗試失敗（數據未經過 TRIM 處理）。
然後，我將 SSD 驅動器韌體從版本 0001（開箱即用）升級到版本 0009。使用 Ext4 和 BtrFS 重複測試，兩個文件系統都成功地修剪了數據。
為了確保 TRIM 命令有時間執行，我
rm /mnt/testfile && sync && sleep 120在執行驗證之前做了一個。如果您嘗試進行相同的測試，需要注意的一件事是：SSD 具有可操作的擦除塊（我不知道 Crucial m4 擦除塊的大小）。當文件系統向驅動器發送TRIM命令時，驅動器只會擦除一個完整的塊；如果為塊的一部分指定 TRIM 命令，則由於擦除塊中剩餘的有效數據，該塊將不會被修剪。
因此，為了展示我在說什麼（
sectors.pl上面腳本的輸出）。這是SSD上的測試文件。句點是只包含零的扇區。加號有一個或多個非零字節。驅動器上的測試文件：
24600 .......................................+++++++++++ 24650 ++++++++++++++++++++++++++++++++++++++++++++++++++ 24700 ++++++++++++++++++++++++++++++++++++++++++++++++++ -- cut -- 34750 ++++++++++++++++++++++++++++++++++++++++++++++++++ 34800 ++++++++++++++++++++++++++++++++++++++++++++++++++ 34850 +++++++++++++++++++++++++++++.....................從驅動器中刪除的測試文件（在 a 之後
sync && sleep 120）：24600 .......................................+.......... 24650 .................................................. 24700 .................................................. -- cut -- 34750 .................................................. 34800 .................................................. 34850 ......................+++++++.....................看起來文件的第一個和最後一個扇區與文件的其餘部分位於不同的擦除塊內。因此，一些行業沒有受到影響。
一個外賣形式：一些 Ext4 TRIM 測試說明要求使用者僅驗證第一個扇區是從文件中修剪的。測試人員應該查看大部分測試文件以真正了解 TRIM 是否成功。
現在要弄清楚為什麼手動發出通過 RAID 卡發送到 SSD 的 TRIM 命令可以工作，但自動 TRIM 命令不能…