オペレーティングシステム - PFLab講義スケジュール（予定） 2018/6/25 第11回オペレーティングシステム 3 1. OSの概要（4/9） 2. プロセス管理（4/16）

オペレーティングシステム

加藤真平

東京大学大学院情報理工学系研究科

[email protected]

2018/6/25 1第11回オペレーティングシステム

１．PFLab（加藤研）のウェブサイトからダウンロードできます。⇒http://www.pf.is.s.u-tokyo.ac.jp/ja/classes/

２．紙資料も配布します。

2018/6/25 2

講義概要

• 受講生に求める基礎知識– C言語の理解

– コンピュータアーキテクチャの基礎の理解• メモリ管理、割り込み、CPUモード

• 参考図書– Silberschatz, Galvin, and Gagne, Operating System Concepts 8th

Edition, Wiley

• 成績– 試験の点数で決定

– 試験は持ち込み不可

– 授業に出席していた人で試験の結果が悪い人は追試験あり• 出席をとるが出席点はなし

第11回オペレーティングシステム

講義スケジュール（予定）

2018/6/25 第11回オペレーティングシステム 3

1. OSの概要（4/9）

2. プロセス管理（4/16）

3. プロセス間交信＆スレッド（4/23）

4. プロセス同期（5/7）

5. プロセス同期（5/14）

6. CPUスケジューリング（5/21）

7. CPUスケジューリング（5/28）

8. メモリ管理（6/4）

9. メモリ管理（6/11）

10. I/Oシステム＆ファイルシステム（6/18）

11. ファイルシステム（6/25）

12. プロテクション＆セキュリティ (7/2)

13. バッチシステム＆分散システム＆まとめ（7/9）

14. 試験（7/23）

論文も読んでみましょう。

ACM SOSP

USENIX OSDI

USENIX ATC

USENIX NSDI

ACM ASPLOS

2018/6/25 4

ファイルシステム

• File Concept

• Access Methods

• Directory Structure

• File System Mounting

• File Sharing

• Protection

• File System Structure

• File System Implementation

• Directory Implementation

• Allocation Methods

• Free-Space Management

• Efficiency and Performance

• Recovery

• Log-Structured File Systems


ファイル

• ファイルとは

– 連続した論理的アドレス空間

– 内容:

• データ

– 数値

– 文字

– バイナリ

• プログラム

• ファイル構造

– 構造なし

• 語あるいはバイト列

– 単純なレコード構造

• 行、固定長、可変長

– 複雑な構造• 書式化されたドキュメント、リロケータブルプログラムオブジェクト

– 誰が決める？:

• Operating system

• Program


ファイルとは

• プログラム中に保持する情報

– プロセス生成後に発生し、終了時に消滅

– アドレス空間の大きさに制限

もっと長期に大容量…

プロセスメモリ中ファイル

CPU メモリ

2次記憶2018/6/25 第11回オペレーティングシステム 6

ファイルとは

• 記憶装置の構造に依存しないデータ保持の単位

– データやプログラム

– 記憶装置は主に2次記憶（外部記憶）

• HDD, フラッシュメモリ, 磁気テープ, etc.

• 主記憶上にファイルを配置することも可能

• 統一的な取り扱いが可能な論理的存在

– 生成、オープン, 読み, 書き, クローズ, etc.

– 属性情報を保持


ファイルの名前

• 情報の抽象化：保存しておいて後から読み出し

– ファイルに名前を付加

• 文字数・使える文字等の制限はファイルシステムにより差あり

– 8+3, 256, ... ; 大文字・小文字の区別

• 拡張子 (ピリオド [.] より後ろの扱い)

– ファイルの種類の判定

• .txt, .tex, .doc, .ppt, .bat, .exe, .c, .h, .o, ...

– 単なる慣習の場合

– OS・アプリケーション解釈する場合


2018/6/25 9

ファイル属性とディレクトリ• Name –名前

• Type –ファイルのタイプ

• Location –デバイス上のどこにあるか

• Size –大きさ

• Protection –誰にread/write/deleteを許すか

• Time, date, and user identification


F 1 F 2F 3

F 4

F n

Directory

Files

これらの属性はディレクトリの中に保持

