ソリッドステートドライブ

関連記事

• ソリッドステートドライブ/NVMe
• ソリッドステートドライブ/メモリセルの消去
• ベンチマーク/データストレージデバイス
• パフォーマンスの最大化#ストレージデバイス
• Flashcache

この記事では、ソリッドステートドライブ (SSD) や他のフラッシュメモリベースのストレージデバイスの取り扱いに関するトピックをカバーしています。

特定の目的のために SSD をパーティショニングしたい場合、フラッシュメモリ向けに最適化されたファイルシステムのリストで検討すると良いかもしれません。

一般的な利用では、自由にファイルシステムを選び、#TRIM を有効化すると良いでしょう。

使用法

TRIM

ほとんどの SSD は、長期的なパフォーマンスの維持とウェアレベリングのための ATA_TRIM コマンドをサポートしています。TechSpot 記事では、SSD をデータで埋める前と後でのパフォーマンスベンチマークの例が示されています。

Linux カーネルバージョン 3.8 以降、異なるファイルシステムに対する TRIM のサポートが継続的に追加されました。概要は以下の表を見てください:

ファイルシステム	連続的な TRIM (discard オプション)	定期的な TRIM (fstrim)	参照 と備考
Btrfs	Yes	Yes
exFAT	Yes	Yes	fstrim はカーネル 5.13 以降、サポートされています。[1]
ext3	Yes	Yes
ext4	Yes	Yes	[2] の "discard, nodiscard(*)"
F2FS	Yes	Yes
JFS	Yes	Yes	[3]
NILFS2	Yes	Yes
NTFS-3G	No	Yes	バージョン 2015.3.14 以降 [4]
VFAT	Yes	Yes	fstrim はカーネル 4.19 以降、サポートされています。[5]
XFS	Yes	Yes	[6]

警告: TRIM を試みる前に、SSD が TRIM をサポートしていることを確認する必要があります。さもないと、データを失うかもしれませんよ!

TRIM のサポートを確認するには、以下を実行してください:

$ lsblk --discard

そして、DISC-GRAN (discard granularity) と DISC-MAX (discard max bytes) 列の値を確認してください。値が 0 でなければ、TRIM をサポートしていることを意味します。

SATA SSD の場合にのみ、hdparm パッケージは、hdparm -I /dev/sda | grep TRIM を root ユーザとして実行することにより、TRIM サポートを検出することができます。hdparm は、NVMe SSD をサポートしていません。

定期的な TRIM

util-linux パッケージは fstrim.service と fstrim.timer systemd ユニットファイルを提供しています。タイマーを有効化すれば毎週サービスが実行されます。このサービスは、discard 操作をサポートしているデバイス上のマウント済みのファイルシステムすべてに対して fstrim(8) を実行します。

タイマーは最後に実行してから一週間経過したことを知るために (最初に実行したときに作成される) /var/lib/systemd/timers/stamp-fstrim.timer のタイムスタンプを使います。そのため、anacron のように、何度も頻繁に実行される恐れはありません。

ユニットの活動と状態を取得するには、journalctl を見てください。タイマーの周期や実行されるコマンドを変更するには、提供されているユニットファイルを編集してください。

連続的な TRIM

ノート: fstrim を定期的に実行しているのであれば、連続的な TRIM を有効化する必要はありません。TRIM を使いたいのであれば、定期的な TRIM か連続的な TRIM のどちらか一方を使ってください。

TRIM コマンドを定期的に (fstrim.timer を使用する場合はデフォルトで1週間に1度) 発行するのではなく、ファイルが削除されるたびに TRIM コマンドを発行することも可能です。後者は、連続的な TRIM (continuous TRIM) として知られています。

警告: SATA 3.1 以前ではすべての TRIM コマンドはキューされなかったので、連続的な TRIM はシステムを頻繁にフリーズさせていました。この場合、低頻度で #定期的な TRIM を適用するのがより良い代替策です。また、深刻なデータ破損を引き起こすためキューに入れられた TRIM コマンドの実行がブラックリスト化されているデバイスの多くでも似たような問題が発生します (Linux ソースコードの ata_device_blacklist を参照)。そのような場合、デバイスにも依りますが、システムはキューの TRIM コマンドではなく非キューの TRIM コマンドを SSD に送信することを強制される場合があります。詳細は Wikipedia:ja:TRIM#短所 を見てください。

