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

この記事では SSD (solid state drive) について Linux と関係する様々なことを記述していますが、一般的な根本原則やキーポイントは Windows ファミリーや Mac OS X など他のオペレーティングシステムで SSD を使っているユーザーも応用することができます。さらにそのような情報に加えて、Linux ユーザーはここに書かれた方法で SSD を最適化・調整することが可能です。

概要

イントロダクション

Solid State Drive (SSD) は PnP デバイスではありません。パーティションアライメント、ファイルシステムの選択、TRIM サポートなどの特別事項は SSD の性能を最適化するために必要になります。この記事には Linux で SSD から最高の性能を引き出すための情報を集めています。コンテンツはトピックでまとめられており、必ずしも系統的または時系列順に並べられているわけではないので、実際に推奨事項をやろうとする前に記事全体を読むと良いでしょう。

ノート: この記事は Linux を動作させているユーザーを対象にしていますが BSD, Mac OS X, Windows など他のオペレーティングシステムを使っているユーザーにも中身がほぼ全て当てはまります。

HDD に対する利点

高速な読み込み速度 - 最新のデスクトップ HDD のおよそ2-3倍高速 (7,200 RPM で SATA2 インタフェースを使用した場合に比べて)。
一定の読み込み速度 - デバイス全体で読み込み速度の低下がありません。HDD はドライブのヘッドが外縁から HDD プラッタの中心に移動するにつれパフォーマンスがだんだん低下します。
極小のアクセス時間 - HDD よりおおよそ100倍高速。例えば、デスクトップ HDD の 12-20 ms (12,000-20,000 us) に対して 0.1 ms (100 us)。
高度な信頼性。
可動部が存在しない。
熱の発生が少ない。
消費電力が少ない - 回転速度によって HDD が10-30ワット消費するのに対してアイドル状態で1ワット、読み書き中は1-2ワット。
軽量 - ノートパソコンに最適。

欠点

容量単位のコスト (1GBあたり1ドル近く、それに対して回転メディアでは1GBあたり10または20セント)。
市販されているモデルの容量が HDD よりも少ない。
セルの大きさによって回転メディアと異なるファイルシステムの最適化が必要。現代の OS はアクセスを最適化するためにフラッシュ変換レイヤを使用しており生のフラッシュアクセスは遮蔽されている。
パーティションとファイルシステムを SSD の特性にあわせて調整する必要がある。ページサイズや消去ページサイズは自動検出されません。
セルは劣化します。一般的に、50nm プロセスによる民生の MLC セルは10000回の書き込み、35nm では5000回の書き込み、25nm では3000回の書き込みが出来ます（小さくなればなるほど高密度で値段が安くなります）。書き込みが適当に散らばっていて、小さすぎず、セルにピッタリはまるようになったときに、容量の倍数である最終的な SSD の書き込みボリュームに移されます。日々の書き込みボリュームは耐用年数から差引かなければなりません。ただし、最新のハードウェアで行われた試験 [1][2][3] では SSD の劣化は無視できるほどで、人為的に書き込みボリュームを多くしても SSD の耐用年数は HDD と並ぶとされています。
ファームウェアやコントローラーが複雑。たまにバグが存在することもあります。最新のコントローラーは HDD と匹敵するほどの電力を消費します。コントローラーにはガベージコレクションの付いたログ構造化ファイルシステムに相当するものが実装されています。回転メディアにあわせて作られた SATA コマンドは変換されます。ファームウェアによってはオンザフライで圧縮を行います。反復書き込みをフラッシュ領域全体に散らばらせて、特定のセルがすぐに劣化するのをふせぎます。また、書き込みをまとめることで小さな書き込みがそれと同じ回数大きなセルを消去することにならないようにしています。最後にデータを含むセルを移動するので時間の経過によってセルが中身を失うことはありません。
ディスクが満杯になるにつれてパフォーマンスが低下します。一般にガベージコレクションはあまり上手く実装されておらず、空き領域が完全に空のセルに集められているとは限りません。

購入前に考慮すべき事項

最新の SSD を買う前に見ておくべきポイントがいくつか存在します。

TRIM のネイティブサポートは不可欠です。SSD の寿命を伸ばして、少しずつおこる書き込み操作のパフォーマンスの減少を少なくします。
適切な容量の SSD を買うことが重要です。カーネルが SSD パーティションを効率的に利用するために占有率は75%以下が望まれます。