2018/6/25 10

ファイル操作

• Create

• Write

• Read

• Seek

• Delete

• Truncate

• Open(Fi) ： Fiで示されるファイルをディスクから探索

– ファイルの中身をメモリ上で操作できるように

• Close (Fi) ：メモリ上で操作した内容をディスクに反映


2018/6/25 11

ファイルタイプ例


OSにおけるファイルアクセス

• ファイル制御ブロック(FCB: File Control Block)

– ファイル記述子(File Descriptor)とも

– ファイルシステム中の属性情報のうち必要なものを保持

– ファイルのアクセス状態の管理

– プロセスはFCBを通じてファイルを操作

• read, writeの引数ではFCBの配列のインデックスを指定

– ユーザプロセスはFCBの中味は変更が不可能

– Openの返り値として取得が可能


OSにおけるファイル操作

• create/delete

– ファイルの生成・削除

– 生成時には属性の指定

• open

– ファイルの使用開始

– 必要な属性をFCBへコピー

• ファイルアクセスに関する状態情報も保持

– 操作属性の指定 (read only など)



• close

– バッファのフラッシュ、FCBの削除

– 属性情報の更新

– プロセス終了時には全て自動的にclose

• read/write

– データの読み出し・書き込み

– ある程度のまとまりを主記憶(バッファ)に保持



• append

– 追記、writeの限定版

• seek

– 読み・書きの場所の移動

• set/get attribute

– 属性値の取得 (時刻やら)

• rename

– ファイル名の変更


ファイルの構造

• バイト列

– OSはファイルの中味に興味なし

– 構造的な解釈はアプリケーションが担当

• レコード列

– 論理レコード

• ファイルを構成するデータの集まりの単位

– 住所録 = 名前・住所・電話番号

– 改行まで (可変長)

– 物理レコード(ブロック)

• 記憶装置に入出力する際のデータの単位

– 内容は１つまたは複数の論理レコード


ファイルの構造

• 構造を持つファイル (論理構造)

– 2次記憶装置(物理構造)に依らず扱う必要性

– ファイルの2次記憶への格納時

• 論理構造⇒物理構造へ変換し格納

– 2次記憶からファイルの読み出し時

• 物理構造⇒論理構造へ変換し主記憶に配置

• ファイルアクセスの方法

– 2次記憶での構造と入出力の効率化


バッファリング

• 二次記憶を直接読み書き → 遅い

– メモリ中に一次蓄積

• バッファリング（buffering）

– 二次記憶からブロック単位でメモリに転送

– プロセスはバッファに読み書き

– 変更のあるバッファは定期的・解放時に二次記憶に書き戻す

– CPUと入出力の並行処理


ダブルバッファリング

• 二つのバッファ

– 一方のバッファを読み・書きしている間に他方に二次記憶から／へ転送

• プロセスのI/O待ちを最小化

入力レコード

出力レコード

レコードレコードレコード




レコード

レコード

レコード

レコード

レコード

レコード

レコード

レコード

レコード

レコード

レコード

レコード作業バッファ

入力バッファ1

入力バッファ2

出力バッファ1

出力バッファ2


ファイルアクセス手法

• 逐次ファイル (sequential file)

– レコードを書き込んだ順で配置

• 書き込んだ順でのみ読み出し可能

– 磁気テープ上のファイルはこの構造

• レコードの位置はレコード番号で指定

• 途中のレコードを読む場合

– 先頭から読みたいレコードの前までを読み飛ばす必要あり


ファイルアクセス手法

• 直接アクセスファイル (direct access file)

– ランダムアクセスファイル(random access)

– 任意の位置のレコードを直接アクセス可能

• ファイルのブロックサイズの粒度(固定)

– 逐次アクセスの2次記憶装置では実現不可能

• 磁気テープ

• ランダムアクセス可能な２次記憶装置

• ランダムアクセス可能な割当て方式


ファイルの管理

• ディレクトリ (directory) … フォルダ

– ファイルの情報を保持する管理実体

• 1つのディレクトリで複数ファイルを管理

• ２次記憶上に保持

• ファイルアクセスの際にディレクトリもアクセス

– 高速化が必要

– 一部を主記憶にキャッシュ


