SSDのBtrFSでTRIMサポートを確認する
SSDディスクのアレイでBtrFSを使用することを検討しており、ファイルの削除時にBtrFSが実際にTRIM操作を実行することを確認するように求められました。これまでのところ、TRIMコマンドがディスクに送信されていることを確認できませんでした。
BtrFSは本番稼働可能とは見なされていませんが、最先端のEdgeが好きなので、テストしています。サーバーは、Ubuntu 11.04サーバー64ビットリリース（mkfs.btrfsバージョン0.19）です。 BtrFS changelog がUbuntu 11.04（2.6.38）に付属のカーネルではバルクTRIMを使用できないと記載しているので、Linux 3.0.0カーネルをインストールしました。
これが私のテスト方法です（最初は 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_ - テストファイルがディスクからTRIMされていることを確認します。
./sectors.pl | tee sectors-$(date +%s) - TRIMされたブロックを確認します：
diff2つの最新の_sectors-*_ファイル
この時点で、削除前と削除後の検証では、使用中の同じディスクブロックが引き続き表示されます。代わりに、使用中のブロックの数が減少するはずです。テストファイルが削除されてから1時間待機すると（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
- HP DL160se G6
- LSI LSISAS9200-8e HBA
- ジェネリックSAS Enclosure
- Dell XPS m1210ノートパソコン
サーバーでのBtrFSの検証に何度も失敗した後、古いラップトップを使用して同じテストを試すことにしました（RAIDカードレイヤーを削除します）。ラップトップでExt4とBtrFSの両方を使用したこのテストの最初の試みは失敗します（データはTRIMされていません）。
次に、SSDドライブのファームウェアをバージョン0001（出荷時の状態）からバージョン0009にアップグレードしました。Ext4とBtrFSを使用してテストを繰り返し、両方のファイルシステムでデータのTRIMが成功しました。
TRIMコマンドを実行する時間があることを確認するために、検証を実行する前にrm /mnt/testfile && sync && sleep 120を実行しました。
これと同じテストを試行する場合に注意する必要があるのは、SSDには動作する消去ブロックがあることです（Crucial m4消去ブロックのサイズはわかりません）。ファイルシステムがTRIMコマンドをドライブに送信すると、ドライブは完全なブロックのみを消去します。ブロックの一部にTRIMコマンドが指定されている場合、消去ブロック内に有効なデータが残っているため、そのブロックはTRIMされません。
だから私が話していることを実証するために（上記のsectors.plスクリプトの出力）。これは、SSDのテストファイルにあります。ピリオドは、ゼロのみを含むセクターです。プラスには、1つ以上のゼロ以外のバイトがあります。
ドライブ上のテストファイル：
24600 .......................................+++++++++++
24650 ++++++++++++++++++++++++++++++++++++++++++++++++++
24700 ++++++++++++++++++++++++++++++++++++++++++++++++++
-- cut --
34750 ++++++++++++++++++++++++++++++++++++++++++++++++++
34800 ++++++++++++++++++++++++++++++++++++++++++++++++++
34850 +++++++++++++++++++++++++++++.....................
ドライブから削除されたテストファイル（sync && sleep 120の後）：
24600 .......................................+..........
24650 ..................................................
24700 ..................................................
-- cut --
34750 ..................................................
34800 ..................................................
34850 ......................+++++++.....................
ファイルの最初と最後のセクターは、ファイルの残りの部分とは異なる消去ブロック内にあるようです。したがって、いくつかのセクターはそのままにされました。
これからの要点：一部のExt4 TRIMテスト命令は、最初のセクターがファイルからTRIMされたことを確認することだけをユーザーに要求します。テスト担当者は、TRIMが成功したかどうかを実際に確認するために、テストファイルのより大きな部分を表示する必要があります。
RAIDカードを介してSSDに手動で発行されたTRIMコマンドは機能するが、自動TRIMコマンドは機能しない理由を理解する...
私が読んだことに基づいて、あなたの方法論に欠陥があるかもしれません。
あなたは、TRIMによってSSDが削除されたブロックをゼロ化すると想定しています。しかし、これはしばしばそうではありません。
SSDがTRIMを実装して、破棄されたブロックをゼロにする場合のみです。デバイスが少なくともdiscard_zeroes_dataを報告するのに十分な情報を持っているかどうかを確認できます。
cat/sys/block/sda/queue/discard_zeroes_data
また、SSDがゼロになる場合でも、破棄が完了した後も、SSDがブロックを実際にゼロにするまでに時間がかかることがあります（これは、一部の低品質SSDにも当てはまります）。
http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html
ところで私はTRIMを検証するための信頼できる方法を探していましたが、まだそれを見つけていません。誰かが道を見つけたら、私は知りたいです。
これは10.10とEXT4のテスト方法です。多分それは助けるでしょう。
https://askubuntu.com/questions/18903/how-to-enable-trim
ああ、私はfstabマウントにdiscardパラメーターが必要だと思います。 SSDを自動検出するはずなので、SSDパラメータが必要かどうかはわかりません。
Btrfsの場合、TRIMサポートを有効にするにはdiscardオプションが必要です。
機能的なTRIMの非常にシンプルですが実際に機能するテストは次のとおりです： http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2
SATAインターフェースを備えた事実上すべてのSSDは、完全にあなたから隠されているある種のログ構造ファイルシステムを実行します。 SATAの 'trim'コマンドは、ブロックが使用されなくなったことと、基盤となるログ構造ファイルシステムが/ if /対応する消去ブロック（かなり大きくなる可能性があります）/ only /がトリムでマークされたブロックを含むことをフラッシュできることをデバイスに通知します。
私はここにある標準のドキュメントを読んでいません： http://t13.org/Documents/MinutesDefault.aspx?keyword=trim ですが、標準レベルの保証があるかどうかはわかりませんあなたはトリムコマンドの結果を見ることができるでしょう。消去ブロックの開始時に最初の数バイトがゼロになるなどの変化が見られる場合、これがさまざまなデバイスやファームウェアバージョンに適用できる保証はないと思います。
抽象化の実装方法について考える場合、トリムコマンドの結果を、ブロックの読み取り/書き込みを行うだけのユーザーには完全に見えなくすることができるはずです。さらに、フラッシュ変換層だけがそれを認識すればよく、それらを論理的に並べ替えた可能性があるため、どのブロックが同じ消去ブロックにあるのかを見分けるのが難しい場合があります。
おそらく、SSDフラッシュ変換レイヤーに関連するメタデータをフェッチするためのSATAコマンド（おそらくOEMコマンド？）がありますか？
考えるべきいくつかのこと（「何かが足りないのですか？」という質問に答えるために）：
/ dev/sdaとは正確には何ですか？シングルSSD？または（ハードウェア？）RAIDアレイのSSD？
後者の場合、どのようなRAIDコントローラですか？
そしてあなたのRAIDコントローラはTRIMをサポートしていますか？
そして最後に、
- テスト方法では、/ dev/sda1をbtrfs以外でフォーマットした場合に期待する結果が得られますか？