SSD のパフォーマンスを最大化させるヒント

パーティションアライメント

消去ブロックサイズに揃えたパーティションを使用することを強く推奨します。昔は、パーティション分けをするときに手動で計算して設定する必要がありました。現在では一般的なパーティションツールのほとんどが（最新バージョンを使っていれば）パーティションアライメントを自動的に行います:

fdisk
gdisk
gparted
parted

パーティションが調整されているか確認するには、以下のように /usr/bin/blockdev を使って問い合わせて下さい。'0' が返ってくれば、パーティションは揃えられています:

# blockdev --getalignoff /dev/<partition>
0

TRIM

ほとんどの SSD は長期間パフォーマンスを維持するために ATA_TRIM コマンドをサポートしています。ベンチマーク前後などの詳細は、このチュートリアルを見て下さい。

Linux カーネルバージョン 3.7 現在、次のファイルシステムが TRIM をサポートしています: Ext4, Btrfs, JFS, VFAT, XFS。

VFAT はマウントフラグ 'discard' によって TRIM をサポートしています、fstrim はサポートしていません。

この記事のファイルシステムの選択のセクションにさらに詳しく書かれています。

TRIM のサポートを確認する

# hdparm -I /dev/sda |grep TRIM
        *    Data Set Management TRIM supported (limit 1 block)
        *    Deterministic read data after TRIM

"limit 1 block" や "limit 8 block" の意味は、wikipedia:TRIM#ATA を見て下さい。

マウントフラグで TRIM を有効にする

/etc/fstab でフラグを使うことで上述の TRIM コマンドの恩恵を得ることができます。

/dev/sda1  /       ext4   defaults,noatime,discard   0  1
/dev/sda2  /home   ext4   defaults,noatime,discard   0  2

ノート: ext3 の root パーティションで discard フラグを使用すると読み取り専用でマウントされます。

警告: discard フラグを使ってパーティションをマウントする前に SSD が TRIM をサポートしていることを確認してください。そうしないとデータが喪失する可能性があります。

cron で TRIM を適用する

ノート: この方法は VFAT ファイルシステムでは使えません。

サポートされている SSD では TRIM を有効にすることが基本的に推奨されますが、場合によってはファイルの削除中に SSD の動作が遅くなる問題が発生します。このような場合、代わりに fstrim を使うことを選択できます。

# fstrim -v /

fstrim を適用するパーティションはマウントされている必要があり、さらにマウントポイントで示さなければなりません。

この方法の方が上手くいくようでしたら、cron を使って定期的にこれを実行するようにすると良いでしょう。デフォルトの cron パッケージ (cronie) には、デフォルトで、毎時・毎日・毎週・毎月のジョブを設定するための anacron 実装が含まれています。Arch の新規インストールでは cronie の systemd サービスはデフォルトで有効になっていないので注意してください。毎日の cron のタスクのリストに追加するには、希望の動作をするスクリプトを作成して /etc/cron.daily や /etc/cron.weekly に置くだけです。この方法を使用する場合は適当な nice や ionice の値を使うことを推奨します。上手くできたら、/etc/fstab から discard オプションは削除してください。

ノート: まず最初は discard マウントオプションを使うべきです。TRIM の通常実装で上手く行かない時にこの方法を使って下さい。

systemd サービスで TRIM を適用する

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

tune2fs で TRIM を有効にする (非推奨)

tune2fs を使って静的に trim フラグを設定することができます:

# tune2fs -o discard /dev/sdXY

警告: この方法を使うと mount で discard オプションが現れなくなります。

LVM で TRIM を有効にする

/etc/lvm/lvm.conf で issue_discards オプションを有効にしてください。

dm-crypt で TRIM を有効にする

/etc/crypttab を設定して SSD 上の暗号化されたブロックデバイスのオプションのリストに discard を含めて下さい。この discard オプションは discard リクエストが暗号化されたブロックデバイスを通過するのを許可します。これによって SSD ストレージのパフォーマンスは向上しますが、セキュリティに影響があります。このセクションを見て下さい。

I/O スケジューラー

デフォルトの CFQ (Completely Fair Queuing) スケジューラから NOOP または Deadline に切り替えるということも考えられます。後者の2つは SSD のパフォーマンスを加速させます。例えば、NOOP スケジューラは全ての I/O リクエストに対して、ディスクに物理的に近いものを並び替えたりグループ化することなく、一つのシンプルなキューを実行します。SSD においては全てのセクタでシーク時間は同じであり、シーク時間に基づいて I/O キューを並び替える必要性には説得力がありません。