2018/6/25 23

ディレクトリ操作

• ファイルの探索

• ファイルの生成

• ファイルの削除

• ディレクトリの下のファイルをリスト化

• ファイル名を変更Rename a file

• 他のファイルシステムに移動

– 例：

• LinuxファイルシステムからWindowsファイルシステムへ

– 貸与したLaptop上でWindowsファイルシステムを見ることが可能

• LinuxファイルシステムからNFSファイルシステムへ


2018/6/25 24

ディレクトリ作成の指標

• Efficiency：高速にファイルを探索可能

• Naming：ユーザー利便性

– 複数のユーザーが異なるファイルに同じ名前

– 同じファイルに異なる名前

• Grouping：ファイルの特徴による論理的な集合を定義可能

– 例：all Java programs, all games, …


ディレクトリエントリの管理

• 線形リスト

– 特定のエントリの検索⇒線形探索

– エントリをソート⇒２分探索

• エントリの挿入・削除が複雑 (2次記憶)

• ２分木

– エントリの挿入・削除が容易

– 線形リストより領域が必要

• ハッシュ

– 高速，エントリの挿入・削除が容易

– 同一ハッシュ値の対策が必要


ディレクトリの階層

• 単一レベルディレクトリ

– システムにディレクトリは１つ

– ファイル名をシステム全体でユニークにする必要あり

• ２階層ディレクトリ

– ユーザごとに独立

• 自分の空間のみ参照

• ユーザ間共有不可

・・・

FileFile File ・・・

ディレクトリ・・・

FileFile File ・・・

user nuser 2user 1 ・・・

マスタファイルディレクトリ

ユーザファイルディレクトリ



• 木構造ディレクトリ

– ディレクトリの階層化を一般化

• ルートディレクトリ，サブディレクトリ

・・・

File

File File

File FileFile File

File File

ルートディレクトリ

サブディレクトリ



• パス名(path name) … 木構造の中での指定法

– 絶対パス名 (absolute path name)

• ルートから指定– 例： /usr/local/bin/

– 相対パス名 (relative path name)

• 作業ディレクトリ (working directory)から辿る際のパス

• カレントディレクトリとも (current directory)

• UNIXの場合

– / で区切り、. がカレント、.. が一つ上

• /usr/local/bin にいて ../../lib とすると /usr/lib


2018/6/25 29

単一レベルディレクトリ

• すべてのユーザーが同じディレクトリを使う

Naming problem

Grouping problem


2018/6/25 30

２レベルディレクトリ

• ユーザ毎にディレクトリを作る

•Path name

•Can have the same file name for different user

•Efficient searching

•No grouping capability


2018/6/25 31

木構造ディレクトリ

• 効率良い検索

• グループ化機能

• カレントディレクトリやワーキングディレクトリの概念

– cd /spell/mail/prog

– more list

– mkdir tmp

– rmdir tmp


2018/6/25 32

Acyclic-Graph ディレクトリ

• 異なる名前で同一の実体を参照

(aliasing)

• If dict deletes list dangling

pointer.

解決方法:

– Backpointers, so we can delete all

pointers.

Variable size records a problem.

– Backpointers using a daisy chain

organization.

– Entry-hold-count solution.


2018/6/25 33

Acyclic-Graph ディレクトリ• Hard Link

– ディレクトリからファイルの実体を参照

– ファイル側はreference countを保持

– 参照しているファイルが削除されてもファイルの実体は残る

• reference countがゼロでないから

• Symbolic Link (Soft Link)– ファイルのパス（文字列）でファイルを参照

– 参照しているファイルが削除されると、symbolic linkしているファイル名からの参照が不可能


2018/6/25 34

Acyclic-Graph ディレクトリ• Hard LinkとSymbolic Link (Soft Link)


% cd ~/linktest

% echo “hello” > mydata.txt

% mkdir foo

% cd foo

% ln ../mydata.txt archive.txt

% cd ~/

% ln –s linktest/mydata.txt data.txt

% ls –l data.txt

% rm ~/linktest/mydata.txtの結果、~/linktest/foo/archive.txtおよび~/data.txtはどうなるか？

% rm ~/linktest/foo/archive.txtの結果、~/linktest/mydata.txtおよび~/data.txtはどうなるか？

