Linux、SSD、BTRFS、およびトリム
SSD（480GBネットのToshiba Q300）にBTRFSファイルシステムがインストールされたLinuxシステム（Gentooベース）を実行しています。私の/etc/fstabは次のようになります：
UUID=14cb9b65-... swap swap defaults,noatime, 0 0
UUID=cd7d93b3-... / btrfs defaults,cache,compress=lzo,subvol=@ 0 1
UUID=cd7d93b3-... /home btrfs defaults,noatime,space_cache,compress=lzo,subvol=@home 0 2
UUID=cd7d93b3-... /Data btrfs defaults,noatime,space_cache,compress=lzo,subvol=@Data 0 2
UUID=cd7d93b3-... /mnt/rootfs btrfs defaults,noatime,space_cache,compress=lzo 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 tmpfs /proc proc defaults 0 0
tmpfs /var/log tmpfs defaults,noatime,rw,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,rw,mode=1777 0 0
tmpfs /var/run tmpfs defaults,noatime 0 0
tmpfs /var/spool tmpfs defaults,noatime 0 0
tmpfs /var/lock tmpfs defaults,noatime 0 0
tmpfs /var/cache tmpfs defaults,noatime 0 0
tmpfs /run tmpfs defaults,noatime 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
devtmpfs /dev devtmpfs gid=5,mode=620 0 0
以前は、XFSファイルシステムを備えた240GBネットのIntelSSDを持っていました。そのXFSシステムに対してfstrim -v /を実行すると、次のようなメッセージが表示されました。
8ギガバイトがトリミングされました。
さて、480GByte Toshiba SSDのトップレベルには、次のようないくつかのサブボリュームがあります。
# btrfs subvolume list /mnt/rootfs
ID 264 gen 273 top level 5 path @_original_install
ID 265 gen 152 top level 5 path @home_install_ok
ID 266 gen 270 top level 5 path @_snapshot_install_ok
ID 267 gen 28504 top level 5 path @
ID 275 gen 28504 top level 5 path @home
ID 276 gen 26900 top level 5 path @Data
ID 607 gen 245 top level 5 path @_snapshot_home_20160330
ID 628 gen 3837 top level 5 path @_root_snapshot_20160402
fstrimコマンドを開始すると、次の結果が表示されます。
***************************************** # fstrim -v /mnt/rootfs/@ 177,3 GiB (190331097088 Bytes) getrimmt *****************************************
トリミングされたスペースの量が、古いXFS形式の240 GB SSDのように8または10ではなく、177 GiBであるのはなぜですか？
最初のトリミングの直後に480GBのToshibaSSDを再度トリミングした後、結果はほぼ同じで、172 GiBがトリミングされました。したがって、fstrimはBTRFSでは機能しませんか？
そして、サブボリュームがどのように機能するか、メタデータについてなど、BTRFSを説明する（非常に）優れたチュートリアル/ウェブサイトなどを知っていますか？
最新のbtrfs-progs（私はバージョン4.4.1を使用）に関する情報が多いほど良いです。ドイツ語ならそれも素晴らしいでしょう...
また、トリミング時、または頻繁にトリミングする場合、SSDに有害ですか？
BTRFS Wiki FAQから：
BtrfsはSSD用に最適化されていますか？
SSDドライブにはいくつかの最適化があり、-ossdを使用してマウントすることでそれらを有効にできます。 2.6.31-rc1以降、Btrfsが非回転ストレージを検出できる場合、このマウントオプションが有効になります。 SSDは将来のストレージの大きな部分になる予定であり、Btrfsの開発者はSSDを大幅に調整することを計画しています。 -ossdはTRIM/discardを有効にしないことに注意してください。
-o ssdでマウントしていないようです。おそらくあなたのbtrfs-progsはそれをSSDとして検出していません。 （/sys/block/sdX/queue/rotationalが0かどうかをチェックします。）
「-o ssdはTRIM /破棄を有効にしません」おそらく過度の上書きはSSDドライブの消耗を早めるためです。
fstrimのマンページには次のように書かれています。
fstrimを頻繁に実行するか、mount -o discard[TRIMを永続的にオンにする]を使用すると、低品質のSSDデバイスの寿命に悪影響を与える可能性があります。ほとんどのデスクトップおよびサーバーシステムでは、十分なトリミング頻度は週に1回です。すべてのデバイスがキュートリムをサポートしているわけではないため、各トリムコマンドは、その時点でディスクを使用しようとしている他のデバイスに対してパフォーマンスの低下を招くことに注意してください。
また、BTRFSの CoW（copy-on-write） はSSDに有利であり、不要な上書きを最小限に抑えるため、BTRFSではTRIMはそれほど必要ではありません。 SSD上の非CoWファイルシステムneedTRIMをオンにします。
トリミングされたスペースの量が、古いXFS形式の240 GB SSDのように8または10ではなく、177 GiBなのはなぜですか？
おそらく、ssd_spreadがオンになっていないことに関連しているので、より大きく、断片化されていない空き領域があります。
ssd_spreadマウント-o ssd_spreadは、新しい割り当てのためにディスクの大きな未使用領域を見つけることについてより厳密です、時間の経過とともに空き領域が断片化する傾向があります。多くの場合、安価なSSDデバイスの方が高速です。
東芝Q300はローエンドSSDであるため、ssd_spreadマウントオプションをオンにする必要があります。
fstrimはBTRFSでは機能しませんか？
します。 BTRFSマウントオプションページ は「fstrimコマンドを定期的に実行できます」と言っています。
そして、サブボリュームの仕組みやメタデータについてなど、BTRFSを説明する（非常に）優れたチュートリアル/ウェブサイトなどを知っていますか？
これは最高のBTRFSリソースです： https://btrfs.wiki.kernel.org/
btrfs-subvolume manpage は良いです。 Sysadminガイドのサブボリュームセクション もそうです。 btrfsQuota.py は、スナップショット/サブボリュームとメタデータのサイズを理解するための優れたスクリプトです。
最新のbtrfs-progs（バージョン4.4.1を使用）に関する情報が多いほど良いです。
最新はバージョン 4.5. です。
ドイツ語ならそれも素晴らしいでしょう...
自動バックアップとスナップショットを実行するためにBTRFSを活用するための btrbk Perlスクリプトを強くお勧めします。それは本当にBTRFSの力を示しています。著者 Axel Burri はスイスのチューリッヒ出身で、ドイツ語の名を持っていることから、ドイツ語も知っている可能性があります。おそらく彼はあなたにいくつかのドイツのBTRFSリソースを指摘することができます。
また、WorldCatで検索すると、この本はBTRFSについて言及していますが、やや時代遅れです（2011）：
- リーベル、オリバー。 2011. LinuxHochverfügbarkeit：EinsatzszenarienundPraxislösungen 。 [S.l.]：ガリレオプレス。
Udevを使用して、ssdを非回転ドライブに設定します。
10-ssd.rules（またはその他）というファイルを/etc/udev/rules.d/に編集/追加し、次のような行を挿入します。
ACTION == "add | change"、KERNEL == "sd [az]"、ATTR {queue/rotational} == "0"、ATTR {queue/scheduleer} = "mq-deadline"（これにより、私のioschedulerが設定されますssdからmq-deadline、あなたはこのようになります
ACTION == "add | change"、KERNEL == "sda"、ATTR {queue /ローテーション} == "0"（sdaはssd、uidkはUIDSを使用できる場合は、マニュアルで正しい設定を確認してください。カーネルがそれをサポートしている場合は、ATTR {queue/scheduler} = "mq-deadline"も追加できます。これは、ssdsとmqの方が高速であり、通常のioschedulerがデバイスごとに選択できるようになったためです）
Fstabでrw、lazytime、compress = zstd、ssd、space_cache = v2のようなものを使用し、明らかにサブボリューム構成を調整します。
再起動後にすべてが機能した場合は、cat/sys/block/sda/queue/rotationalの場合は0、cat/sys/block/sda/queue/schedulerの場合はmq-deadlineと表示されます。
その後、fstrim-vaがドライブで機能するはずです。常に破棄を発行するべきではないので、fstrimを頻繁に実行するsystemdタイマーを追加することをお勧めします。