Copyright (C) Ken'ichi Fukamachi, 2021-2025. CC BY-NC-SA 4.0

class: title, smokescreen, shelf, no-footer # ストレージ<br><small><small>〜ファイル,ファイルシステム,デバイス,RAID〜</small></small> <div class=footnote> <small> <small> (脚注) <B>ストレージ</B>というタイトルですが補助記憶装置=長期記録関係全般の話題をあつかいます </small> </small> </div> --- class: compact # おしながき <div class=footnote> <small> <small> (脚注) 今回は普通のPC一台の中で行える処理について解説し、その他の高信頼化手法は次回 </small> </small> </div> <small> データの記録関係全般の話題をあつかいます 1. 補助記憶装置というハードウエアについて解説を少々 - HDDの構造 - SSDの構造 - 磁気テープの現在 1. ファイルというデータ構造 - データストリーム(<- コンピュータネットワークでやりましたね、ok?) - ファイル = メタデータ + データ 1. ファイルシステム - 木構造のディレクトリ(フォルダ) - ファイルシステムレベルでの(ファイルの不整合をふせぐ)障害対策 1. [RAID](#RAID) (Redundant Arrays of Inexpensive Disks)を使った冗長化による障害対策 1. ~~複数のPCを使う(冗長化による)[高信頼化手法](../highavail/)~~(これは次回の話題) </small> --- class: col-2,compact # 補助記憶装置 <div class=footnote> <small> <small> (脚注) 【基本情報試験の出題範囲】 (a)HDDは動作原理も含む (b)入出力装置や補助記憶装置の各種デバイスについての名称くらい </small> </small> </div> - **補助記憶装置** - **HDD** (ハードディスク) - **SSD** (**Solid State Drive**) - FD (フロッピーディスク) - 光ディスク(CD-ROM,DVD,BD) - **磁気テープ**(DAT) - USBメモリ,SDカードのたぐい - 注: **主記憶装置**(メインメモリ)はストレージ話とは無関係です <wbr> - **ブロックデバイス** ... ストレージのたぐいの実体であるHDDやSSDなどはブロック単位での読み書きをするデバイス。代表的な単位はHDDのセクタ=512バイト - **キャラクタデバイス** ... ブロックデバイスの対極。入力デバイスが典型。キーボード,マウス,ジョイスティック,スキャナー,バーコードなどのデータ転送は低速です(1文字ずつのスピード感) --- class: col-2,compact # データを確実に長期保存する <div class=footnote> <small> <small> (脚注1) データ作成に費やされた人間の時間は貴重なので確実にデータを保存したい！ (脚注2) 分散システムは次回すこし取り上げる予定です (脚注3) ランサムウエア対策としてもマメなバックアップは重要で、 バックアップしたものはREAD ONLYにできるとなおよし </small> </small> </div> - データの保存はOSの最も重要な機能のひとつです。 確実な読み書きが求められます。 さらに、できるだけ高速な読み書きが出来るとなおよいです - 障害対策 <small> - 装置自体の信頼化や冗長化 - ソフトウエア(ミドルウエア)による冗長化 - 分散システム (ネットワーク接続された安価なコンピュータ群でリカバー) </small> <wbr> - 定期**バックアップ**は運用の基本 <small> - 手動より自動がよい。 現代では保存先としてGoogle Driveなどの**オンラインストレージ**もありますが、 利用には十分なネットワーク帯域が必要だし、 外部におく以上セキュリティは一層きをつけないといけません <br> (**運用の話題になるので以下省略**) - **[RAID](#RAID)**による冗長化で耐障害性向上 - サーバ機材ではRAIDカードの利用が普通 - 個人利用ならOSのRAID機能(Software RAID)でも十分な速度です </small> --- class: title, smokescreen, shelf, no-footer # デバイス<br>〜HDD,SSD,磁気テープ〜 <div class=footnote> <small> <small> </small> </small> </div> --- class: col-2,compact # デバイス: HDD, SSD <div class=footnote> <small> <small> (脚注) 現代で身の回りにあるPCが使うストレージ端子の規格はSATAかM.2くらい </small> </small> </div>  <small> 2.5インチのSATA HDD(左)と、 M.2 SSD(右側の銀色ヒートシンク下の板,よく見えないけど;-) </small>  </small> 2.5インチのSSD(端子はSATA)、 見栄えは写真(左)のHDDと変わらない (-> ノートPCのHDDをSSDに入れ替えて高速化できる) </small> --- class: col-2,compact # デバイスの物理的な話: HDD <div class=footnote> <small> <small> (脚注) レコードと一緒ですよ！って説明が通じない世代ですね... orz </small> </small> </div> - 小さな磁石(N極とS極)で0と1を表現する媒体で、磁石の層が平たい金属盤の上に塗られています - 金属板は常に回転していて、 読み書きしたい場所(セクタ)にはアームを近づけ、アームの先で磁場を使って読み書きします (アームを直径方向に移動させ、読み書きしたいセクタが回転してくるのを待ちます) - 回転速度(分速)は4200〜15,000rpm - YoutubeなどにHDDを分解して動作させている動画があるので、 それらを見た方がわかりやすいでしょう(-> 右の動画)    <!-- <iframe width="240" height="160" src="https://www.youtube.com/embed/J6VQGveQXNo?rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> --> <iframe width="240" height="160" src="https://www.youtube.com/embed/oGygwiprEbA?rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> --- class: col-2,compact # デバイスの物理的な話: HDDのメリット、デメリット <div class=footnote> <small> <small> (脚注1) 最近はセンサーで墜落を関知した場合アームを固定して衝撃に備えてます (脚注2) 2021年末、Seagateが20TBのHDDを発売 <br> (脚注3) アームは円盤上20nm ... もしHDDが飛行機サイズとしたら翼は地上数mmでしかない。 この精度で15000回転/分です...すごい </small> </small> </div> <small> - メリット - 枯れた技術。コストパフォーマンスがよい。 保存性能も予想以上に高い - デメリット - 磁気媒体も原子サイズにはならないので、ある程度の大きさは必要。 金属の円盤を回転させるため、電力も必要だし、速度にも限界あり。 (アームがあるので)衝撃には弱い。 (アームの移動が必要なので)ランダムアクセスは不得意 - HDDは密閉されておらず、円盤は空気の粘性からくる圧力を利用して浮いています。 周囲の騒音(->動画)や空気の汚れの影響あり </small>  <iframe width="240" height="160" src="https://www.youtube.com/embed/tDacjrSCeq4?rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> --- class: img-right,compact # デバイスの物理的な話: SSD <div class=footnote> <small> <small> (参考) <A HREF="https://www.slideshare.net/InsightTechnology/dbts-osaka-2014-b11-hardware-hironobuasano"> いまさら聞けないSSDの基本 </A> by (今はInsight Technology)の浅野さん (脚注) 量子力学効果のため、そろそろ微細化も限界で... </small> </small> </div>  - LSI。 絶縁体の箱の中に電荷がある/なしで1/0を表現しています。 **SLC**は1/0(1bit)、 **MLC**(2bits)や**TLC**(3bits)は箱内の電子量を細かく判定し、多値化を実現 - 書き込みや消去は**電圧をかけて強引に絶縁体を越えて電荷を移動**させます <br> (SSDを痛める原因の一つ) - 右図は**フローティングゲート**型。 箱内の電子量により基盤側に流れる電流が変化する。そこから値(1-3bits)を判断する - もうひとつ**チャージトラップ**型というのがあり、TLCは両タイプの製品がある - **微細化も限界**で**3D**(縦方向の積層数)勝負 --- class: compact # デバイスの物理的な話: SSDのメリット、デメリット <div class=footnote> <small> <small> (脚注) Q: 安いSSDとは何か? A: 怪しげなコントローラとか、キャッシュを小さくするとか... (蓋を開けたらUSBメモリだったとかな:-) </small> </small> </div> <small> - メリット ... (a)軽い、小さい、回転部品が無いので(HDDよりは)衝撃に強い (b)ランダムアクセスが得意 (c)最近だいぶ安くなり実用的になりました(最近はHDDと数倍差) - デメリット - 物理的に部品へ無理がかかるため、 つねに少しずつ摩耗(崩壊)している媒体です。 長期保存は危険です。 有名ブランドのSSDをPCの耐用年数程度(数年)使うくらいなら問題ないでしょう。 つまり普段使いなら大丈夫です。 ただしHDDのように20年ものでも使えますか?というと、おそらく無理 - 少しずつ崩壊するため、 特定の場所に読み書きが集中するのは避けないといけません。 均等に摩耗するようにコントローラが調整しています (**wear leveling**; wear=摩耗) - HDDと同じインターフェイスでも、裏側は大きく異なります。 <br> HDDのセクタより大きな単位で処理しています。 とくにErase(消去)は大きな単位でしか処理できません。 (HDDのような単純な)更新処理もできません。 - このように、さまざまな合わせ技でSSDを動かすため、 **性能や耐久性はコントローラ**で大きく変わります。 信頼できるブランドのSSDを買うことくらいしか対策はないでしょう </small> --- class: col-2,compact # デバイスの物理的な話: 磁気テープ <div class=footnote> <small> <small> (脚注1) もはや磁気テープは日本(それも富士フィルムだけ?)しか製造しておらず、 全世界のクラウドの裏側は日本だより！ <B>需要拡大中</B> <br> (脚注2) 磁気テープの価格は手頃ですが磁気テープドライブがサーバ用しかなく高価(数十万〜)なので、 個人はテープよりHDDが手頃 <br> (脚注3) ちなみにLTFSの仕様は <A HREF="#ufs">Unix初期のファイルシステム</A>そっくりでINDEXとデータを分けて管理 </small> </small> </div> <small> - 容量単価、大容量性、長期保存性能という点で、 **磁気テープ**が最強の保存媒体です。 - 現在はテープ1巻12TBですが、 1巻[580TBの目処はある](https://www.fujifilm.com/jp/ja/business/data-management/data-archive/tips/merit/009)らしいので、まだまだ大容量化が可能 - 巨大ストレージのバックアップは磁気テープしかない。 Googleも磁気テープでバックアップをとっています。 ransom対策もあり需要急増中 - 近年はLTFSという磁気テープ向けのファイルシステムも策定され使いやすくなりました！ LTO-5規格以降なら、 (HDD/SSDをみるように)磁気テープをフォルダとして開いて操作ができます </small>   --- class: col-2,compact # 銀の弾丸などない <div class=footnote> <small> <small> (脚注1) HDDや磁気テープは永遠に不滅です！(は言い過ぎか:-) <br> (脚注2) F.J.Brooks, <A HREF="https://doi.org/10.1109/MC.1987.1663532">"No Silver Bullet"</A>、 Brooksの有名な「人月の神話」新装版の第16章に日本語訳が収録されている </small> </small> </div> - SSDは万能ではありません <br> (一般に「新技術も特定の分野に秀でているだけで前時代の問題の全てを解決するわけではない」 と言えます) - 身の回りからHDDや磁気テープがなくなることはあるかもしれませんが - **クラウドの裏や業務用サーバでHDDや磁気テープがなくなることは(当面)ありません** <wbr> - Googleが次世代のHDDにもとめているもの(2016) <small> - ランダムアクセス性能 - 容量、代替領域は不要なので、その分も容量へ回してほしい - 継続利用性 (アーム先端のヘッドが壊れたらHDDは使えない? -> アームの先端部を冗長にしてほしいとか) - https://research.google/pubs/pub44830/ </small> --- class: img-right,compact # ストレージの階層化 <div class=footnote> <small> <small> (脚注1) SSDとHDD間で自動的に移動する製品(NASとか)が売られてますね (脚注2) AWS S3 Glacier(=氷河)がこれをするサービス <br> (脚注3) 自動化されていたら便利ですけど、 kernelにが実装せずとも、メタデータを見て適切に移動させるデーモンを書けばok </small> </small> </div>  <small> - データにも**参照の局所性がある**ので、よく使うファイルはストレージのごく一部です - SSD -> HDD -> 磁気テープの順に**大容量**ですが、その順に**低速**になります。 そこで、 まずは**SSDに読み書き**し、一ヶ月アクセスがないファイルはSSDからHDDへ移動し、 HDD上で3ヶ月アクセスがないファイルはHDDから磁気テープへ移動するといった運用が理想です - これも一種の多段キャッシュ構造です </small> --- class: title, smokescreen, shelf, no-footer # ファイル <div class=footnote> <small> <small> </small> </small> </div> --- class: col-2,compact # ファイルのデータ表現 <div class=footnote> <small> <small> (脚注) 内部表現はUTF-16なのにWin10日本語版はShift-JISがデフォルトでテオクレ感... </small> </small> </div> <small> - ファイルとは、数字の**バイト列**を格納するもの - **データストリーム**(コンピュータネットワークで取り上げました、ok?) - 改行や空白(SPACEやTAB)を意味するコードを入れておき、 テキストを表示するプログラム(エディタやブラウザなど)が適切な表示を行う**お約束** - Q: 日本語のあつかいは? <br> A: 21世紀のデファクトスタンダードは、 **Unicode**で定義された数字(code point)を**UTF-8**方式でエンコードした数字列。 表示の際は、 その数値を解釈し、該当する日本語フォントで表示します (あ = 343 201 202) </small>   ``` HAMLET To be, or not to be, that is the question, Whether 'tis nobler in the mind to suffer ... 以下略 ... ``` --- class: col-2,compact # ファイルという論理構造(or 概念 or プロトコル) <div class=footnote> <small> <small> (脚注) 実際にファイルを操作する手段はファイルシステムが提供します。 システムコールでkernelに操作を依頼です </small> </small> </div> <small> - ファイルは**メタデータ**と**データ(本体)**から構成されていると考えられます - Protocol Header = メタデータ - Protocol Payload = データ<small>(例: Cのソースコードそのもの、テキストつまりUTF-8の数字の列)</small> - ファイル操作の例 1. ファイル名の変更(a.c -> b.c) <br> メタデータのみを書き換え(ファイル名と最終参照時刻を変更) 1. ソースコードを書き換える場合 <br> データその物の書き換え + <br> メタデータを更新(サイズや最終参照時刻、最終更新時刻などを変更) <wbr> | 属性 | 備考 | |------------------ |-------------------- | | ファイル名 | 文字列 | | ファイルの長さ | バイト数 | | 所有者のID | uid(数字) | | 所有者のグループ | gid(数字) | | ファイルモード | いわゆるpermission | | 最終参照時刻 | unixtime | | 最終更新時刻 | unixtime | 表: メタデータの例 </small> --- class: title, smokescreen, shelf, no-footer # ファイルシステム <div class=footnote> <small> <small> (脚注) 実際にファイルを操作する手段はファイルシステムが提供します </small> </small> </div> --- class: img-right,compact # ファイルを管理するには？本棚？   - ファイルは本で、ディレクトリ(フォルダ)は本棚と考えてよい - 本の奥付 = メタデータ: タイトルや著者、出版日など - 本の中身 = データ(ファイルの本体) - 大型計算機のファイルシステムは一階層なので本当に本棚みたいに見えますが - Unixのファイルシステムは木構造です([DNS](../../../network/tcpip/app_dns/)(右図)と同様)。 - 本棚は階層化されています。 棚のなかを区切り、本棚の階層(入れ子構造)が作れます。 深い階層化も可能です --- class: img-right,compact # ディレクトリ(フォルダ)と木構造 <div class=footnote> <small> <small> (脚注1) rootからの木構造は(/を.にすれば)DNSと同じなので分かりますよね? (脚注2) Windowsの遠いご先祖MS-DOS 2.0でUnixの設計思想を大々的に取り入れたのですが、 MS-DOS 1.0のオプション記号/を維持するために、MS-DOSは区切りに/ではなく\を使い大迷惑 (\はC言語で特別なのに...) (脚注3) T.Berners-LeeがURLを/区切りにしたのはUnix互換OS上での開発だからだと思う(推測) </small> </small> </div>  - ファイルをおさめる入れ物をUnix系では**ディレクトリ**、 Windowsなどでは**フォルダ**と呼びます (以下Unixの話をします) - ディレクトリは**入れ子**にでき**、木構造**をなします (ディレクトリの中にはディレクトリもファイルも入れられます) - Unixでは/で階層の区切りを表現します。 階層の一番上は**/**でrootと呼びます - たとえば/usr/bin/viは図(の網線部の)ような階層をあらわしています --- class: compact # ディレクトリ: lsコマンドでの表示<small><small>(前頁の図と比較してください)</small></small> <div class=footnote> <small> <small> (脚注1) この例で使っているlsコマンドは、 対象がディレクトリの場合、 右端に/を追加して表示しています <br> (脚注2) オプションなしlsコマンドは名前一覧のみを表示、 -l オプションをつけると最重要なメタデータ情報とともに表示します </small> </small> </div> ``` prompt> ls / altroot/ boot.cfg home/ libdata/ netbsd root/ tmp/ bin/ dev/ kern/ libexec/ proc/ sbin/ usr/ boot etc/ lib/ mnt/ rescue/ stand/ var/ prompt> ls -l / ... 省略 ... drwxr-xr-x 2 root wheel 1024 May 12 22:15 bin/ -rw-r--r-- 1 root wheel 172 May 12 22:15 boot.cfg drwxr-xr-x 30 root wheel 2560 Oct 23 10:04 etc/ ... 省略 ... drwxr-xr-x 15 root wheel 512 Oct 20 09:59 usr/ drwxr-xr-x 25 root wheel 512 Oct 8 21:12 var/ permission ユーザ グループ サイズ 最終更新時刻 ファイル名もしくはディレクトリ名 ``` --- class: img-right,compact # パス <div class=footnote> <small> <small> (脚注1) 後半の演習にそなえて紹介するのですが、パスの問題は意外と基本情報処理に出ます <br> (脚注2) ./viは、そのディレクトリにあるviコマンドを実行という意味です。 コマンド検索時に.を探さないのがdefaultなので./が必要 </small> </small> </div>  <small> - ファイルの位置を表現する/usr/bin/viのような表記をパス(path)と呼びます - **/**(root)からの階層をすべて表現したものが**絶対パス**、 いま作業しているディレクトリからの相対表記が**相対パス**です - ディレクトリの移動はcdコマンドの引数にパスを書きます。 **.**(自分自身)と**..**(一つ上,親ディレクトリ)は特別なパスです。 ``` /usr/bin/vi # #の右側はコメントです cd /usr/bin # /usr/binに移動して ./vi # viを起動(/usr/bin/viの起動と同じ意味) cd .. # 一つ上に移動したので今いる場所は/usr ./bin/vi # viを起動(/usr/bin/viの起動と同じ意味) ``` </small> --- class: col-2,compact # ファイルシステムによる性能の向上: (HDDの)高速化 <div class=footnote> <small> <small> (脚注1) FFSの原論文(PDF,1984): [1] <A HREF="https://dsf.berkeley.edu/cs262/FFS.pdf"> M.K.McKusick and W.N.Joy </A> [2] <A HREF="https://dl.acm.org/doi/pdf/10.1145/989.990"> M.K.McKusick et.al. (ACM) </A> <br> (脚注2) もちろんSSDには関係ありません;-) </small> </small> </div> <small> - Berkeley UnixのFFS(Fast File System)で実装し、劇的に高速化しました(4.2BSD, 1983)。 4.2BSDはTCP/IPとFFSサポートという売りが多いversion - HDDは回転する金属の円盤なので、その構造を意識した読み書きをすれば速くなるはず - たとえば、書きこむ際、 アームを極力動かさずにすむ配置を考え、 なるたけデータを同心円上に配置していきます。 アームを直径方向には動かさず、すなおに回転に沿って読めとよいです。 アームを上げて下げる必要がある場合は、上下の時間差と回転する分を考えて配置します </small>   --- class: img-right,compact # ファイルシステムによる性能の向上: 電源断などへの備え <div class=footnote> <small> <small> (脚注1) トランザクションと言った方がわかりみがよい? (脚注2) FFS以前の<A HREF="#ufs">Unix初期のファイルシステム</A>は障害に弱いです <br> (脚注3) FFSの作者M.K.McKusickによる上述のような改善案として<A HREF="https://www.usenix.org/legacy/publications/library/proceedings/usenix99/full_papers/mckusick/mckusick.pdf">Soft Updates</A>があり、現在のBSD系ではデフォルトです </small> </small> </div>  <small> - 電源断などの非常事態からの復旧を容易にする工夫もしています。 具体的には、 メタデータの書き込む順序の最適化やメモリ処理、 ジャーナリングなどで一貫性を保つ方法があります - ジャーナリング(細かい分類は省略) ... メタデータやデータ変更履歴を記録することで障害時の復旧を助ける技術 - 【注意】 これらは中途半端な状態にならない(一貫性を維持する)努力であって、 データの冗長化ではありません。 そのため、 ハードウエア障害でデータがなくなることは避けられません - 冗長化には[RAID](#RAID)や分散システムが必要です </small> --- name: RAID class: title, smokescreen, shelf, no-footer # RAID<br><small><small>- Redundant Arrays of Inexpensive Disks -</small></small> <div class=footnote> <small> <small> (脚注) 本来はInexpensive Disksですが最近はIndependentの略と称することも </small> </small> </div> --- class: compact # RAID (Redundant Arrays of Inexpensive Disks) <div class=footnote> <small> <small> (脚注1) Redundant Arrays of Inexpensive Disks つまり Inexpensive (安い)という用語のとおりです <br> (脚注2) RAIDレベル 2 3 4 は定義されていますが製品を見たことがありません </small> </small> </div> <small> - 本来は**安いHDDをたくさんつなげて大きなHDDを作りたい**という動機 - 1980年代後半の話でRAID 0などは、まさにそれ - データの**冗長化**->耐故障性向上;サーバ機ではHDD障害にそなえてRAIDを組むのが基本 - 実務では専用ハードウエア(RAIDカード)の利用が普通ですが - 個人用であればソフトウエア(カーネルの機能)でも十分な速度です - RAIDの名称はレベル,よく見るレベルは0 1 5 6および10(いちぜろ) </small> | レベル | 概要 | 冗長性 | 利用可能な最大容量 | コスト | |-------- |---------------------------------- |-------- |-------------------------------- |---------- | | 0 | ストライピング:分散して書き込む | なし | 1 | 安価 | | 1 | ミラーリング:2個のDISKに同じデータを書きこむ | あり | 1/2 | 高価 | | 5 | データとパリティを書き込む | あり | (HDD数-1)/HDD数e.g.2/3 | やや高価 | | 10 | RAID1群を作成後それらをRAID0で束ねる | あり | 1/2 | 高価 | --- class: col-2,compact # RAID 0および1  RAID 0 = ストライピング: 大容量かつ(HDDの並列動作で)高速化が可能ですが、HDDが1つ壊れるだけで全滅。 キャッシュなどの一時領域としては便利ですが、保存領域に使ってはいけません  RAID 1 = ミラーリング: 二つの HDD に同時に同じデータを書きこむ。 簡潔な理屈のため回路も簡単で信頼性が高いが、 HDDの半分しか使えない高価な手法。 読むときは2つのHDDから読みこむことで倍速が可 --- class: compact # RAID 10 <div class=footnote> <small> <small> (脚注) RAID 10は数字の10(ten)ではなく1と0です </small> </small> </div>  RAID 1のセットを作り、それらをRAID 0で束ねることで高速化と大容量化が可能 <br> メリット: RAID 0と1のメリットのいいとこ取り <br> デメリット: RAID 1と同じでHDD数の1/2しか利用できない高価なところ --- class: img-right,compact # RAID 5および6 <div class=footnote> <small> <small> (脚注) RAID5の障害時からの復旧は、 壊れたHDDを新しいHDDに交換し、パリティを利用したHDDの再構成を行いますが、 この処理が非常に高負荷のため、 この負荷により別のDISKも壊れて結局HDDが全滅することがあります(実話) <- parity系RAIDがきらいな由縁 </small> </small> </div>  RAID 5 = RAID 1と0の妥協点とも言え、復旧するためのパリティデータを分散配置 (HDDが1台なら壊れても大丈夫、2台こわれたら全滅)。 パリティにHDD 1台分が使われますがRAID 1ほど高価な方法ではないため、よく見かけます。 例: 合計3台のHDDなら2個分、合計4なら3個分の容量が利用可能 RAID 6 = RAID 5 の拡張でパリティを二重にもつ方法です。 HDDの総容量はRAID 5より少なくなりますが故障には強くなります。 最近は 6 を見ることが多い気がします --- name: appendix class: title, smokescreen, shelf, no-footer # <small>付録</small> <div class=footnote> <small> <small> (脚注) これ以降は中間試験に出ません </small> </small> </div> --- name: ufs class: img-right,compact # 参考: ファイルシステムの例(Unixの初期, 1970年代) <div class=footnote> <small> <small> (脚注1) 中間試験には出ません (脚注2) inodeはサーバのデバッグに必要な知識ですが、 OS各論すぎるので情報処理試験には出ません。LPICでは出題されます。 さすがにレイアウトの詳細までは出題されない模様 </small> </small> </div>  - HDDは512バイト単位のsectorという配列と考えてください - セクター0(sector[0], 先頭の512バイト)にはOS起動時に使う特別なデータを格納 - セクター1はHDDのlayoutなど設定情報が入っています(superblock, 詳細は略) - セクター2から**inode構造体**配列が並び、 その後にデータが並んでいます(図ではセクターN以降がデータ): 各inodeが持つデータは (a)メタデータ (b)該当するファイルやディレクトリのデータを格納しているセクタ番号群(必要なだけ複数個)