2018/6/25 35

プロテクション

• ファイルの所有者と生成者は、誰に対してどのような操作を許すかを制御すべき

• 操作の種類

– Read

– Write

– Execute

– Append

– Delete

– List

• ディレクトリの場合、ディレクトリにあるファイル名を検索


2018/6/25 36

Unix系におけるアクセス制御• アクセスモード

– read, write, executeを3bitsで表現する

• ３カテゴリ

RWX

a) owner access 7 1 1 1RWX

b) group access 6 1 1 0

RWX

c) public access 1 0 0 1

• グループの作成– /etc/group

• ファイルのグループ名の変更– chgrp Group-name game

owner group public

chmod 761 game


アクセス制御

• ファイル等の資源に対する操作を適切に制限（保護）

– 制御の対象となるファイル操作：

• 読出し(R)，書込み(W)，実行(X)，追加，削除

• ドメイン：保護の対象とそれに対する権限の組の集合

• 制御手法

– アクセス制御行列

– アクセス制御リスト

– ケーパビリティ

– ユーザをクラスに分類

保護ドメインの例

ドメイン1

ドメイン2 ドメイン3


ファイル6 [RWX]プリンタ2 [W]

ファイル1 [R]ファイル2 [RW]

ファイル3 [R]ファイル4 [RWX]ファイル5 [RW]

プリンタ1

[W]

アクセス制御行列

• ドメイン毎に各資源にどの操作を許可するか

– ユーザ毎に各ファイルにどの操作を許可するか

• アクセス制御行列の要素aij (ドメインi、資源j)

– アクセス許可なら１，制限なら０

– ユーザのファイル操作要求時に行列を検索

• ファイル保護エラー (Permission denied）

– 行列が大きくなる, 殆ど0の疎行列

ファイル1 ファイル2 ファイル3 ファイル4 ファイル5 ファイル6 プリンタ1 プリンタ2

ドメイン1 読み読み, 書き

ドメイン2 読み読み, 書き, 実行読み, 書き書き

ドメイン3読み, 書き, 実行書き書き




プリンタ1

[W]


アクセス制御リスト

• ACL: access control list

• それぞれの資源毎に

– 許可するドメインと操作の組だけをリストにして保存

ファイル1: （D1, R）ファイル2: （D1, RW）ファイル3: （D2, R）ファイル4: （D2, RWX）ファイル5: （D2, RW）ファイル6: （D3，RWX）プリンタ1 : （D2，W），（D3,W）プリンタ2 : （D3, W）

•ドメイン：ユーザ，グループの組

• ＊は任意（any）

ファイル1: (John, *, RW-)

ファイル2: (*, admin, R--)

ファイル3: (MIke staff, RWX)

ファイル4: (John, *, ---), (*, staff, R--)

user group File 1 File 2 FIle 3 File 4

Johnadmin RW- R-- --- ---

staff RW- --- --- ---

Mikeadmin --- R-- --- ---

staff --- --- RWX R--





プリンタ1

[W]

ケーパビリティ

• capability

• ドメイン毎に権限の集合を保持

– OSが不正改竄に対して保護




プリンタ1

[W]

型権限対象

ファイル R-- ファイル1へのポインタ

ファイル RW- ファイル2へのポインタ

型権限対象

ファイル R-- ファイル3へのポインタ

ファイル RWX ファイル4へのポインタ

ファイル RW- ファイル5へのポインタ

プリンタ -W- プリンタ1へのポインタ

型権限対象

ファイル RWX ファイル3へのポインタ



ドメイン1

ドメイン2

ドメイン3

プロセスに適切なケーパビリティを付与


ユーザクラスによる方法

• アクセスを許可・制限する対象の分類

– 所有者（owner）

• ファイルを作成したユーザ

– グループ

• 特定のユーザ群

– 任意のユーザ

• ファイルごとに各ユーザクラスに対してアクセス許可・制限の情報を保持


UNIXのファイル保護• ファイルごとにrwxrwxrwxの9bitの情報

userA% mkdir foo; touch foo/bar

userA% ls -ld foo foo/bar

drwxr-xr-x 3 userA groupA 102 Feb 7 13:57 foo

-rw-r--r-- 1 userA groupA 0 Feb 7 13:57 foo/bar

userA% chmod o-r foo

userA% ls -ld foo

drwxr-x--x 3 userA groupA 102 Feb 7 13:57 foo

guest% groups

guest

guest% ls ~userA/foo

ls: /home/userA/foo/: Permission denied ; ディレクトリファイルの表示は不可

guest% cd ~userA/foo ; cdは許される（ディレクトリのxの意味）

guest% ls

ls: .: Permission denied

% ls -l bar

-rw-r--r-- 1 userA groupA 0 Feb 7 13:57 bar ; ファイルの情報は許される


2018/6/25 43

ファイルシステムのマウント


例：• CD-ROMをマウント• USBメモリをマウント• VMからホストマシンのディスクをマウント

2018/6/25 44

ファイル共有

• 複数の人によるファイル共有

• プロテクションがキーポイント

• ネットワーク上でのファイルを共有するためのシステ– =分散ファイルシステム

– LANでは• User-IDが一元管理されていることを想定

• UNIX系: Network File System (NFS)

– WANでは• User-IDは一元管理できない

• AFS：サーバ毎に管理、トークン（期限付き）を発行


2018/6/25 45

ファイルシステムの構造

• ファイル構造

– Logical storage unit

– Collection of related information

• ファイルシステムは２次記憶に存在

• ファイルシステムはレイヤ構造

• File control block :ファイルに関する情報が格納


2018/6/25 46

Layered File System


2018/6/25 47

メモリ上でのファイルシステム構造


2018/6/25 48

Virtual File Systems

• Virtual File Systems (VFS) はさまざまなファイルシステムを実装するための仮想的なもの

– オブジェクト指向言語における仮想クラス

• VFSは統一システムコールインターフェイス（API)を提供

