ストレージとは、データを表すビット列を、電源がなくても区別できる物理状態に対応付け、あとで同じビット列として返す装置・仕組みです。SSDではNANDフラッシュのセルが持つしきい値電圧の範囲、HDDではプラッタ上の磁化パターンを利用します。ただし、OSが媒体へ「0」「1」を直接書くのではありません。OSは番号付きの論理ブロックへI/Oを要求し、ストレージコントローラが媒体上の配置、符号化、誤り訂正などを引き受けます。
この記事では、テキストエディタでmemo.txtに「A」を追記して保存する1回の操作を追います。「A」はどのように番号付きブロックへ変わり、SSDやHDDの物理状態として残り、再び「A」として読めるのでしょうか。
「データが残る」とは、同じビット列を再構成できること
NISTの用語集はstorageを、データを後から取り出せるよう保持すること、またはデータを入れて取り出せる要素と定義しています。ここで大切なのは、単に物理状態が残るだけでなく、後から同じデータとして取得できることです。
ビットは「0か1のどちらかを区別する情報の単位」であり、それ自体が小さな物体ではありません。記憶装置は、ビット列を区別可能な物理状態へ対応付けます。読み出すときは、その状態を電気信号として測り、符号化規則と誤り訂正を使って論理上のビット列へ戻します。ビットと物理状態の関係は、ビットとバイトの解説を前提にすると整理しやすくなります。
| 見ている層 | 「A」は何として見えるか | 次の層へ渡すもの |
|---|---|---|
| テキストエディタ | memo.txtの末尾に追加した文字 |
文字コードで表したバイト列 |
| ファイルシステム | ファイル内の位置と内容 | 更新対象の論理ブロックとメタデータ |
| OSのブロックI/O層 | 番号付き領域への読み書き | LBA、長さ、read／write、データ |
| ストレージコントローラ | 処理すべきコマンド | 媒体上の配置、符号化したデータ、ECC・管理情報 |
| SSD／HDDの媒体 | 電気的または磁気的な状態 | 読み出し時に検出できる物理信号 |
memo.txtの保存を、論理から物理まで一気に追う
ここからは、memo.txtへ「A」を追記し、保存ボタンを押した後を追います。実際のエディタには、同じファイルへ上書きするもの、一時ファイルへ書いてから名前を置き換えるもの、自動保存を併用するものがあります。以下は、それらに共通する「最終的にストレージへブロックI/Oが届く部分」のモデルです。
1. ファイルシステムが、ファイル内の位置を論理ブロックへ対応付ける
保存要求を受けたOSは、memo.txtという名前、ファイル内の書き込み位置、追加するバイト列を扱います。ファイルシステムは、ディレクトリエントリやファイルのメタデータをたどり、どのファイルシステム上の論理ブロックを更新するかを決めます。一般的なバッファ付きI/Oでは、変更はまずRAM上のページキャッシュへ反映され、後で書き戻されることもあります。
ここでいうファイルシステムの論理ブロックと、ストレージ装置が公開する論理セクタ／論理ブロックは同じ言葉でも層が違います。たとえば、ファイルシステムが4KiB単位で管理し、装置が512Bまたは4KiBの論理ブロックを公開する構成があります。暗号化、RAID、LVMなど別の変換層を挟む場合もあり、1つのファイルが物理媒体上で連続しているとは限りません。名前・パス・メタデータとデータブロックの対応は、ファイルシステムの解説で詳しく扱っています。
2. OSが、LBA・長さ・データを含むI/O要求にする
書き戻す段階になると、OSのブロックI/O層は「この論理ブロック番号から、この長さのデータを書いてほしい」という要求を組み立てます。LBA（Logical Block Address）は、装置が外部へ見せる番号付きの保存領域です。Linuxカーネルの資料では、logical_block_sizeは装置がアドレス指定できる最小単位と説明されています。
ストレージ装置が受け取る中心情報は、memo.txtというファイル名ではなく、LBA、ブロック数、read／writeの種類、転送するデータです。OSは隣接する要求をまとめたり、キューで順序や公平性を調整したりすることがあります。要求キュー、DMA、割り込みなどI/O全体の動きはI/O（入出力）の解説へ、共通要求を装置のコマンドへ変える境界はデバイスドライバの解説へつながります。
3. NVMeやSATAのコマンドが、ストレージコントローラへ届く
ドライバはI/O要求を、NVMe、SATA、SAS、USBなど接続方式・プロトコルに応じたコマンドとしてコントローラへ渡します。NVMeのWriteコマンドを例にすると、ホストは開始LBAと書き込む論理ブロック数を指定します。ホストが指定するのは論理上の住所であり、NANDセルやHDDヘッドの座標ではありません。
NVMeは、PCIe上などで不揮発性ストレージへコマンドを渡すための仕様です。多数のキューと並列要求を扱いやすくし、ホストからコントローラまでのボトルネックを減らせます。しかし、NVMeという名称自体が記録媒体を表すわけではなく、NANDの消去単位や寿命を消してくれるわけでもありません。NVMe SSDでも、コントローラの内側では論理→物理変換、ECC、garbage collectionなどが必要です。
4. コントローラが、論理ブロックを媒体上の状態へ変換する
コントローラは装置の「受付窓口」だけではありません。論理アドレスを内部の保存位置へ対応付け、媒体に合う形へデータを符号化し、ECC（Error Correcting Code）などの管理情報を追加し、読み出し時には誤りを検出・訂正して論理ブロックを返します。
SSDではFTL（Flash Translation Layer）がLBAをNAND上の物理位置（ページなど）へ対応付けます。HDDでも、ホストから見えるLBAと内部の物理位置の間をコントローラが管理し、不良セクタを予備領域へ置き換える場合があります。そのため、同じLBAが常に同じ物理場所を指すとは限らず、ファイルの並びを媒体表面へそのまま描けるわけでもありません。
5. 完了通知が戻る。ただし「どこまで届いたか」を分ける
装置が処理完了を返すと、ドライバ、OS、待っていたアプリへ結果が戻ります。しかし、完了の意味は一段ではありません。OSのページキャッシュへ受け付けた時点、装置内の揮発性write cacheへ入った時点、不揮発媒体へ到達した時点は区別が必要です。
| 完了と見える地点 | 「A」がある主な場所 | 突然の電源断に対して言えること |
|---|---|---|
| アプリの通常writeが成功 | OSのページキャッシュなど | 媒体へのI/Oが未発行の場合がある |
| 装置が通常writeを完了 | 装置内write cache、または媒体 | 揮発性cacheを持つ装置では、まだ媒体へ未到達の場合がある |
| 同期処理とflush／FUAが完了 | 装置が保証する不揮発性の範囲 | その保証範囲では、電源断後も取得できることを意図した段階 |
Linuxカーネルのwrite-back cache資料は、揮発性cacheを持つ装置が不揮発媒体への到達前にI/O完了を返し得ること、そのためデータ整合性が必要な処理でflushやFUA（Force Unit Access）を使うことを説明しています。NVMe NVM Command Set仕様も、揮発性write cacheが有効でFUAや完了済みflushがないまま電源を失う条件では、後のreadが古いデータを返し得ると定めています。
OSや装置が一時領域を挟む理由と、flushという言葉の層ごとの違いはバッファの解説で掘り下げています。
SSDは、NANDセルの電荷状態をどう使うのか
NISTはSSDを、solid-state memoryを使って永続データを保持するストレージ装置と定義しています。現在の一般的なSSDではNANDフラッシュが使われ、機械的なヘッド移動やプラッタ回転はありません。
NANDセルでは、蓄えた電荷によってトランジスタのしきい値電圧が変わります。コントローラは電圧の範囲を読み分け、ビットパターンへ復号します。SLCは1セルで1ビットを表しますが、TLCやQLCなどは複数の電圧範囲を区別して1セルに複数ビットを対応付けます。したがって、「電荷がある＝1、ない＝0」と二択で説明するのは、現在のSSD全般には粗すぎます。
read／programはページ、eraseはより大きなブロック
NANDでは、読み出しとprogram（書き込み）はページ単位、消去は多数のページをまとめたブロック単位で行うのが基本です。既存データのあるページを、RAMのようにその場で自由に上書きできません。書き換えるときは、消去済みの空きページへ新しいデータをprogramし、FTLの対応表を新しい物理位置へ切り替え、古いページを無効として扱う方式が使われます。
この非対称性から、SSDの内部処理が必要になります。
| 仕組み | 何を解決するか | memo.txtの更新との関係 |
|---|---|---|
| FTL | LBAとNAND上の物理位置を対応付ける | 同じ論理ブロックの更新でも、別の空きページへ書ける |
| wear leveling | program／eraseを特定ブロックへ偏らせない | 同じファイルを繰り返し保存しても、同じセルだけを酷使しない |
| garbage collection | 有効ページを移し、無効ページを含むブロックをまとめて消去する | 古い版が無効になった後、再利用できる空きブロックを作る |
| over-provisioning | ホストから見えない予備領域を作業空間として確保する | GC、wear leveling、不良ブロック置換を進めやすくする |
| ECC・bad block管理 | 読み出し誤りを訂正し、信頼できない領域を避ける | 物理状態の揺らぎがあっても、元の論理データを返せる範囲を広げる |
KIOXIAの技術資料はLBAをソフトウェア向けの抽象化、PBAを実際のハードウェア位置として整理しています。また、同社のgarbage collection資料では、有効データを新しい場所へ移し、元のブロック全体を消去して空き領域へ戻す流れが説明されています。
つまりSSDへの1回のwriteは、「指定されたセルへ同じ量だけ書く」単純な1対1処理ではありません。空きページへのprogram、対応表の更新、後のGCによるデータ移動があるため、ホストが書いた量よりNAND内部の書き込み量が増えることもあります。
空き領域が少ない状態や継続的なrandom writeでは、GCがホストのwriteと重なり、レイテンシやスループットが変動する場合があります。だからSSDの速度は「NANDだから一定」ではなく、コントローラ、ファームウェア、空き領域、read／write比、アクセスパターン、温度などの条件で変わります。
HDDは、回転するプラッタの磁化をどう使うのか
HDDは、磁性材料で覆われたプラッタを回転させ、read／write headで磁化パターンを書き込み、読み取ります。Seagateが公開するHDD製品マニュアルでは、プラッタが磁極性の遷移としてデータを保持し、headが磁気パターンを生成・読み戻すと説明されています。
プラッタ表面は同心円状のtrackに整理され、trackはsectorに区切られます。ただし、OSが「何枚目のプラッタの何番track」と指定するわけではありません。OSはLBAを指定し、HDDのコントローラが内部位置への対応、不良sectorの再配置、信号の符号化・復号、ECCを管理します。
HDDのrandom accessで時間がかかりやすい理由は、媒体が磁気だからというより、目的の位置へ機械的に移動して待つからです。
- seek：actuatorがheadを目的のtrackへ移動する。
- rotational latency：目的のsectorがheadの下へ回ってくるまで待つ。
- transfer：headの下を通る磁化パターンを読み書きする。
連続したLBAを大きく読み書きすると、head移動と回転待ちを何度も繰り返さずに転送しやすいため、sequential throughputを出しやすくなります。離れた小さな領域を次々に読むrandom I/Oではseekと回転待ちが増え、1回ごとのレイテンシが支配的になります。SSDにはこの機械的なseekと回転待ちはありませんが、SSDでも要求サイズ、並列性、FTL、GCによりrandomとsequentialの性能差は残ります。
RAMとストレージは、役割だけでなくアクセスの仕方が違う
「RAMは作業机、ストレージは本棚」というたとえは入口として便利ですが、本質的な違いは、保持性だけでなくCPUから見えるアクセス経路にもあります。
| 観点 | RAM（主記憶） | ブロックストレージ |
|---|---|---|
| 主な役割 | 実行中の命令・データをCPUが扱う作業領域 | ファイル、アプリ、OS、DBなどを後から取得できる形で保持 |
| 電源断 | 一般的なDRAMは揮発性で内容を失う | SSD・HDDは不揮発性で内容を保持する |
| ソフトウェアから見える単位 | CPUのload／storeでバイト単位のアドレスを扱える。実際の転送にはcache lineやDRAM burstも関わる | LBAで論理ブロックを指定する。装置の論理ブロックは512Bや4KiBなど |
| 経路 | CPU、cache、memory controllerを通る | システムコール、ファイルシステム、block layer、driver、device controllerを通る |
| レイテンシの桁 | 一般にnanosecondの桁 | SSDは一般にmicrosecond以上、HDDのrandom accessはmillisecondの桁。製品・負荷で大きく変動 |
| 容量と単価 | 相対的に小容量・高単価 | 相対的に大容量・低単価 |
アプリを起動すると、ストレージ上の実行ファイルやデータの必要部分がRAMへ読み込まれ、CPUが処理します。memo.txtを編集している間は主にRAM上の状態が変わり、保存によってストレージの論理ブロックへ反映されます。両者は代用品ではなく、速度、容量、保持性、アクセス方式を分担しています。RAM側の詳細はメモリとはで確認できます。
性能値は「どんなI/Oを何個同時に出したか」とセットで読む
ストレージ性能の数値は、単独では比較できません。最低でも、request size、random／sequential、read／write比、queue depthをそろえます。SNIAのSSD解説でも、workloadをblock size、IOPS、throughput、latency、queue depthなどで表すと整理されています。
| 指標 | 何を数えるか | 値と一緒に必要な条件 |
|---|---|---|
| 容量 | 保持できるユーザー可視のデータ量 | GB／TBの10進表記か、GiB／TiBか。format後の容量、予備領域、冗長化も区別 |
| latency | 1つのI/Oを出してから完了するまでの時間 | read／write、要求サイズ、QD、平均かpercentileか、flushを含むか |
| IOPS | 1秒に完了したI/O操作数 | 4KiBなどの要求サイズ、random／sequential、read／write比、QD |
| throughput | 1秒に転送したバイト数 | 要求サイズ、アクセスパターン、read／write、持続時間。MB/sとMiB/sも区別 |
| queue depth（QD） | 未完了のまま同時に存在するI/O要求数 | 1 queue当たりか全体か、thread／job数、deviceが処理できる並列度 |
IOPSとthroughputは、1回の大きさでつながる
すべての要求が同じ大きさで、同じ測定境界を使うなら、次の関係でおおよそ結び付けられます。
throughput ≈ IOPS × 1回のI/Oサイズ
例：25,000 IOPS × 4 KiB
= 102,400,000 byte/s
≈ 97.7 MiB/s1GiBを読む場合でも、4KiBずつなら262,144回、1MiBずつなら1,024回のI/Oです。前者は多くの操作をさばくIOPSが、後者は大きな連続転送を運ぶthroughputが効きやすくなります。OSが要求をmergeしたりcacheで応答したりすると、アプリ側とdevice側で数えるI/O回数が違うことにも注意が必要です。
queue depthは並列性を増やすが、待ち時間も作る
QD 1は、1つのI/Oが終わってから次を出す状態です。QDを増やすと、SSDの複数channelやNVMeのqueueなど内部並列性を使いやすくなり、一定範囲ではIOPSやthroughputが上がります。しかし処理能力を超えて要求を積めば、queue内の待ち時間が増え、latencyは悪化します。
何を知りたいかで、見る条件を変える
| 知りたいこと | 見るI/Oの例 | 中心指標 |
|---|---|---|
| OSやアプリの体感応答 | 4KiB random read、低QD | 平均latencyと高percentile latency |
| DBの小さな多数アクセス | 4KiB〜16KiB random、実際のread／write mix | IOPS、latency、QD |
| 大きなファイルのコピー | 大きなsequential read／write | 持続throughput |
| 電源断耐久を求める小さな更新 | 同期writeとflushを含む | durable write latency、IOPS |
| 混雑の有無 | 実運用の要求サイズとmix | QD、latency、throughputの同時変化 |
5つの誤解を、正しい境界へ置き換える
| ありがちな理解 | 正確な理解 |
|---|---|
| SSDへ0と1を直接書く | ホストはLBAへのwriteを要求し、controllerが符号化・FTL・ECCを通してNANDの電圧状態へ対応付ける |
| 1つのファイルは媒体上で連続している | file system、変換層、device controllerが論理→物理対応を管理し、断片化や再配置があり得る |
| write成功なら電源断にも耐える | page cache、device write cache、不揮発媒体への到達を分け、必要なら同期・flush／FUAを確認する |
| NVMeならNANDの制約がなくなる | NVMeはhostとcontroller間のcommand・queueを効率化する仕様で、NAND内部管理は残る |
| 最大MB/sだけで速さが分かる | request size、random／sequential、read／write、QD、latency、測定持続時間をそろえて初めて比較できる |
ローカル、NAS、クラウドでも芯は同じ
内蔵SSDや外付けHDDでは、コンピュータからdevice controllerまでが比較的近くにあります。NASやSANでは、その手前にnetwork、remote protocol、server cache、RAIDなどが加わります。cloud storageも物理媒体が消えるわけではなく、API、冗長化、分散配置、運用管理をサービスとして重ねています。
したがって遠隔storageのlatencyを考えるときは、「媒体のread／write時間」だけでなく、network往復、server処理、cache hit、冗長書き込み、混雑も分離します。DAS・NAS・SANの接続形態はネットワークストレージの解説へつながります。
まとめ：ストレージは「物理状態を論理データとして守る層」
memo.txtへ「A」を保存すると、文字を表すバイト列はファイルシステムの論理ブロックへ反映され、OSのブロックI/OとしてLBAとともにコントローラへ届きます。コントローラはSSDならNANDの物理ページ、HDDなら磁気媒体上の位置へ対応付け、ECCや管理情報とともに記録します。読み出し時は逆に物理状態を検出・訂正・復号し、同じ論理ブロックを返す――この往復が、ストレージの本質です。