Arch ではデフォルトで CFQ スケジューラが有効にされています。/sys/block/sdX/queue/scheduler の中身を見て確認してください:

$ cat /sys/block/sdX/queue/scheduler

noop deadline [cfq]

表示されているスケジューラの中で角括弧で囲まれているのが現在使われているスケジューラです。

ユーザーは再起動することなくスケジューラを変更することができます:

# echo noop > /sys/block/sdX/queue/scheduler

または:

$ sudo tee /sys/block/sdX/queue/scheduler <<< noop

この方法は永続的ではありません (再起動で変更は失われます)。ファイルの中身をもう一度見て "noop" が使われるようになっていることを確認してください。

カーネルパラメータ (シングルデバイス)

システムの唯一のストレージデバイスが SSD である場合、elevator=noop カーネルパラメータでシステム全体の I/O スケジューラを設定できます。

1つのデバイスまたは HDD/SSD 混合環境で udev を使って設定する

上の方法は確かに動作しますが、あくまで回避策と考えられています。つまり、デバイスのスケジューラを一番最初に実行するシステムを使うのが好ましいでしょう。この場合、それは udev で、設定するのに必要なのはシンプルな udev ルールだけです。

設定するには、以下を作成してください:

/etc/udev/rules.d/60-schedulers.rules

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

Deadline/CFQ をお望みのスケジューラに設定してください。次に起動した時に変更が適用されるはずです。新しいルールが適用されているか確認するには:

$ cat /sys/block/sdX/queue/scheduler  # where X is the device in question

ノート: In the example sixty is chosen because that is the number udev uses for its own persistent naming rules. Thus, it would seem that block devices are at this point able to be modified and this is a safe position for this particular rule. But the rule can be named anything so long as it ends in .rules.)

SSD のスワップ領域

SSD 上にスワップパーティションを配置することが可能です。最新のデスクトップではメモリが2ギガ以上積まれておりスワップはほとんど使いません。ただしハイバネート機能を利用するシステムの場合は別です。以下のようにシステムの "swappiness" を減らすことで SSD にあるスワップへの書き込みを減らすことが推奨されます:

# echo 1 > /proc/sys/vm/swappiness

パフォーマンスの最大化の記事で推奨されているように行うこともできます:

/etc/sysctl.d/99-sysctl.conf

vm.swappiness=1
vm.vfs_cache_pressure=50

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

マザーボードの BIOS は初期化時に取り付けられたストレージデバイスに "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 パスワードによってロックされていないこと、そして凍結状態によってデバイスを (パスワードを設定してデバイスをロックさせてしまうような) マルウェアから保護していることがわかります。

凍結状態のデバイスにパスワードを設定したい場合、それに対応しているマザーボード BIOS が必要です。ハードウェア暗号化に必須なので、ノートパソコンでは大抵サポートされていますが、デスクトップやサーバーのボードではサポートがあるかどうかはっきりしないことがあります。例えば、Intel DH67CL/BL マザーボードの場合、設定にアクセスするには物理的なジャンパによってマザーボードを "maintenance mode" に設定する必要があります ([4], [5] を参照)。

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

SSD を消去するときは、Securely wipe disk#hdparm や下のセクションを見て下さい。

SSD Memory Cell Clearing

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

リセットは SSD Memory Cell Clearing の wiki 記事に書かれている3つのステップで簡単に行なえます。

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)

以下の方法のいずれかによって問題が解決する可能性があります:

SSD のファームウェアをアップデートする。SSD (日本語)#ファームウェアのアップデートを参照。
マザーボードの BIOS/UEFI をアップデートする。Linux で BIOS を更新を参照。
起動時に NCQ を無効にする。ブートローダーの設定におけるカーネルコマンドラインに libata.force=noncq を追加してください。

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

SSD の読み書きを最小化するヒント

SSD の使用で一番重要なテーマは読み書きが多い操作を SSD の代わりに RAM (Random Access Memory) や物理 HDD に配置するという'シンプリシティ'でしょう。そうすることで SSD をより長生きさせることができます。これは主として巨大な消去ブロックサイズのためで (場合によっては 512 KiB)、多数の小さな書き込みは大きな効果的な書き込みになります。

ノート: 書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、毎日 10GB のデータ書き込みを行うと、8年間で寿命が尽きるとされます。この数字はもっと容量が大きい SSD を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは [6] を比較してください。