struct file_io {

int (*file_open)(…);

int (*file_close)(…);

int (*file_read)(…);

int (*file_write)(…);

int (*file_lseek)(…);

};


2018/6/25 49

Virtual File Systemの仕組み概略

struct file_io {int (*file_open)(…);

int (*file_close)(…);

int (*file_read)(…);

int (*file_write)(…);

int (*file_lseek)(…);

};

#define UNIX_FILESYSTEM 0

#define DOS_FILESYSTEM 1

#define NET_FILESYSTEM 2

extern struct file_io *getFilesystemOp(int);

struct file_io *fop;

fop = getFilesystemOp(UNIX_FILESYSTEM);

fop->file_open(…);

fop->file_read(…);

….

fop->file_close(…);

extern int unix_file_open(…);

extern int unix_file_close(…);

….

struct file_io fio_table[3] = {

{ unix_file_open, unix_file_close, unix_file_read,

unix_file_write, unix_file_lseek },

{ dos_file_open, dos_file_close, dos_file_read,

dos_file_write, dos_file_lseek },

{ net_file_open, net_file_close, net_file_read,

net_file_write, net_file_lseek }

};

struct file_io *getFilesystemOp(int type)

{

return &fio_table[type];

}

インターフェイス定義


2018/6/25 50

ディレクトリの実装方法

• データブロックへのポインタを保持したファイル名の線形リスト– シンプルな実装

– 実行に時間がかかる可能性

• ハッシュテーブル– ハッシュデータの線形リスト

– ディレクトリ探索の時間コスト軽減

– 衝突：2つのファイルの名前のハッシュが同じ可能性

– サイズを変更しやすい


2018/6/25 51

割り当て手法

• ファイルを保存するためにディスクブロックをどのように割り当てるか

– 連続割り当て

– リンク割り当て

– インデックス割り当て


2018/6/25 52

連続割り当て法

• ファイルはディスク上の連続ブロックを使用

– 実装は簡単

• スタートブロックとブロック長だけ

– ランダムアクセスが容易


2018/6/25 53

連続割り当て法• デメリット

– 無駄な空き領域問題

– ファイルを大きくできない（再割り当てが必要）

• 解決法

• Extentと呼ばれる領域にディスクブロックを割り当て

• ファイルを大きくする回数はextentの数に依存

– 複数のextentを保持


補足


• 2次記憶上の連続領域に割り付け

