LVMとdm-cryptを搭載した500GSSDディスクを搭載したUbuntu18.04サーバーがあります。最近、ディスクに書き込まれるバイト数(vmstat -d
またはiostat
によって報告される)が非現実的に多いことに気付きました。システムI/Oを監視した後、fstrim.service
が実行されると、ディスク書き込みの巨大なスパイクが週に1回発生することがわかりました。
ログから、毎週fstrim
を実行すると、システムがほぼアイドル状態で、最大で1週間で10Gbをわずかに下回っていても、基本的にすべての空き領域がディスクに書き込まれたことが報告されているようです。
これは予想される動作ですか?前回のfstrim
の実行以降の新しい空きブロックのみを破棄する必要があると常に考えていましたが、毎回空き領域全体を破棄する必要はありません。これにより、SSDの摩耗が異常に高くなります(ディスクで報告されているメディアの摩耗値から判断すると)。それとも、dm-crypt
の存在に何らかの形で関係していますか?
ディスクはTRIMをサポートしています。
hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM
また、パススルーの破棄はdm-crypt
でも有効になっています。
dmsetup table
silverbox--vg-swap: 0 19529728 linear 253:0 917964800
silverbox--vg-root: 0 917962752 linear 253:0 2048
sda3_crypt: 0 937496576 crypt aes-xts-plain64 00...0 0 8:3 4096 1 allow_discards
ATA trim
コマンドは、ディスクドライブ内のメタデータのみを変更し、メモリセルへの低レベルの書き込みは絶対に行いません。ディスクがdeterministic trim
をサポートしている場合、トリミングされたブロックはゼロで返されますが、これはtrim
の時点でセルが実際に消去されたためではなく、新しいメタデータステータスに基づいてコントローラーによって行われます。コマンド。
trim
コマンドは、残念ながら、私が知っているすべてのカーネル統計で書き込みとしてカウントされます。したがって、iostat
またはsar
または/sys/fs/ext4/*/lifetime_write_kbytes
は、真の書き込みとトリムの合計を返します。 スーパーユーザーに関する質問 も参照してください。
fstrim
を週に1回実行すると、未使用のディスク領域全体が解放されるようです。たとえば、1 TBディスクが50%使用されている場合、デフォルトのfstrim
アクティビティは、1週間あたり500GBまたは1日あたり70GBとして統計に表示されます。 。
結論は次のとおりです。書き込み統計は、特に適度に満たされたファイルシステムの場合、書き込みとしてカウントされるトリムによって簡単に支配されます。