ノート: 連続的な TRIM は、TRIM コマンドを発行する方法として Linux コミュニティの間で最も好まれているわけではありません。例えば、Ubuntu は定期的な TRIM をデフォルトで有効化しており [7]、Debian は 連続的な TRIM の使用を推奨しておらず、Red Hat は可能であれば連続的な TRIM よりも定期的な TRIM を使用することを推奨しています [8]。

/etc/fstab 内で discard オプションを使うことにより、デバイスオペレーションでの連続的な TRIM を有効化します:

/dev/sda1  /           ext4  defaults,discard   0  1

ノート: XFS / パーティションの場合、/etc/fstab 内で discard オプションを指定しても、うまく行きません。このスレッドによると、rootflags=discard カーネルパラメータを使用して設定しなければならないようです。

ext4 ファイルシステムでは、tune2fs を使って discard フラグをデフォルトマウントオプションとして設定することもできます:

# tune2fs -o discard /dev/sdXY

外部ドライブの場合は、/etc/fstab 内のエントリではなくデフォルトマウントオプションを使うと便利です。そのようなパーティションは、他のマシンでもデフォルトのオプションを使ってマウントされるからです。この方法では、すべてのマシンで /etc/fstab を編集する必要はありません。

ノート: デフォルトマウントオプションは、/proc/mounts にリストアップされません。

デバイス全体を trim する

一度に SSD 全体を trim したい場合 (例えば、新しいインストールのためや、そのドライブを売りたい場合など)、blkdiscard コマンドが使えます。

LVM

ファイルシステムから論理ボリュームへ渡された TRIM 要求は、自動的に物理ボリュームへ渡されます。追加の設定は必要ありません。

デフォルトでは、LVM のオペレーション (lvremove、lvreduce、そしてその他すべて) は物理ボリュームに TRIM 要求を発行しません。これは、vgcfgrestore(8) を使って以前のボリュームグループ設定を復元できるようにするためです。/etc/lvm/lvm.conf 内の issue_discards は、論理ボリュームがその基底となる物理ボリュームの領域をもはや使用しなくなった時に、その物理ボリュームに discard 要求を送信するかどうかを制御します。

ノート: issue_discards の設定を変更する前に /etc/lvm/lvm.conf 内のコメントをよく読んでください。この設定は、ファイルシステムからディスクへ渡される TRIM 要求 (例: ファイルシステム内でのファイル削除) には全く影響を与えませんし、シンプール内の領域管理にも影響を与えません。

警告: issue_discards を有効化すると、vgcfgrestore によるボリュームグループメタデータの復元ができなくなります。LVM コマンドを誤って発行した場合のリカバリオプションは無くなります。

dm-crypt

警告: discard オプションは、暗号化されているブロックデバイスを通して discard 要求を渡せるようにします。これは、SSD ストレージのパフォーマンスを向上させるかもしれませんし、しないかもしれません[9]。しかし、セキュリティに影響を与えます。詳細は以下の記事を見てください:

• Debian:SSDOptimization#Mounting SSD filesystems
• dm-crypt/特記事項#ソリッドステートドライブ (SSD) の Discard/TRIM のサポート