• ディレクトリの管理情報

– ファイルの先頭ブロック番号，ブロック数

• 物理的に連続して格納されるため，逐次アクセスの場合は高速

• ディレクトリの管理が簡単

• ファイル削除による空き領域

• 再利用できない可能性あり

• 断片化

• コンパクション

ファイル名先頭ブロック番号

ブロック数

F1 1 4

F2 8 3

F3 12 4

ディレクトリ

0 1 2 3 4 5

6 7 8 9 10 11

12 13 14 15 16 17

ディスクブロック

2018/6/25 55

リンクによる割り当て法

• ディスクブロックのリンクドリスト

– 簡単

• スタートのアドレスだけ管理

– 空き領域の管理も簡単

– ランダムアクセスに不向き

– Mapping

pointer

Data

block =


補足


• ファイル⇒ブロックのリスト

– ブロック中に次ブロック番号を付与

• ディレクトリエントリ‥先頭／最終ブロック番号

• 書き込み：秋ブロックに行い，ファイルの最後に連結

• 読み出し：ブロック番号をたどり主記憶に転送

ファイル名先頭ブロック番号最終ブロック番号

F1 1 6

F2 2 8

F3 5 16

ディレクトリ

0 1 2 3 4 5

6 7 8 9 10 11

12 13 14 15 16 17


• 空き領域の断片化

• 次ブロックの番号の領域が必要

• この領域が破壊されると，ファイルの回復が困難

• ファイルの途中をアクセスする場合でも先頭からたどる必要

• 逐次ファイルに適

2018/6/25 57

インデックスにより割り当て法

• 全てのディスクブロックへのポインターをindex blockに集中

• インデックステーブルが必要

• ランダムアクセスは楽

• インデックスブロックが必要

• ブロックサイズが512KBの時、それよりも小さいサイズのファイルでも、インデックスブロックが必要

index table


2018/6/25 58

インデックスにより割り当て法• 全てのディスクブロックへのポインターをindex blockに集中– インデックステーブルが必要

– ランダムアクセスは楽

– ブロックサイズが512KBの時、それよりも小さいサイズのファイルでも、インデックスブロックが必要となる

– インデックスブロックが必要

index table


2018/6/25 59

インデックスによる割り当て法

outer-index

index table file


補足


• 「次のブロックの番号」を，1つのブロックに

– 索引ブロック（index block）‥ファイル毎に用意

• ディレクトリには，索引ブロックの番号を格納

ファイル名先頭ブロック番号

F1 0

F2 5

F3 12

ディレクトリ

0 1 2 3 4 5

6 7 8 9 10 11

12 13 14 15 16 17

• 索引のための余分な領域が必要

• 一つの索引ブロックに収まらない場合

• 索引ブロックのリンク割付け

• 多段の索引ブロック

• ランダムアクセスに適


1 3

4 68 10

16

2 7

13 17

2018/6/25 61

UNIX系の場合 (4K bytes per block)



UNIXのiノード

• s5fs (SysV), FFS(BSD) ⇒ ufs

– index node; i-node

iノード

保護モード

所有者 (2)

ファイルの種類、他

参照カウント

タイムスタンプ

ファイルサイズ

直接ブロック

直接ブロック

間接

二重間接

三重間接

直接ブロック

(固定長)

SysVとFFSではディスク上のレイアウトに差あり

HDDの構造をみた配置による高速化

HDDの構造に伴い除去


UNIXのiノード

• １つのiノードで１つのファイル

– ファイル名は含まず

• 長い名前，複数の名前を持つことが可能

– 同じiノードを共有することも可能

• 直接ブロック: 12エントリ，ブロックサイズ＝8KB

– 8KB×12=96KB (192KB) まで直接参照

• 間接ブロック: 2048エントリ (8byte block pointer)

– 8KB×2048=16MBまで間接参照

• 二重間接: 2048^2エントリ 8KB×2048^2=32GB

• 三重間接: 2048^3エントリ 8KB×2048^3=64TB ⇒ 16TB


UNIXファイルシステムの構造

iノード空間iノードはインデックスで指定（iノード番号）

データブロックファイルの実体i-node中のブロックポインタから指される

