図 3 同一トラック上のアクセス順序は不定 1 ケース 2 図 4 複数トラックにまたがるテータの I/O 順序は不定 ・ wait ケース 1 9 2 3 4 5 6 7 wait 30 14 29 ケース 2 ケース 1 13 27 28 12 26 10 32 25 9 17 1 24 8 2 3 4 20 23 7 22 6 8 4 畄致 4 : セクタのアクセス順序は不定である 30 などのシリコンディスクでも成立する。 あるが ) あてはまる。とくに、特徴 1 ~ 3 は FlashROM こまでに挙げた性質は、 HDD 以外にも ( 程度の差は 側にある場合、セクタ 1 ~ 16 がさきになる。 一方、ケース 2 のようにヘッドが目的のセクタよりも内 りもさきに書き込まれる。 ラックよりも外側にある場合、セクタ 17 ~ 32 は 1 ~ 16 よ ケース 1 のように、ヘッドが目的とするセクタを含むト おこないたいとする。 今度は、図 4 の状態で、セクタ 1 ~ 32 にすべて書込みを えるからだ。 1 または 3 、 1 、 2 の順で書き込む。そのほうが早く書き終 ったとしよう。この場合、 NVM は効率を重視して、 2 、 3 、 ら、ちょうどセクタ 1 の真ん中あたりがヘッドの直下にな 一方、ケース 2 のようにヘッドをトラック上に移動した のように 1 、 2 、 3 の川頁でセクタに書き込むことになる。 という指示が与えられたとする。多くの場合は、ケース 1 ・セクタ 1 から 3 セクタぶん書き込め たとえば、図 3 のようなセクタ配置に対し、 ック間の順序不定問題である。 ートラック上のアクセス川印不定問題、そして、複数トラ これには 2 つの理由がある。今回のモデルであれば、同 ストレーシ全体のモデル UNIX MAGAZINE 2006.3 PC からストレージにデータを書き込む場合、データの もに失われる。 ロ内されているデータは、電源断 ( リセットも含む ) とと Read/Write バッフアはたんなるメモリである。 つながっており、ストレージ外部との通信制御もおこなう。 ストレージ全体を制御している。また、接続ケープルとも (Read/Write バッファおよび NVM) とつながっており、 アがある。これは、ストレージを構成するすべての要素 ストレージ側には、 Controller 2 というハードウェ で制御することはできない。 このため、データ転送のタイミングを HDD 側の都合だけ ケープルに複数のストレージがつながっていることもある。 量は固定で通信速度は変わらない。ときには、単一の接続 送容量が大きく、遅延 (latency) も大きい。また、輔医容 プルのことである (iSCSI なども含まれる ) 。基本的に、転 接続ケープルとは、 ATA や SATA 、 SCSI などのケー スドライバもある。 データ転送を管理する。 ControIIer 1 を管理するデバイ 接続ケープルを介して HDD とメインメモリとのあいだの 際の言 t 算機では、 ATA コントローラなどである。これは、 PC には、 ControIIer 1 というハードウェアがある。実 る側カ第 t 算機本体、 HDD がストレージである。 NVM 以外の部分についてのモデルだ。 PC と書かれてい 図 2 は、計算機とストレージ、ならびにストレージの
仮想ストレージとしてのファイルシステム [ 1 ] 特集 するにはこの条件は不可欠である ) となると、残るのはス 343 , 667 個のファイルがあるらしい。 トレージだけである。 CPU から直接内容が参照できない、 ストレージ自体は、データを区別する手段をもっていな 圧倒的に遅いといった弱点はあるが、実質的にほかの選択 い。つまり、 2 つのデータを 1 台のストレージに十帑内する 肢はない。 場合、そのままでは、どこまでが 1 つ目のデータで、どこ これ以外の部品はすべて、電源を切ればそれまで憶え からが 2 つ目かの区別はつかない。したがって、生のデー ていたことをきれいに忘れてしまう。つまり、メモリでも タをそのままストレージに格納するとしたら、 1 データに っき 1 ストレージにせざるをえない。仮に 1 つ 1 円のス CPU のレジスタでも、電源断と同時にデータは失われるの トレージがあったとしても、私の W ⅲ dows マシンにある である。 ファイルを別々のストレージに保存していくと約 35 万円 一方、 PC 側では電源断を完全には防げない。永久機関 もかかる引算になる。 ではないので、外部からエネルギーを供給しなければいつ だが、現実には、これらのファイルはたった 3 万円の かは止まる。不意の停電などにより、とんでもない瞬間に HDDI のなかにすべて収まっている。ファイル単価で比較 電源断に襲われることもある。 すれば 1 / 10 以下である。このコストダウンの要となって また、プログラムにはバグがつきものだ。 Windows だ いるのが、ストレージのイ反想化技術であるファイルシステ とプルースクリーン、 Linux なら Panic 画面が出て、に ムだ。 っちもさっちもいかなくなるという現象は、停電の何万倍 ファイルシステムは、最初に 1 つのストレージ上に名前 もの確率で発生する。そうなったら PC をリセットするし かないが、、、リセット " とは、いったん電源を切り、明殳入 空間を用意する。そして、 1 つの名前ごとに 1 つのイ反想ス トレージを割り当てる仮想ストレージは、最小で 0 バイ することの別名にすぎない。 ト、最大でメディアか午す範囲のサイズをとることができ、 このように、あらゆる計算機は電源断と無縁ではいられ 大きさは可変長である。これらの仮想ストレージを、、ファ ないのである。 イル " と呼ぶ。 電源断には、もう 1 つ、重要な性質がある。発生する ファイルシステムという仮想化技術を経由することで、 タイミングを予測したり、事前に制御することができない ストレージの利用効率を向上させている。 1 つ 1 円のメデ のだ。人間カ噫図的に電源を切る場合もあるが、そうでは ィアを 35 万個用意する代わりに、 3 万円のメディアを 1 ないこともある。バグカ源因でマシンカ阯まったり、外部 っ用意すればすべてのデータがオ内できる からの電力供給が途絶えるといったケースを事前に予測し、 それを防ぐのは事実上不可能である。 UPS などの補助電 こういったことは常識に属する事柄だ力、意外にこのポ 源も、電源断の発生確率を下げるだけでゼロにするわけで イントを忘れる人が多いので、あえて説明している。もう はない。 すこし我して読んでほしい。 電源断によって、データカ趺われては困る。そこで、ス ファイルシステムに求められる要件 トレージの出番になる。失われては困るデータを作成した さて、ファイルシステムは、どのような要件を満たさな ら速やかにストレージに内し、電源断が発生したら復旧 ければならないのだろうか。ファイルシステムは、、仮想ス 後に取り出せばよい。これで、データが失われる危険性は トレージ " を提供するのだから、ストレージに対するユー 大幅に低くなる。 ザーの要望をすべて満たしてくれなくては困る。重要な要 仮想イヒストレージ 件としては下記の 2 つがある。 こで、質問をもう 1 つ。 ・電源断があってもデータをイ尉寺し続ける機構がある。 どのくらいの数のファイルがあるだ 「皆さんの PC には、 、、電源断発生の予測は不可能 " が大前提。 ろうか ? 」 1 2.5inch 100GB ( 7 , 2()0rpm ) の日立製 HDDO 5 , 4()0rpm なら、 たとえば、私の手許にある Windows XP マシンには 1 万数千円で同容量のものカ手に入る。 0 を一口 0 ヾ、 27 UNIX MAGAZINE 2006 . 3
もちろん、この 2 点だけではない。ファイルシステムは 、、イ反想 " ストレージだから、提供する個々のファイルが相互 に独立している必要がある。つまり、 ・あるファイルへの操作が、別のファイルの内容に影響を 与えてはいけない のである。 たとえば、どこかの web ページからファイルをダウン ロードしている最中に電源断が起こったとしよう。その結 果、 /etc/passwd カれ、誰もログインできなくなった、 などという事態になっては困る。被害を受けたのが 1 つの ファイルだけならまだしも、ファイルシステム全体力鱇れ、 すべてのファイルを失う事態なと考えたくもないだろう。 ファイルへの操作は、 all or nothing で反映してほしい 中途半端な状態は困る。ファイルヘデータを書き込んでい る最中に電源断が発生したら、すべての更新をなかったこ とにするか、電源断前にすべての更新が終了していたかの ように振る舞うかの、どちらかにしてほしい。 中途半端な状態というのは、、、更新部分の頁から 10 バ イト目までしか反映されていない " といったお行儀のよい 場合ばかりとはかぎらない。 、、 1 バイトおきにしか反映さ れていない " とか、、、最後の 20 バイトだけ反映されてい る " といったこともありうる。 もっとも怖いのは、ファイルサイズを大きくし、そこに データを書き込もうとした際に起こった電源断である。た とえば、それ以前に別のファイルカ駛っていた領域を再利 用し、追加データを格納しようと決め、領域の再初期化を おこなう直前に電源断が生じたとする。この場合、その 領域にオ内されていた旧いデータが見える状態が発生した あるいは、メールの draft を書いている最中に電 源カ駱ち、再起動したところ、その draft に /etc/shadow の旧いデータが入っていたら・・ 。セキュリティ的な観 点からしても、これほど布いことはない。 、、ファイル更新が途中で止まった " と聞くと、ほとんどの人 は、ファイルの先頭から数バイトだけが更新され、その後 は手つかずの状態となる、、シーケンシャル更新の中断 " を 思い浮カべる。しかし、最近の HDD は指定したとおりの 川印茅ではプラッタ 2 に書かない場合が多い。もちろん、シー 2 、ハード " な、ディスク " のゆえんともいうべき、磁場でデータを言できる 板 ( ガラスなとでできている ) 。 28 ケンシャル更新を強制することもできるが、平均的な読み 書きの速度が大きく低下する。それなら、むしろ、、中途半 端なデータ更新 " をいっさい禁止するほうカ率的である。 中途半端なデータ更新を禁止することを、、 Atomic Up- date" という。多くの人はほとんど意識していないと思う が、 Atomic Update はファイルシステムに対する暗黙の 重要な要件である。 上記の要件は、仮想ストレージの基盤となる物理ストレ ージか皸損した場合は、実現されなくてもやむをえない。 仮想ストレージといえど、データ自体は物理ストレージ上 に格納されているが、その故障防止はファイルシステムの 守備範囲ではない。 こまで、仮想ストレージとしての、、実用的 " ファイルシ ステムに求められる最低限の前提をみてきた。一覧にする と、次のようになる。 くてもよい。 前提 6 : 以上は、物理ストレージが壊れた場合は満たせな 前提 5 : Atomic Update をサポートする。 ない。 前提 4 : ファイル操作によるファイルどうしの相互干渉は を指定する。 前提 3 : 各ファイルには名前があり、その名前でファイル 前提 2 : 電源断発生の予測は不可能である。 前提 1 : 電源断があってもデータを保持し続ける。 UN 工 X MAGAZINE 2006 . 3 図 1 から見ていこう。 今回、私がモデル化したストレージを図 1 ~ 2 に示す。 しい。 近の HDD はそういう性質をもっていると思って読んでほ てモデルを作ろう。一部、 j 日感があるかもしれないが、最 ますは、現在よく使われているストレージをベースとし ストレージの性質を考えなくてはならない。 それには、ファイルシステムを作るための、、土台 " である にして実装するかである。 ファイルシステムの前提は分かった。次は、これをいか ストレージのモデル化 に対応すること力外質的な最重要課題である。 の前提もある。ただし、あくまでも上記の 6 つの前提条件 実用上は、 POSIX インターフェイス仕オ、の準拠など
特集 はじめに 仮想ストレージとしてのファイルシステム [ ] ] 奥山健一 最近、、、仮想化 " というキーワードが大人気である。言 t 算 機のリソースのほとんどが仮想化さ楸複数の実言 t 算機を 渡り歩く機能も実装されつつある。 そのなかで、長い歴史をもちながら、軽視されている仮 想化技術がある。 それが、、ファイルシステム " だ。、、ストレージ " を仮想化 するための技術の 1 つである。 30 年以上もの歴史があるため、ファイルシステムの機 能はまことに多種多様である。とくに、 UNIX やその子孫 たちの場合は、デバイスへのアクセスもセキュリティ機能 も、すべてファイルシステムの機能をベースに作られてい る。その守備範囲は広大だ。 以下では、そのファイルシステムにおける、、ストレージ のイ反想北 " という機能に焦点を絞って説明する。ただし、初 期化や終了処理などの特殊なケースには触れない。 現在のほとんどの OS は、ファイルシステムに強く依存 している。ところが、当り前すぎるからか、ファイルシス テムが満たすべき要件を理解できない人が増えつつあるよ うだ。また、 HDD などの技術の進歩にともない、これま では有効だったいくつかの前提が成り立たなくなってきて もいる。、、ストレージ " のモデル化をやりなおす時期がき ているのだろう。 今回は、ファイルシステムの、、理想論 " についてお話しす る。まず、、、そもそも、何を期待してストレージを使うの か " から始める。次に、最近の HDD などのモデル化を試 みる。そして、それらの上にファイルシステムを作る際の 理想論を駆け足でみていくことにする。 26 理想的なファイルシステム 次回は、 Linux の各種ファイルシステムの評価、 project DOUBT などをとりあげる予定である。 ファイルシステムの必要性 計算機におけるストレージの彳殳割 本誌の読者の多くは、 1 台以上の計算機を日常的に操作 し、それらの保守管理もおこなっているだろう。 PC のハ ードウェア構成についても、ある程度は理解しているにち がいない。 そこで質問を 1 つ。 「手近にある PC に、電源を切っても情報をイ尉寺できる部 品は何個あるだろうか ? 」 じつは 3 種類しかない。 ROM 、 CMOS 、そして外部 記億装置 ( ストレージ ) だけである。 ROM は、電源投入直後に実行される BIOS のような プログラムを十内するために利用される。 CPU が直接ア クセスできるなど、たいへん便利ではあるが、内容の変更 カ攤しいという弱点がある。 CMOS は、チップセットのなかにある。電力がボタン 電池で供給されるため、内容は電源を切ってもイ尉寺される。 ROM と同じく CPU からほば直接に値が参照できるし、 アクセスも高速だ。 ROM とは異なり、内容の変更も可能 である。ただし、容量はたった 256bit しかない。ボタン 電池で内容を何年も保持するため、大容量化は難しい ( そ もそも、 BIOS がすべてのビットを消費している ) 。 大容量で内容の読み書きができ、内容の保持によぶんな エネルギーを必要としない ( 長期間、大容量の情報を保持 UNIX MAGAZINE 2006.3
UNiKNF ( 0 n t e n t s 2 0 0 6 / 0 3 [ 特集 ] 26 仮想ストレージとしての ファイルシステム 奥山健一 長い歴史をもちながら軽視されている仮想化技術が、ファイルシステム である。ストレージを仮想化する技術としての機能に焦点を絞り、詳細に 解説。ストレージのモデル化をおこない、理想的なファイルシステムの 構造について考えていく。 し inux のプロセス 白崎博生 今回はまず、プロセスとスレッド、タスクの概念、システムコールの働き について説明する。続いて、し inux カーネル 2.6.13 のソースコードに 沿って、プロセスを生成する fo 「 k システムコール、終了させる exit シス テムコールにおける処理を解説する。 87 連載 UNIX Communication Notes ・・・・・・山口英 情報資産の運用管理 ネットワーク・ミニ実験室・・・・・・荒井美千子 BIND9 の Dynamic Update 国立天文台のネットワーク・・・・・・大江将史 ネットワーク回線の変更 文房具としての UN Ⅸ・・・・・・宮地利幸、森島直人 プライベート認証局ーールート証明書の発行 天文学と UN Ⅸ・・・・・台坂博 M 円プログラミングの基礎 プログラミング・テクニック・・・・・・多治見寿和 newsyslog の d0 entry 関数 Pe 活用のヒント 今津英世 RSS ファイルの生成 COVER, CONTENTS DESIGN, ILLUSTRATION ・ MORIYA, KAZUO (AUDREY THE DESIGN)
特集 仮想ストレージとしてのファイルシステム [ 1 ] 図 6 ファイルシステムの全体像 OS / アプリケーション ないことを祈る のどちらのほうがリスクカ觝いかという問題が発生する。 最近の HDD は、利用期間が数年程度であればめった に NVM の石員は起こさない。結果として、前者の Read after Write 方式カ坏リ用されるのはごく稀である。今回の モデルでも、この方式は考慮しないことにする。 理想的なファイルシステムの構造と考え方 こまでで、ファイルシステムに対する前提 ( 前提 1 ~ 6 ) 、ストレージのモデルとその特徴 ( 特徴 1 ~ 7 ) の一部が 明確になった。 これらの条件に合致するファイルシステムを作る場合、 どのような点に着目すればよいだろうか。 以下では、具体的な実装には踏み込まず、どのような観 点から何を考える必要があるのかに絞って説明する。 ファイルシステムの全体像 、、ストレージ a のセクタ b から c セクタぶんを読み込み、 まず、プログラムとしてのファイルシステムの理想像を そのなかの p バイト目から q バイト目までにある目的のデ 図 6 に示す。 ータを読む " ファイルシステムは古典的な機構で、必要とされる要求 という処理に変換され、結果カされる。 はかなり明確になっている。したがって、これらの要求を 一方、 Attribute HandIer の仕事は 2 つある。 1 つは 満たすための基本的な枠組みというものカ在する。これ 、、ファイルの名前空間 " から、、具体的なファイルの指定 " へ を VFS (Virtual File System) という。 の変換、もう 1 つはファイル属性の提供である。これら 新しいファイルシステムを作りたければ、 VFS という は、 Storage Layout による、、ファイル " サービスの提供 フレームワークが内部向けに提供しているインターフェイ を前提としている。 スを利用し、 VFS カ、要とするフレームワークに合わせて VFS が 2 層構造になっているのは、これらの層がフォ インターフェイスを構築することになる。 ーカスすべき対象が異なるからである。 古典的な VFS では、 OS / アプリケーションに対するイ Storage Layout 層は、ストレージにとって最適になる ンターフェイスだけが定義されていた。今回の、、理想的フ ように作らなければならない。いくらモデル化してあると ァイルシステム " では、 VFS の内部を 2 つのユニットと 4 はいえ、動特性によってストレージの動作は異なる。これ つのインターフェイスで構成する。 を無視してファイルシステムを構築すると、応答速度の低 VFS に沿って新たなファイルシステムを作る場合には、 いシステムになってしまう。 Storage Layout" と、、 Attribute Handler" の 2 つの層 一方、 Attribute HandIer 層は OS によって提供すべ を作成しなければならない S 、 0 , 0g0 L000 、は、 : 一イ " を . = トレージ上に構 き機能が異なる。 Windows には read only や hidden などの属性があるが、 UNIX では read/write/execute 築する。たとえば、 になっている。さらに、最近では ACL (Access Control 、、ファイル w の先頭から数えて x バイト目から y バイト List) などにより、言田なアクセス制御が標準的に要求され ぶんのデータがほしい " る。ファイル名にも、文字コードの問題がある。 ASCII や EBCDIC 、 Unicode であったりする。これらか変わるた という要求は、 Storage Layout によって、 ① VFS I/O lnterface ② Layout lnte rface 3 Virtual Device lnterface ④ VM lnterface Attribute Handler Storage Layout 3 VFS 0 デバイスドライバ 33 UNIX MAGAZINE 2006 . 3
Mar. 2006 2006 年 3 月 1 日発行 ( 毎月 1 回 1 日発行 ) 第 21 巻第 3 号通巻 233 号昭和 63 年 9 月 5 日第三種郵便物認可 ユニックス・マガジン 仮想ストレージとしての ファイルシステム 一理想的なファイルシステム ・ストレージのモデル化 ・ファイルシステムの構造 ・ VFS の多層構造化 三二・ラ。 」のン幻ョ」じリっ住引せも プゴセ芳の第匕了 天文学とリ N Ⅸ M 円プログラミングの基礎 国立天文台のネットワーク ネットワーク回線の変更 プログラミング・テクニック newsyslog—do_entry 関数 リ N Ⅸ便利鮎 M00 引 e の活用法 し inux のツールたち Mandriva Linux 2006 文房具としてのリ N Ⅸ プライベート認証局の構築
特集 図 5 PC からストレージに書き込む際のテータの不舞カ川頁序 メインメモリ ステップ 1 デバイスドライバ PC HDD / ヾッファ Read/Write ControIIer 1 接続ケーカレ Controller 2 ステップ 2 : NVM ( 不揮発性メディア ) 移動順序は図 5 のように 2 段階になる。 ステップ 1 : データを PC のメインメモリからトレージの Read/Write バッフアへコピーする。 ステップ 2 :Read/Write バッファ上のデータを NVM に書き込む。 メインメモリから NVM へ直接データを書き込むことは できない。 a) 接続ケープル上をデータカ毓れるタイミングは、厳密 には制御できない b) 接続ケープル上をデータが流れる速度は、 NVM に書 き込める速度とは無関係に決まっている c) NVM は、書込み速度に厳密に合わせたかたちでデー タを受け取らなくてはならない という 3 つの要件に合わせるには、 Read/Write バッファ という、、高速な中間バッファ " が必要なのだ。 さきほど述べたとおり、 Read/Write バッフア自体は不 揮発性ではなく、ここに置かれたデータは電源断と同時に 消失する。したがって、データをバッフアに中幻去した段階 では偂醍 1 の要件は満たされていない。 FIush Cache 命令は、 Read/Write バッファ上にあり、 まだ NVM に書き込んでいないデータをすべて NVM に 書き込めという命令である。 UN 工 X MAGAZ 工 NE 2006.3 仮想ストレージとしてのファイルシステム [ 1 ] このモデルでは、、、過去に送ったェ番目のデータだけを 優先して HDD に書き込め " という命令はないので、 Flush cache 命令は上記のステップ 2 を強制できる唯一の方法に なる。また、いったん Read/Write バッフアに到達した 書込み命令は、それ以降、状態を追跡する術はなくなる。 一部の HDD には、 write キャッシュという機能があ る。この機能が ON になっていると、ステップ 1 が完了 した時点で write 命令が終了したことになる。 OFF にな っていると、ステップ 2 が完了するまで write 命令の終 了にはならない。 この機能はその名とは異なり、 write キャッシュを OFF にしても Read/Write バッフアを経由せずにデータを直 接書き込めるわけではない。さらに、最近の HDD には write キャッシュを OFF にできないものも多い。とく に、 ATA 系の廉価なドライプではその傾向か顳著である。 そこで、今回のモデルでは write キャッシュを OFF にす る機能は仮定しない。 Read/Write バッフアの容量は、 NVM 自身の転送速度 や書込み遅延などにより適切なサイズか変化する。今日の HDD では、 16MB ほどにもなる。この容量を効率的に活 用するため、最近のストレージは特徴的な動き方をする。 特徴 5 : Out of Order 読み書き要求のストレージへの到達速度が NVM の I/O 速度を上回ると、いくつもの命令が実行待ち状態にな る。このとき、 PC から与えられた命令の川印ではなく、ス トレージにとって都合のよい川印で読み書きをおこなうと、 ヘッドシークなどのオーバーヘッドによる無駄な時間が減 り、総合的な I/O 性能力痾上する。それには、ストレージ に与えられた命令川印事を Out of Order で処理できなくて はならない。これを、、 NCQ (Native Command Queu- ing)" と呼ぶ。 NCQ はオーバーヘッドを低減するが、 NVM への読み 書き川印茅は予想すらできなくなる。 書込み順序がまったく保証されず、次々に読み書きの命 令カリ着し続けると、永遠に NVM に到達しないデータが 発生するおそれがある 4 。書込みに順序保証を求める場合 4 A 、 B 、 C という 3 つのデータを書き込もうとしたとする。さきに B と C を書き込んだほうカ上糾よよい。そこで、そうする。ところが、そのあい だに新しいデータ D 、 E がやってくる。 A よりも前に D と E を書き込 んだほうカ上がよいので・・・・。こうして、 A は永久に取り残される。 31
は、あいだに FIush Cache 命令を挟んで側を確保する すでに Read/Write バッファ上にあるデータへの読込 必要がある。このような処理を、、 write Barrier" と呼ぶ。 み要求があった場合、ストレージは NVM を参照せずにバ 複数の Write Barrier 間にある書込み命令は、どのよう ッファ上のデータを言 t 算機に返す。これは、 Read/Write な川印で実行してもかまわない。しかし、いったん write バッファ上に存在するが、まだ NVM に書き込まれていな Barrier に到達したら、 Barrier よりも前にあるすべての いデータについても同様である。 ダーテイデータ (dirty data) を書き終えるまで、次のデ たとえば、 HDD に書込み命令を発行したとする。 Flush ータを書込みにいってはいけない。 Cache を実行する前に言囚みリクエストを発行すると、た 読込み順序を保証しなければならない場合は、さきに しかに HDD から同じデータが返ってくるだろう。だが、 実行する必要のある読込み命令カ院了するまで次の命令を この段階ではデータがプラッタに書き込まれたという保証 与えないというかたちで制御する必要がある。これには、 はない。つまり、電源断が生じると、、読み込めたデータで TCP/IP などの場合と同じく、 Sliding Window を使う あっても " 失われる可能性がある。 のが一的である。 仮に Flush Cache 命令を実行し、ストレージ側はデー タが NVM に転送されたと主張したとしよう。ところが、 # ギ徴 6 : Lazy write 実際には NVM カ員しているかもしれない。ここで特 計算機側に、可及的速やかに NVM に中幻医する必要のあ 徴 1 を思い出してもらいたい。書込み中は、 NVM の中身 るデータがある場合は、 Flush Cache などの書込み命令が は確認できないのだ。かといって、計算機側から同一領域 発行されるはずだ。逆にいえば、これがくるまでに電源断 への言囚み要求を発行しても、 Read/Write バッファ上の が発生したら、データカ趺われてもかまわないことになる。 データカ弡ってくるだけで、 NVM の状態は確認できない。 よって、 FIush Cache 命令が発行された場合を除き、ス Read/Write バッファ上からデータがなくなり、 NVM トレージは PC から転送されたデータを即座に NVM に を読みにいかなくてはいけないような読込み命令が発生し 書き込もうとはしない。 ている場合は、メインメモリにも目的のデータはないこと 書込みの遅延には、次のようなメリットがある。 が多い。メインメモリのほうカ溶量が圧倒的に大きく、か っそこに目的のデータがあるあいだは、そもそもストレー ・同一のプロックへの上書き命令があとからやってきて、 ジに言囚み命令など発生しないからだ。この段階で、 NVM NVM への書込み回数を減らせるかもしれない。 カ蔀皮損していて、目的のデータがきちんと書き込まれてい 複数の I/O 命令を蓄えることで NCQ の効果が軍さ なかったことが分かっても手遅れである。 れ、総合的なスルーブットカ可司ーヒするかもしれない。 本来、この問題を回避するには、、 Read after write" 型 ただし、あまりに多くのデータを NVM に書き込まない の書込み命令を使う。つまり、 NVM に書き込んだあと、 まま蓄積してしまうと、次のようなデメリットが生じる。 NVM からデータを再度読み込み、 Read/Write バッファ ・電源断によって失われるデータ量カ社曽大する。 上のデータと比較してエラーがないかを確認する。この方 ・ Read/Write バッフアが書込みデータで一杯になって 法では、 NVM に書き込んだあと、同じセクタを読み出す しまい、 NCQ か読込み処理をさきにおこなおうとした 必要があるぶん、実行時間が長くなる。 とき、 Read / Write バッフアに空き領域がないという状 ところが、話はここで終らない。たいていの NVM は、 態に陥るかもしれない。 売込み時にも物理的破損を起こす危険性がある。 HDD で あれば、ヘッドがプラッタに着地する場合などがそれだ。 これらの長短のバランスをとるには、ストレージ自身の こうなると、 内部情報カ坏可欠になる。このため、 Controller 2 の専任 事項として処理され、ストレージの挙動の予測はますます ・ Read after Write を実行し、読込み時に NVM カ蔀皮 困難になる。 損するリスクを負う 榻徴 7 : 書込みのイ新寉定性 ・ write 十 Flush Cache だけを実行し、 NVM の石員が 一三ロ 32 UN 工 X MAGAZINE 2006 . 3
特集 か Atomic に更新できない。これは、書込み能力の限界を 試すようなべンチマークでは苦しい。 2 つ目は、上記の問題を回避するための方法で発生する。 これは、一殳に、、部分 Logging" と呼ばれる方法で、たと えばメタデータだけを Logg ⅲ g の対象にしようというも のだ。これを利用すると、書込み川印がさらにややこしく なる。データを CoM 方式で処理する必要があるが、それ では fragmentation 問題の発生は防げない。既存のデー タを一部上書き、一部追加するような場合には、次のよう なことを考えなければならない。 追加部分、上書き部分、メタデータをどの順序で書けば 矛盾がなくなるのか。 ・どのような情報をログ上に残すのか。 ・どこまで終了していれば、完全に再実行してよいのか。 ・どこまで終了していれば、、、なかったこと " にしなくては いけないのか。 これらの点を相当考えたつもりでも、結果的には考慮不 足に陥っている場合が多い。 3 つ目の弱点は、もっとリである。すなわち、 、、ログを書き忘れても簡単にはバグが分からない " ことだ。事実、 Logging 方式における 2 大バグは、 ・ログに記録すべき更新情報をまとめるバッフアに更新記 録を書き忘れる そのバッフアを Write Barrier 付きでストレージに書 き込むことを忘れる である。 Logging 機能がないからといって、絶対確実にフ ァイルシステムが壊れるわけではない。かなりクリティカ ルなタイミングで電源断が発生しないかぎり、ファイルシ ステムは適当 ( いい加減 ) に更新されてしまう。また、壊れ た場合にも、木構造で問題となるポイントを参照しなけれ ば、障害カ験出されることはない。 さらに、 Logg ⅲ g 機能のために、ファイルシステム整合 性確認プログラム (fsck) がろくなチェックをしていない場 合もある 6 。これでは、不整合カ材衾出できない。 6 Linux の XFS など、、 return 0 ; " としか書かれていない。なんという ・ずいぶんと思い切りのよいシステムである。 UNIX MAGAZINE 2006 . 3 仮想ストレージとしてのファイルシステム [ 1 ] その結果、不整合カ緻命傷になるまで障害カ験出できな いという問題が発生する。もちろん、その場合に原因カ畤 定できる可能性はほとんどない。 今回は、ファイルシステムに求められる要件を概観した。 そもそも、我々はなぜストレージを使うのか、ストレー ジはどういう性質のものなのかも述べた。そして、ファイ ルシステムの大きな構造である VFS をとりあげ、その下 半分にあたる Storage Layout 層について駆け足で説明 0 次回は、 Attribute Handler 層について説明する。な ぜ、 VFS をこのポイントで分割したのかについても述べ る。それまで待てない人は、「特開 2004-334419 」という 資料を参照してほしい。 Layout lnterface を独立させた 理由が分かるはずだ。 そして、理想論と比較した現実のファイルシステムの状 況、最新の動向について説明する予定だ。具体的な標的は Linux である。今回は理侖を述べたので抑え気未だった 、、巧の教祖様 " の怨嗟の声にも期待していただきたい。 ( おくやま・けんいち NTT データ先端技術 ) ☆ 41