プログラムがディスクにどれだけ書き込んでいるか確認するには $ iotop -oPa を使ってディスクの書き込み順にソートしてください。

賢いパーティションスキーム

SSD と HDD 両方搭載しているシステムでは、読み書きを減らすために /var パーティションは SSD ではなく磁気ディスク上に配置すると良いでしょう。

noatime マウントフラグ

このフラグを /etc/fstab で使うと、ファイルに関連付けられた atime 情報の更新によるファイルシステムの読み込みアクセスの記録が止められます。noatime 設定によってファイルの読み込みだけでファイルシステムに書き込みを行うのを阻止することになります。前のセクションで説明しているように書き込みは負担が大きいため、ある程度パフォーマンスが向上する可能性があります。

ノート: このオプションを有効にしても、ファイルが変更されたときのファイルの変更日時の情報は更新されます。

/dev/sda1  /       ext4   defaults,noatime   0  1
/dev/sda2  /home   ext4   defaults,noatime   0  2

ノート: この設定を使うと Mutt などのプログラムで問題がおこります。ファイルのアクセス日時がやがて変更日時よりも前になってしまうからです。noatime の代わりに relatime オプションを使うことでファイルの最終変更日時よりも atime が前にならないようにすることができます。また、maildir ストレージフォーマットを使うことでも mutt の問題は解決します。

頻繁に使うファイルを RAM に移動する

ブラウザのプロファイル

tmpfs を使って chromium, firefox, opera などのブラウザプロファイルを RAM へ簡単にマウントすることができ、また、rsync を使うことで HDD によるバックアップと同期させることができます。これによって速度が向上するだけでなく、SSD の読み書きサイクルを節約することにもなります。

AUR には profile-sync-daemon^AUR など、この手順を自動化するパッケージが複数存在します。

その他

ブラウザプロファイルを RAM に移動するのと同じ理由で、(ウェブサーバーを動かしている場合) /srv/http などの頻繁に利用するディレクトリを移動することもできます。profile-sync-daemon^AUR の姉妹プロジェクトとして anything-sync-daemon^AUR があり、同じ方法・セーフガードを使ってあらゆるディレクトリを RAM に同期させるよう定義することが可能です。

tmpfs でコンパイルする

意図的に /tmp でコンパイルすることで問題を少なくすることができます。Arch Linux はデフォルトで /tmp を物理メモリの50%にします。メモリが 4GB 以上あるシステムならば、/scratch を作成して tmpfs にマウントすることで物理メモリの50%以上を使うように設定できます。

例えば物理メモリが 8GB あるマシンの場合:

$ mount | grep tmpfs

tmpfs     /scratch     tmpfs     nodev,nosuid,size=7G     0     0

詳細については、Makepkg (日本語)#コンパイル時間を短縮するを参照してください。

ファイルシステムのジャーナリングを無効にする

SSD で ext4 などのジャーナリングファイルシステムを使っている場合、ジャーナルを無効にすることで読み書きを減らすことができます。ただし、ジャーナリングを無効にしたファイルシステムを使用するときの明らかな欠点として、ちゃんとマウントが解除されていない (つまり、電源が落ちたり、カーネルが固まったりする) とデータが消失します。最新の SSD では、ほとんどの場合、あまり読み書きサイクルを増やさないでジャーナリングを有効にすることができると Ted Tso は主張しています:

noatime でマウントされた ext4 ファイルシステムに書き込まれるデータの量 (単位はメガバイト)。

操作	ジャーナル	ジャーナルなし	減少率
git clone	367.0	353.0	3.81 %
make	207.6	199.4	3.95 %
make clean	6.45	3.73	42.17 %

"この結果は、make clean など、メタデータの変更が多い操作はディスクに書き込むデータ量がほぼ2倍になることを示しています。これは当然の結果です。なぜならメタデータが最終的にディスクに書き込まれる前に、メタデータブロックへの変更はまず全てジャーナルに書き込まれ、それからジャーナルのトランザクションが行われるからです。しかしながら、ファイルシステムのメタデータブロックを変更するだけでなくデータの書き込みも行うような一般的な操作では、違いはかなり少なくなります。"

ノート: 表にある make clean の例は、この記事の前のセクションで説明している tmpfs でコンパイルするのが何故推奨されているのかを示す典型例でしょう。

ファイルシステムの選択