ファイルシステムの基本情報ブロック数、最大ファイル数、空きブロックリスト情報

OSの起動に必要なプログラムboot block

superblock

i-node space

data blocks

copy of

superblock

i-node space

data blocks

cylinder group

status

boot block

copy of

superblock

i-node space

data blocks

cylinder group

status

・・・

シリンダブロック元はffsでのデータ配置単位ブロックグループとして機能

supserblockのコピーは一つだけ


UNIXディレクトリの構造

• 通常のファイルと同様

– iノードで管理されるファイル

• ディレクトリエントリの表

– iノード番号, ファイル名, 文字数

– エントリはソートなし

• 表を拡張するときは，普通のファイルと同じ方法

– 大きなディレクトリも自由に作成可能


• ファイル名 /usr/bin/ls

• まずルートディレクトリ（/）のiノードを取得

– / のiノード番号は２と定義

UNIXのファイル名lookup

iノード#2

drwx...

ディレクトリファイル（データブロック）

iノード#5

2 .

2 ..

5 usr

4 home

:

5 .

2 ..

7 bin

9 lib

:

drwx...

iノード#7

7 .

5 ..

18 ls

11 ps

:

drwx...


UNIXファイルシステムの利用

• 各ディスクのファイルシステムの根は/

– 複数のディスクの統合が必要 ⇒ マウント(mount)

– ファイルシステムの木の一つのディレクトリに他のディレクトリの根を接続（乗せる）

/

hirotsu

/

usrbin lib home

/

localbin lib

bin lib

/

usrbin lib home

hirotsulocalbin lib

bin lib

% df


iノードの情報の表示

% ls -ldi /

2 drwxr-xr-x 22 root root 4096 1月 12 04:10 /

% touch a; ln a b; ls -li a b

1081349 -rw-r--r-- 2 guest guest 0 1月 12 23:38 a

1081349 -rw-r--r-- 2 guest guest 0 1月 12 23:38 b

% rm b; ls -li a

1081349 -rw-r--r-- 1 guest guest 0 1月 12 23:38 a

% cat > c

0^D

% ls -l c

-rw-r--r-- 1 guest guest 2 1月 13 00:10 c

% ls -s c

4 c


iノードとファイル記述子

• ファイルアクセス時にはカーネル内にiノードのコピー

– 以降のiノードへの操作はメモリ上のiノードに対して

• システムのオープンファイルテーブルのエントリ

– メモリ上のiノードへのポインタ

– ファイル操作に必要な情報 (現在のファイル読込み位置等)

• 各プロセスにはファイル記述子テーブル

– 各エントリはオープンファイルテーブルを指定

– open() は記述子テーブルのインデックス(整数)を返却

• この値はファイル記述子

• 0:stdin, 1:stdout, 2:stderr はdefaultで開放済み


OSにおける入出力の抽象化

• UNIXにおけるI/Oの抽象化

– ファイル（バイトストリーム）

– ファイル記述子 (file descriptor)

» プロセス内のI/Oのインデックス

– OS内部ではバッファ等の資源を割り当て

kernel

user space

bufferfileprocess

file descriptor

process

file descriptor


UNIXファイル関連システムコール

• int open(const char *pathname, int flags);

int open(const char *pathname, int flags, mode_t mode);

– ファイルをオープンしファイル記述子を返却（エラーなら-1）

– flags

- O_RDONLY, O_WRONLY, O_RDWRのいずれか．

- 更に以下をO可能

‣ O_CREATE: ファイルが存在しなければ作成

‣ O_APPEND: 追加モードでオープン, etc.

– mode

- ファイルのモードを指定．

- あらかじめ定義されたシンボル定数を用いるか0644等と指定



• int close(int fd);

– ファイルをクローズ

• off_t lseek(int fd, off_t offset, int whence);

– ファイル記述子fdのオフセットをoffsetの位置へ変更

– whence：オフセットの設定方法

‣ SEEK_SET： offsetバイトに設定

‣ SEEK_CUR：現在位置＋offsetバイトに設定

‣ SEEK_END：ファイルのサイズ＋offsetバイトに設定



• ssize_t read(int fd, void *buf, size_t count);

– ファイル記述子fdからの読み込み

