web-dev-qa-db-ja.com

`fstrim`は毎回すべての空きブロックに書き込みを引き起こしますか?

LVMとdm-cryptを搭載した500GSSDディスクを搭載したUbuntu18.04サーバーがあります。最近、ディスクに書き込まれるバイト数(vmstat -dまたはiostatによって報告される)が非現実的に多いことに気付きました。システムI/Oを監視した後、fstrim.serviceが実行されると、ディスク書き込みの巨大なスパイクが週に1回発生することがわかりました。

bytes written

ログから、毎週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
1
Oleg

ATA trimコマンドは、ディスクドライブ内のメタデータのみを変更し、メモリセルへの低レベルの書き込みは絶対に行いません。ディスクがdeterministic trimをサポートしている場合、トリミングされたブロックはゼロで返されますが、これはtrimの時点でセルが実際に消去されたためではなく、新しいメタデータステータスに基づいてコントローラーによって行われます。コマンド。

trimコマンドは、残念ながら、私が知っているすべてのカーネル統計で書き込みとしてカウントされます。したがって、iostatまたはsarまたは/sys/fs/ext4/*/lifetime_write_kbytesは、真の書き込みとトリムの合計を返します。 スーパーユーザーに関する質問 も参照してください。

fstrimを週に1回実行すると、未使用のディスク領域全体が解放されるようです。たとえば、1 TBディスクが50%使用されている場合、デフォルトのfstrimアクティビティは、1週間あたり500GBまたは1日あたり70GBとして統計に表示されます。 。

結論は次のとおりです。書き込み統計は、特に適度に満たされたファイルシステムの場合、書き込みとしてカウントされるトリムによって簡単に支配されます。

1
wfjm