Btrfs

Btrfs のサポートは Linux カーネルのメインライン 2.6.29 リリースから含まれています。ext4 の後継として使っているアーリーアダプターもいますが、人によってはまだ日常的な利用には適さないと感じるかもしれません。詳細は Btrfs の記事を読んで下さい。

Ext4

Ext4 は SSD をサポートしているもうひとつのファイルシステムです。2.6.28 から安定していると考えられており日常的な利用ができるレベルまで成熟しています。ext4 のユーザーは fstab で discard マウントオプションを使って (もしくは tune2fs -o discard /dev/sdaX で) 明示的に TRIM コマンドのサポートを有効にする必要があります。 ext4 に関する詳細情報はカーネルツリーの公式ドキュメントを見て下さい。

XFS

ext4 や btrfs に加えて、XFS も TRIM をサポートしていることを知っているユーザーは多くないでしょう。通常の方法で有効にすることができます。つまり、上述の discard オプションを利用するか、または fstrim コマンドを使うか選択することが可能です。詳細は XFS wiki を見て下さい。

JFS

Linux カーネルバージョン 3.7 から、完全な TRIM サポートが追加されました。現在、このトピックに関する情報はあまり揃っていませんが、Linux ニュースサイトによって確かに取り上げられています。discard マウントオプションにより、または fstrim を使う方法で有効にすることが可能です。

他のファイルシステム

他にも SSD に特化して設計されたファイルシステムが存在します。F2fs などがあります。

ファームウェアのアップデート

ADATA

ADATA は Linux (i686) で利用できるユーティリティを、ここにある彼らのサポートページに用意しています。モデルを選択すれば最新のファームウェアへのリンクが表示されます。

最新の Linux アップデートユーティリティはファームウェアと一緒に入っており root で実行してください。先立ってバイナリファイルに対して適切なパーミッションを設定する必要があるかもしれません。

Crucial

Crucial は ISO イメージを使ってファームウェアをアップデートする方法を提供しています。ここから製品を選んで "Manual Boot File" をダウンロードすることでイメージを入手できます。M4 Crucial モデルを使っている場合、smartctl でファームウェアのアップグレードが必要かどうかチェックすることが可能です。

$ smartctl --all /dev/sdX

==> WARNING: This drive may hang after 5184 hours of power-on time:
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html
See the following web pages for firmware updates:
http://www.crucial.com/support/firmware.aspx
http://www.micron.com/products/solid-state-storage/client-ssd#software

このような警告が表示された場合は重要なデータをバックアップしてから直ちにアップグレードを行うことが推奨されます。

Kingston

Kingston は Sandforce ベースのドライブのファームウェアをアップデートする Linux ユーティリティを用意しています。Kingston のサポートページで見つけることができます。

Mushkin

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

OCZ

OCZ はここにある彼らのフォーラムで Linux (i686 と x86_64) 向けのコマンドラインユーティリティを提供しています。

Samsung

Samsung は Magician Software 以外の方法によるアップデートを"サポートしない"としていますが、不可能ではありません。Magician Software を使ってファームウェアのアップデートを起動する USB ドライブを作成することができるようですが、一番簡単な方法はファームウェアのアップデート用のブータブル ISO イメージを使用することです。イメージはここから入手することが可能です。

ノート: Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages each referencing different ways of doing things.

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

SanDisk

SanDisk は SanDisk SSD Toolkit でサポートされていないオペレーティングシステムにおいて SSD のファームウェアアップデートをするための ISO ファームウェアイメージを作成しています。SSD のモデルだけでなく、SSD の容量にあわせて適切なファームウェアを選択する必要があります (例: 60GB または 256GB)。適当な ISO ファームウェアイメージを焼いたら、PC を再起動して新しく作成した CD/DVD ブートディスクで起動してください (USB スティックからでも動作するかもしれません)。

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

ファームウェアのアップデートが列挙された一つのページは存在しませんが (サイトがわかりづらい)、以下が関連するリンクです:

SanDisk Extreme SSD Firmware Release notes と Manual Firmware update version R211

SanDisk Ultra SSD Firmware release notes と Manual Firmware update version 365A13F0

参照

Discussion on Reddit about installing Arch on an SSD
パフォーマンスを出すためにソリッドステートと回転デバイスを一緒に使う高度な話については Flashcache の記事を見て下さい。
Speed Up Your SSD By Correctly Aligning Your Partitions (using GParted)
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