ルート以外のファイルシステムの場合、/etc/crypttab を編集して、SSD 上の暗号化されているブロックデバイスのオプションリストに discard を追加してください (dm-crypt/システム設定#crypttab を見てください)。

ルートファイルシステムの場合、dm-crypt/特記事項#ソリッドステートドライブ (SSD) の Discard/TRIM のサポート の指示に従って、ブートローダーの設定に適切なカーネルパラメータを追加してください。

パフォーマンスを最大化する

パフォーマンスの最大化#ストレージデバイス のヒントに従ってドライブのパフォーマンスを最大化しましょう。

セクタサイズ

Advanced Format#ソリッドステートドライブ を見てください。

SSD のメモリセルのクリア

時々、SSD のセルを完全にリセットしてデバイスにインストールした時と同じ初めの状態にすることで製造時の書き込みパフォーマンスを取り戻したいと思うことがあるかもしれません。SSD の書き込みパフォーマンスはネイティブの TRIM サポートを使っていても時間経過で落ちていきます。TRIM はファイル削除に対するセーフガードとして働くだけで、増加保存などの代わりにはなりません。

#SATA や #NVMe の場合、ソリッドステートドライブ/メモリセルの消去 に書かれている適切な手順に従うことでリセットすることができます。

ノート: リセットする目的がデータの消去ならば、SSD のコントローラに頼って安全に消去を行うことを望まない場合があるでしょう (例えば、あなたが SSD の製造業者を信頼していなかったり、潜在的なバグを不安に思っていたりする場合など)。この場合、手動消去を行う例やさらなる情報を ディスクの完全消去#フラッシュメモリ で見てください。

セキュリティ

Hdparm で "frozen" 状態と表示される

一部のマザーボードの BIOS は、初期化時に SATA デバイスに対して "security freeze" コマンドを発行します。同様に、一部の SSD (や HDD) の BIOS は、工場出荷時にすでに "security freeze" に設定されています。どちらにしても、以下の出力のように、デバイスのパスワードセキュリティ設定が frozen になります:

# hdparm -I /dev/sda

Security: 
 	Master password revision code = 65534
 		supported
 	not	enabled
 	not	locked
 		frozen
 	not	expired: security count
 		supported: enhanced erase
 	4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

デバイスのフォーマットやオペレーティングシステムのインストールといった操作は、"security freeze" の影響を受けません。

上記の出力は、デバイスが起動時に HDD パスワードによってロックされていないこと、そして frozen 状態によってデバイスを (実行時にパスワードを設定してデバイスをロックさせてしまうような) マルウェアから保護していることを示しています。

"frozen" 状態のデバイスにパスワードを設定したい場合、それに対応しているマザーボード BIOS が必要です。ハードウェア暗号化に必要なので、多くのノートパソコンでサポートされていますが、デスクトップやサーバーのボードではサポートがあるかどうかはっきりしないことがあります。

例えば、Intel DH67CL/BL マザーボードの場合、設定にアクセスするには物理的なジャンパによってマザーボードを "maintenance mode" に設定する必要があります ([10], [11] を参照)。

警告: よくわからないときは hdparm を使って上記のロックセキュリティ設定を変更しないで下さい。

SSD を消去するときは、ディスクの完全消去#hdparm や ソリッドステートドライブ/メモリセルの消去 を見て下さい。

スリープから復帰したあとに SSD 状態を "frozen" にする

スリープからの復帰時に SSD は "frozen" 状態を失っていることが多く、ソリッドステートドライブ/メモリセルの消去 で説明されているように ATA SECURE ERASE コマンドに対して脆弱になっています。

この問題を回避するために、スリープからの復帰後にスクリプトを実行することができます:

/usr/lib/systemd/system-sleep/ssd-freeze.sh

#!/bin/sh
if [ "$1" = 'post' ]; then
	sleep 1
	if hdparm --security-freeze /dev/disk/by-id/ata-name-of-disk; then
		logger "$0: SSD freeze command executed successfully"
	else
		logger "$0: SSD freeze command failed"
	fi	
fi

ハードウェア暗号化

#Hdparm で "frozen" 状態と表示される で説明されているように、BIOS でストレージデバイス (SSD/HDD) のパスワードを設定すると、それをサポートしているデバイスのハードウェア暗号化も初期化される場合があります。デバイスが OPAL 規格にも準拠している場合、パスフレーズを設定する機能が BIOS に無くとも、これを行える場合があります。自己暗号化ドライブ を見てください。

トラブルシューティング

あなたが今遭遇している問題は、Linux 固有でないファームウェアのバグである可能性があります。ゆえに、SSD に影響を与える問題のトラブルシューティングに挑戦する前に、以下のアップデートが利用可能であるかをチェックするべきです:

• SSD のファームウェア
• マザーボードの BIOS/UEFI ファームウェア

ファームウェアのバグであったとしても、解決できることがあります。ファームウェアにアップデートが存在しなかったり、ファームウェアのアップデートをしたくない場合、以下のセクションが役に立つかもしれません。

NCQ エラーを解消する

SSD や SATA チップセットによっては Linux Native Command Queueing (NCQ) が正しく動作しないことがあります。dmesg に以下のようなエラーが表示されます:

[ 9.115544] ata9: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen
[ 9.115550] ata9.00: failed command: READ FPDMA QUEUED
[ 9.115556] ata9.00: cmd 60/04:00:d4:82:85/00:00:1f:00:00/40 tag 0 ncq 2048 in
[ 9.115557] res 40/00:18:d3:82:85/00:00:1f:00:00/40 Emask 0x4 (timeout)

起動時に NCQ を無効にするには、ブートローダーの設定におけるカーネルコマンドラインに libata.force=noncq を追加してください。ポート 9 のディスク 0 の NCQ だけを無効化するには次を使用: libata.force=9.00:noncq。

また、sysfs を使うことで再起動せずに特定のドライブの NCQ を無効化することもできます:

# echo 1 > /sys/block/sdX/device/queue_depth

問題が解決しなかったり他の問題が発生する場合は、バグレポートを作成してください。

SATA の電源管理関連のエラーを解消する

SATA Active Link Power Management (ALPM) が有効になっている場合にエラーを吐く SSD も存在します (例: Transcend MTS400)。ALPM はデフォルトで無効になっており、省電力デーモンによって有効になります (例: TLP, Laptop Mode Tools)。

そのようなデーモンを使っていて SATA 関連のエラーが表示される場合、バッテリーと AC 電源のプロファイルを max_performance に設定して ALPM を無効化してみてください。

外部 SSD での TRIM サポート

いくつかの USB から SATA へのブリッジチップ (VL715、VL716 など) や USB から PCIe へのブリッジチップ (IB-1817M-C31 のような外部 NVMe エンクロージャで使用されている JMicron JMS583 など) は、USB Attached SCSI ドライバ (Linux では "uas" と呼ばれています) を通して送信できる TRIM ライクなコマンドをサポートしています。

しかし、カーネルはこの機能を自動的に検出しない場合があり、この機能を使用しないかもしれません。 問題のブロックデバイスが /dev/sdX であると仮定すると、以下のコマンドを使えばそのケースに当てはまっているかどうかを確認できます:

# sg_readcap -l /dev/sdX

このコマンドの出力に "Logical block provisioning: lbpme=0" と始まる行がある場合、(LBPME) ビットがセットされていないためカーネルはそのデバイスが "Logical Block Provisioning Management" をサポートしていないと推定していることを示しています。

この場合、デバイスの "Logical Block Provisioning" の "Vital Product Data" (VPD) ページでデータのアンマッピングのためのサポートされている機能を確認する必要があります。以下のコマンドでこれを行うことができます:

# sg_vpd -a /dev/sdX

出力から以下のような行を探してください:

Unmap command supported (LBPU): 1
Write same (16) with unmap bit supported (LBPWS): 0
Write same (10) with unmap bit supported (LBPWS10): 0

この例では、デバイスが "UNMAP" コマンドをサポートしていることを示しています。

以下のコマンドの出力を見てください:

$ cat /sys/block/sdX/device/scsi_disk/*/provisioning_mode

カーネルがデバイスのデータアンマッピング機能を検出していない場合、このコマンドはおそらく "full" を返します。 "full" の他に、カーネルの SCSI ストレージドライバは現在以下の provisioning_mode 値が登録されています:

unmap
writesame_16
writesame_10
writesame_zero
disabled

上記の例の場合、"provisioning_mode" を "unmap" に設定することで、カーネルにそれを使用するように要求することができます:

# echo "unmap" >/sys/block/sdX/device/scsi_disk/*/provisioning_mode

このコマンドを実行すると即座に、/dev/sdX 上で "blkdiscard" のようなツールを使ったり、/dev/sdX 上にマウントされているファイルシステム上で "fstrim" を実行したりできるようになるはずです。

特定のベンダ/製品の外部デバイスが接続されたときに "provisioning_mode" を自動的に有効化したいならば、"udev" の機構を使うことで可能です。まず、USB Vendor と Product ID を調べてください:

$ cat /sys/block/sdX/../../../../../../idVendor
$ cat /sys/block/sdX/../../../../../../idProduct

そして、udev ルールのファイルに以下の内容を記述してください (この例では、idVendor 152d と idProduct 0583 を使っています):

# echo 'ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0583", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' >>/etc/udev/rules.d/10-uas-discard.rules

(関連する idVendor/idProduct は lsusb を使うことでも取得できます。)

ファームウェア

デバイスのベンダーによってサポートされていれば、fwupd ユーティリティを使ってファームウェアをアップデートすることが推奨されます。

ADATA

Linux での SSD ファームウェアのアップデートは ADATA によってサポートされていません。Windows でのみ利用できるユーティリティ SSD ToolBox が ADATA によって ADATAのサポートページと ADATA XPG のサポートページで提供されています。このツールにより、監視、TRIM、ベンチマーク、ADATA SSD ファームウェアのアップデートができます。

警告: Wine を使ってファームウェアをアップデートすることは推奨されていません。Wine はハードウェアインターフェイスを扱うようには設計されておらず、不完全なファームウェアアップデートはデバイスを文鎮化させる可能性があります。

Crucial

Crucial は ISO イメージを使ってファームウェアをアップデートする方法を提供しています。SSD サポートページから製品を選んで "Manual Boot File" をダウンロードすることでイメージを入手できます。

ノート: Crucial が提供している ISO イメージはハイブリッドではないようです。dd コマンドを使って MBR が存在しないデバイスにイメージをコピーした場合、デバイスが起動できなくなります。syslinux をインストールし、isohybrid path/to/image.iso を実行してください。

M4 Crucial モデルを使っている場合、smartctl でファームウェアのアップグレードが必要かどうかチェックすることが可能です。

$ smartctl --all /dev/sdX

==> WARNING: This drive may hang after 5184 hours of power-on time:
https://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html
See the following web page for firmware updates:
https://www.crucial.com/usa/en/support-ssd

上記の警告が表示された場合は、重要なデータをバックアップしてから直ちにアップグレードを行うことが推奨されます。ISO イメージと Grub を使用して Crucial MX100 のファームウェアをアップデートする手順は こちら を参照してください。

Intel

Intel は、Windows の Intel® Memory and Storage Tool (GUI) ソフトウェアに対応していないオペレーティングシステム向けに、Linux ライブシステムをベースとする Firmware Update Tool を配布しています。

また、ファームウェアをリフラッシュできる、Intel Memory and Storage (MAS) Tool という新しい Linux コマンドラインユーティリティもあります。intel-mas-cli-tool^AUR パッケージで利用できます。PDF のユーザガイドがあります。

ファームウェアの状態をチェックすると例えば以下のように表示されます:

# intelmas show -intelssd 0

DevicePath : /dev/nvme0n1
DeviceStatus : Healthy
Firmware : 002C
FirmwareUpdateAvailable : The selected Intel SSD contains current firmware as of this tool release.

システム上に1つしか SSD が存在しない場合、-intelssd 0 は省略できます。2番目の SSD は -intelssd 1 となります。

アップデートが利用できる場合は、intelmas load -intelssd 0 を実行することでアップデートできます。上記の PDF ユーザガイドでは、この手順は Linux で2回 (間に電源の切断と再投入を挟んで) 行う必要があると書かれています。すべてのデバイス用の最新のファームウェアは、MAS Tool 自体の一部として配布されており、別途ダウンロードする必要はありません。

Kingston

Sandforce ベースのドライバ向けに KFU ツールが利用できます (kingston_fw_updater^AUR)。

Mushkin

マイナーな Mushkin ブランドのソリッドステートドライブも Sandforce コントローラーを使っており、ファームウェアをアップデートする Linux ユーティリティ (Kingston のものとほとんど同じ) が存在します。

OCZ

OCZ は Linux 用の Command Line Online Update Tool (CLOUT) を用意しています。ocz-ssd-utility^AUR, ocztoolbox^AUR, oczclout^AUR パッケージでインストールすることができます。

Samsung

Samsung は Magician ソフトウェア以外の方法によるアップデートを"サポートしない"としていますが、不可能ではありません。Magician ソフトウェアは、ファームウェアのアップデートを含むブータブルな USB ドライブを作成することはできますが、Samsung はもはやコンシューマ SSD 向けのソフトウェアを提供していません。また、Samsung は 、ファームウェアをアップデートできる作成済みのブータブルな ISO イメージも提供しています。他のオプションは、samsung_magician-consumer-ssd^AUR によって提供されている、Samsung の magician ユーティリティを使うことです。Magician は Samsung ブランドの SSD のみをサポートしています。OEM (Lenovo など) 向けに Samsung によって製造された SSD はサポートされていません。

ノート: Samsung はファームウェアアップデートをわかりやすく提供していません。ファームウェアアップデートに関連するページが4つあり、それぞれで別々の方法が示されています。

(Microsoft Windows で Samsung の "Magician" ソフトウェアを使わずに) Linux で作成したライブ USB スティックからファームウェアアップデートを実行したい場合は、[12] を参照してください。

Linux でのアップデート

SSD のファームウェアは以下に示すように (ブータブルな USB スティックを作らなくても) ネイティブにアップデートできます。まず、Samsung downloads ページを開き、"Samsung SSD Firmware" セクションへ行き、あなたの SSD 用の最新のファームウェア (ISO イメージであるはずです) をダウンロードしてください。

ノート: 一部の ISO イメージには、以下で言及されている initrd Linux イメージが欠落しています。その場合、代わりに #古い SSD を見てください。

ISO イメージから initrd Linux イメージを抽出してください:

$ bsdtar xf samsung_ssd_firmware.iso initrd

root/fumagician/ を抽出してください。このディレクトリには、ファームウェアのアップデートファイルが含まれています:

$ bsdtar xf initrd root/fumagician

最後に、root/fumagician/fumagician を root 権限で実行し、(ファームウェアが正常にアップデートされたのであれば) システムを再起動してください。

古い SSD

SSD ファームウェアの ISO イメージのいくつかには、initrd Linux イメージではなく FreeDOS イメージが含まれています。ゆえに、SSD ファームウェアのアップデートに必要なステップは上記とは異なります。以下の表は、そのような SSD (とそれに関連するパス) のリストです:

SSD モデル	FreeDOS イメージパス	ファームウェアパッケージパス
470, 830	BTDSK.IMG	SSR/
840	isolinux/btdsk.img	samsung/DSRD/
840 EVO (mSATA), Pro	ISOLINUX/BTDSK.IMG

まず、ISO イメージから FreeDOS イメージを抽出してください:

$ bsdtar xf samsung_ssd_firmware.iso freedos_image_path

FreeDOS イメージを /mnt/ にマウントしてください:

# mount freedos_image_path /mnt

Magician SSD 管理ユーティリティから Disk Number にある SSD のディスク番号を入手してください:

# magician --list

ファームウェアパッケージのパスを指定し、指定したディスクに対して SSD ファームウェアをアップデートしてください:

# magician --disk disk_num --firmware-update --fwpackage-path /mnt/firmware_package_path

最後に、(root 権限で実行した) magician --list の出力から Firmware にあるバージョンを確認し、ファームウェアが正常にアップデートできたか検証してください。ファームウェアが正常にアップデートされたのであれば、システムを再起動してください。

SanDisk

SanDisk は、SanDisk SSD Toolkit でサポートされていないオペレーティングシステムにおいて SSD のファームウェアアップデートをするための ISO ファームウェアイメージを作成しています。

適切な SSD モデル だけでなく、適切な SSD 容量 (例: 60 GB または 256GB) も合わせて、ファームウェアを選択しなければなりません。ISO ファームウェアイメージを焼いたあと、PC を再起動し、新しく作成した CD/DVD ブートディスクを起動してください (USB スティックでも動作するかもしれません)。

ISO イメージには、Linux カーネルと initrd が含まれています。それらを /boot パーティションに抽出し、GRUB や Syslinux でそれらを起動して、ファームウェアをアップデートしてください。

参照:

• SanDisk Extreme SSD ファームウェアのリリースノート と 手動ファームウェアアップデートのバージョン R211
• SanDisk Ultra SSD ファームウェアのリリースノート and 手動ファームウェアアップデートのバージョン 365A13F0
• SanDisk Ultra+ SSD ファームウェアのリリースノート and 手動ファームウェアアップデートのバージョン X2316RL - "H2" か "HP" のどちらが使用されているかを確認するには、smartctl -a /dev/sdX を使ってください。

参照

• SSD に Arch をインストールすることについての Reddit における討論
• Re: Varying Leafsize and Nodesize in Btrfs
• Re: SSD alignment and Btrfs sector size
• Erase Block (Alignment) Misinformation?
• Is alignment to erase block size needed for modern SSD's?
• Btrfs support for efficient SSD operation (data blocks alignment)
• SSD, Erase Block Size & LVM: PV on raw device, Alignment

翻訳ステータス: このページは en:Solid state drive の翻訳バージョンです。最後の翻訳日は 2023-03-19 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。