# Solid State Drives (日本語)

関連記事

- SSD ベンチマーク
- SSD Memory Cell Clearing
- profile-sync-daemon

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

## 概要

### イントロダクション

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

Note: この記事は 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] では 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

Note: ext3 の root パーティションで `discard` フラグを使用すると読み取り専用でマウントされます。
Warning: `discard` フラグを使ってパーティションをマウントする前に SSD が TRIM をサポートしていることを確認してください。そうしないとデータが喪失する可能性があります。

#### cron で TRIM を適用する

Note: この方法は 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` オプションは削除してください。

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

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

このブログ記事 を参照してください。

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

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

    # tune2fs -o discard /dev/sdXY

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

#### LVM で TRIM を有効にする

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

#### dm-crypt で TRIM を有効にする

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

### I/O スケジューラー

Consider switching from the default CFQ scheduler (Completely Fair Queuing) to NOOP or Deadline. The latter two offer performance boosts for SSDs. The NOOP scheduler, for example, implements a simple queue for all incoming I/O requests, without re-ordering and grouping the ones that are physically closer on the disk. On SSDs seek times are identical for all sectors, thus invalidating the need to re-order I/O queues based on them.

The CFQ scheduler is enabled by default on Arch. Verify this by viewing the contents `/sys/block/sdX/queue/scheduler`:

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

    noop deadline [cfq]

The scheduler currently in use is denoted from the available schedulers by the brackets.

Users can change this on the fly without the need to reboot with:

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

or:

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

This method is non-persistent (eg. change will be lost upon rebooting). Confirm the change was made by viewing the contents of the file again and ensuring "noop" is between brackets.

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

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

#### sys 仮想ファイルシステムを使う (マルチデバイス)

This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).

Create the following tmpfile where X is the letter for the SSD device.

    /etc/tmpfiles.d/set_IO_scheduler.conf

    w /sys/block/sdX/queue/scheduler - - - - noop

Because of the potential for udev to assign different `/dev/` nodes to drives before and after a kernel update, users must take care that the NOOP scheduler is applied to the correct device upon boot. One way to do this is by using the SSD's device ID to determine its `/dev/` node. To do this automatically, use the following snippet instead of the line above and add it to `/etc/rc.local`:

    declare -ar SSDS=(
      'scsi-SATA_SAMSUNG_SSD_PM8_S0NUNEAB861972'
      'ata-SAMSUNG_SSD_PM810_2.5__7mm_256GB_S0NUNEAB861972'
    )

    for SSD in "${SSDS[@]}" ; do
      BY_ID=/dev/disk/by-id/$SSD

      if [[ -e $BY_ID ]] ; then
        DEV_NAME=`ls -l $BY_ID | awk '{ print $NF }' | sed -e 's/[/\.]//g'`
        SCHED=/sys/block/$DEV_NAME/queue/scheduler

        if [[ -w $SCHED ]] ; then
          echo noop > $SCHED
        fi
      fi
    done

where `SSDS` is a Bash array containing the device IDs of all SSD devices. Device IDs are listed in `/dev/disk/by-id/` as symbolic links pointing to their corresponding `/dev/` nodes. To view the links listed with their targets, issue the following command:

    $ ls -l /dev/disk/by-id/

#### 1つのデバイスまたは HDD/SSD 混合環境で udev を使う

Though the above will undoubtedly work, it is probably considered a reliable workaround. Ergo, it would be preferred to use the system that is responsible for the devices in the first place to implement the scheduler. In this case it is udev, and to do this, all one needs is a simple udev rule.

To do this, create the following:

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

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

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

Of course, set Deadline/CFQ to the desired schedulers. Changes should occur upon next boot. To check success of the new rule:

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

Note: Keep in mind CFQ is the default scheduler, so the second rule with the standard kernel is not actually necessary. Also, 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

### 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)

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

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

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

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

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

Note: A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and 10GB of data written per day, would get an 8 years life expectancy. It gets better with bigger SSDs and modern controllers with less write amplification. Also compare [2] when considering whether any particular strategy to limit disk writes is actually needed.

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

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

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

### noatime マウントフラグ

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

Note: The write time information to a file will continue to be updated anytime the file is written to with this option enabled.

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

Note: This setting will cause issues with some programs such as Mutt, as the access time of the file will eventually be previous than the modification time, which would make no sense. Using the `relatime` option instead of `noatime` will ensure that the atime field will never be prior to the last modification time of a file. Alternatively, using the maildir storage format also solves this mutt issue.

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

#### ブラウザのプロファイル

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

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

#### その他

ブラウザプロファイルを RAM に移動するのと同じ理由で、(ウェブサーバーを動かしている場合) `/srv/http` などの頻繁に利用するディレクトリを移動することもできます。profile-sync-daemon の姉妹プロジェクトとして anything-sync-daemon があり、同じ方法・セーフガードを使ってあらゆるディレクトリを 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倍になることを示しています。これは当然の結果です。なぜならメタデータが最終的にディスクに書き込まれる前に、メタデータブロックへの変更はまず全てジャーナルに書き込まれ、それからジャーナルのトランザクションが行われるからです。しかしながら、ファイルシステムのメタデータブロックを変更するだけでなくデータの書き込みも行うような一般的な操作では、違いはかなり少なくなります。"

Note: 表にある 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 ユーティリティを用意しています。彼らのサポートページ で見つけることができます。

### Mushkin

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

### OCZ

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

### Samsung

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

Note: 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
- See the Flashcache article for advanced information on using solid-state with rotational drives for top performance.
- 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

Category:

- Storage (日本語)