‣ 最大countバイトをbufで指されたバッファに

– 読み込んだバイト数を返却（０：ファイルの終わり）

‣ ファイル位置はこの数だけ進み，エラーなら-1

• ssize_t write(int fd, const void *buf, size_t count);

– ファイル記述子fdへの書き出し

‣ バッファbufから最大countバイトまで

➡その他のシステムコール

– mkdir(), chmod(), etc.


C言語:標準ファイル関連ライブラリ関数

• ファイル入出力をストリームとして利用可能

– システムコールではnバイトのバッファ単位

– ファイル記述子→ ファイル構造体へのポインタ(FILE *)

• 0, 1, 2→stdin, stdout, stderr

• fopen, fclose, fseek, fread, fwrite

– open, close, lseek, read, writeに対応 (ストリームI/O)

• 他にfprintf, fputs, fputc, fgets, fgetc等

– 頭にfがつかないものは、stdin/stdoutが対象

• e.g. printf(…)＝fprintf(stdout, …)

– これらはシステムコールを使って実装

– ストリームで足りる場合はストリームI/Oを使うべき


C言語:標準ファイル関連ライブラリ関数

• ストリーム：直観的にはファイル記述子＋バッファ

– バッファが一杯/空になったらwrite/readを呼び出し

– ただし，stdoutは行単位でバッファリング

• つまり改行かstdinからの入力があるまでバッファリング

• stderrはバッファリングなし

• バッファとバッファリングの変更… setbuf(), setvbuf()

• FILE *fdopen(int fd, const char *mode)

– ファイル記述子fdからストリームを作成

• int fflush(FILE *stream);

– バッファの内容を強制的に書き出し


#include <stdio.h>

int

main(int argc, char* argv[])

{

FILE *fp;

fp = fopen("aaa", "w");

fseek(fp, 100*1024, SEEK_SET);

fprintf(fp, "aaa¥n");

fclose(fp);

}

シークについて

% gcc a.c; ./a.out

% ls -l aaa

-rw-r--r-- 1 guest lab 102404 Feb 14 13:35 aaa

% ls -s aaa

6 aaa

100KB+4byteのファイルに対して、実サイズは6KB


性能を上げるためのキャッシュ


メモリ上の情報とディスク内容


ファイルのtruncateを想定

インデックステーブル

フリービットマップ

000000000

ブロック 10

ブロック 20

ブロック 33

ブロック 8

0

2つの情報がディスクに書かれる前にマシンがクラッシュするとファイルシステムはInconsistencyに

インデックステーブル

フリービットマップ

000000100

ブロック 10

ブロック 20

0

ブロック 8

0

2018/6/25 79

Recovery

• 一貫性（Consistency）のチェック– ディレクトリ構造内のデータとディスク上のデータを比較し，誤りがあれば修正

• 他ストレージにバックアップをとるプログラムを使用

• バックアップから消えたファイルを復元


2018/6/25 80

Log Structured File Systems

• ログ構造（ジャーナリング）ファイルシステム– ファイルシステム適用されるアップデートをトランザクションとして記録

• すべてのトランザクションはまずログに記録

• コミット（された）

– トランザクションがログに反映されること

• コミットされてもファイルシステム自体はまだアップデートされていないかもしれない？


log (or journal)

Block

X

Block

Y

Block

Z

Block

X

Block

Y

Block

Z

Block X

Block Y

Block Z

2018/6/25 81

Log Structured File Systems

• トランザクションは非同期的にファイルシステムに反映– ファイルシステムが更新されたときにトランザクションはログから削除

• ファイルシステムがクラッシュしたときでも，ログ中にあるトランザクションはすべて実行される必要あり


2018/6/25 82

プロテクション

• プロテクション問題とは？

• プロテクションドメイン

• Access Matrix

• Capability-Based Systems


Documents

オペレーティングシステム - PFLab講義スケジュール（予定） 2018/6/25 第11回 オペレーティングシステム 3 1. OSの概要（4/9） 2. プロセス管理（4/16）

オペレーティングシステム - PFLab講義スケジュール（予定） 2018/6/25 第11回オペレーティングシステム 3 1. OSの概要（4/9） 2. プロセス管理（4/16）