UN Ⅸへの招待 # cd /usr/sys/conf # cp GENERIC SNOOPY # vi SNOOPY ←コンフィキュレーション・ファイルの編集 # mkdir /usr/sys/SNOOPY # /etc/config SNOOPY # cd /usr/sys/SNOOPY # make depend # make # mv /vmunix /vmunix. 01d cp vmunix /vmunix このあと、新たに作成したカーネルを立ち上げるため、 りますにれがシンポリックリンクが提供されるにいたっ ドがそれぞれのファイルシステムに存在していることにな ステム内で一意ですから、同し i ノード番号をもつ i ノー i ノード番号と呼びます。 i ノード番号は 1 つのファイルシ システム内で一意な番号がふられています。この番号を、 システムを作ったときにたくさん用意され、そのファイル 割り当てられることになっています。 i ノードは、ファイル よう。 UNIX では、 1 つのファイルには 1 つの i ノードが めの機能です。ここでは、その仕組みを簡単に説明しまし ル名を使って同しファイルにアクセスできるようにするた 前号でもすこし触れましたが、リンクとは異なるファイ クも可能です。 リのリンクも、異なるファイルシステムのファイルのリン もできません。一方シンポリックリンクでは、ディレクト 中のファイルをほかのファイルシステムにリンクすること トリのリンクはおこなえませんし、あるファイルシステム ァイルしかリンクできません。ハードリンクではディレク ードリンクでは、同しファイルシステム内の通常のフ 呼ぶ ) の 2 種類があります。 ードリンクとシンポリックリンク ( 、、ソフトリンク〃とも リンクについて説明します。リンクには、前号で紹介した リックリンクされています。ここでは、そのシンポリック さて、さきほど述べたように /sys は /usr/sys にシンポ シンポリックリンク ちんと読み、その記述にしたがって操作をおこなってくだ ネルを構築する場合には、提供されているマニュアルをき 個々にさまざまな改良を施しているようです。実際にカー 以上の操作については、 UNIX マシンの各メーカーが システムをリプートします。 158 た重要なポイントです ) 。 さて、ファイルを作ったディレクトリには、ファイル名 とそのファイルに割り当てられた i ノード番号のペアが登 録されています。 i ノードには、ファイルの種類、ファイル の保護モード、ファイルの所有者 / グルーフ。所有者、ファイ ルの時刻情報、ファイルの実体が格納されているディスク 上のプロックのアドレスなどの情報が収められています。 ューサーがあるファイル名を指定すると、カーネルはディ レクトリのなかからそのファイル名を検出し、ファイル名 とべアになっている i ノード番号をもとに、そのファイル に割り当てられた i ノードをアクセスします。 i ノードには ディスク上のプロックアドレスが入っていますから、その 情報をもとに実際のファイルの内容がアクセスされるわけ さて、 A というファイルを B というファイルにハー ンクしたとしましよう。 A には、 i ノード番号 10 の i ノー ドが割り当てられているとします。すると以下に示すよう に、 B が登録されたディレクトリには、 B という名前と A と同し i ノード番号の 10 番のペアが登録されます。 この結果、 A という名前でアクセスしても B という名前 でアクセスしても、いすれも i ノード番号 10 番の i ノード がアクセスされることになり、同しファイルの実体にいき つくことになるわけです。これが、ハードリンクです。ハ ードリンクで異なったファイルシステムのファイルをリン クできない理由は、こにあるのです。ファイルシステム には、それぞれ一意な i ノード番号をもつ i ノードが存在 していますが、ファイルシステムが異なれば、それは一意 なものとはいえなくなってしまいます。というのは、ファ イルシステム / usr にもファイルシステム / tmp にも 10 と いう番号の i ノードが存在しているからです。 10 B UNIX MAGAZINE 1991.6

int int char * Char * int int int short int int int char * dev_t off_t char struct struct struct daddr_t blkaddr = 0 ; dfd dfpath fiename fsfd 1 level = NULL , logblksiz = 0 ; ofd ofpath ofsdev tnw / * プロックアドレス * / / * int character * / / * del ファイル記述子 * / = Ⅱ . L ; / * del ファイルのノくス名 * / ・ / * undelete するファイル * / / * ファイルシステムのファイル記述子 * / / * ループインデックス * / / * 間接レベル * / / * 論理プロックサイズ * / / * 読み取られた文字数 * / / * 書き込まれた文字数 * / / * 出力ファイル記述子 * / = NULL; / * 出力ファイルのパス名 * / / * 出力ファイルのシステムデハ・イス id * / / * 書き込まれた / シークされた合計文字数 * / fspathCPAN_MAX + 1 ; / * ファイルシステムのデパイスパス名 * / / * 削除されたファイル・レコード * / delfil 矼 ; / * スーノく filsys fs; ープロック * / / * 出力ファイルのステータス * / stat st ; / * コマンド行オプションと引数の処理 * / -argc; + + argv ; if (argc く 1 ) { / * ファイル名 * / fputs(USAGE, stderr) ; exit(EXIT_FAII. URE) ; filename = *argv; -argc; + + argv ; if (argc } else { / * 出力ファイルのノくス名 * / ーの { ofpath = NULL ・ ofpath = *argv; ¯argc; + + argv ; if (argc ! = の { fputs (USAGE , stderr) ; exit(EXIT_FAILURE) ; / * 削除されたファイルのパス名の取得 * / dfpath = getdfpath ( ) ; if (dfpath = NULL) { fputs(PROGNAME い $ HO ト旧 e Ⅱ V1 て 01 皿 e Ⅱ t variable not set. \Ⅱ" / * 削除されたファイルの探索 * / exit (EXIT_FAILURE) ; perror("opening del file") ; fprintf ( stderr , "DeIeted file %s not found. \n't if (errno = 盟 0 T ) { if (dfd = dfd = open(dfpath, O_RDONLY) ; / * 削除されたファイルのオープン * / exit (EXIT_FAILURE) ; stderr) ; nr = read(dfd, & 矼 , sizeof(df)) ; if ( 皿 = perror("readlng deleted record file") ; exit(EXIT_FAILURE) ; if ( 皿く sizeof(df)) { fprintf(stderr, "De1eted file %s not found. \n't , filename) ; exit (EXIT_FAILURE) ; (strncmp(df. filename , filename, sizeof(df. filename)) break ; if 116 / * 出力ファイルのオープン * / close(dfd) ; / * 削除されたファイルのクローズ * / filename) ; UNIX MAGAZINE 1991.6

単独のフリープロックがすべて記されていなければならな い。しかしスーパープロックは明らかに、ファイルシステ ム内のすべてのフリープロックのアドレスを保持できな い (NICFREE は通常 50 程度にすぎない ) 。フリーリスト に十分な容量を与えるには、リンクプロックと呼ばれるフ リー・データブロックにチェインされなければならない。 s ー free がいつばいのときにフリーになるプロックは、リン クプロックになる。 s ー free の内容は新しいリンクプロック の先頭に移され、 s-free を空にし、リンクプロックのアド レスが s ー free の最初の要素に置かれる。リンクプロック がない場合には、 s-freeC0] は 0 である。 フリーリストの代わりに、ビットマップをプロック割当 ての追跡に使用することもできる。この方法は、ファイル システムの一部 ( 通常は、 i ノードリストとデータブロック のあいだ ) をビットマップのために必要とする。記憶領域の オーバーヘッドは重要ではない ( 1 プロックにつき 1 ピッ トにすぎない ) 。しかし、プロックが割り当てられるときの ビットマップ・サーチにかかるオーバーヘッドは、あっさ り見過ごすわけにはいかない。問題は、フリープロック・ アドレスを i ノードの場合と同様にキャッシュすることに よって解決される。 ロ ファイルシステムへの直接アクセス デバイスは、 open 、 read 、 lseek などを用いて、通常の ファイルと同様にアクセスされる。ファイルシステムに直 接アクセスするには、デバイス・スペシャルファイル名が 必要である。共通デバイスの命名には厳格な規則が適用さ れる。 通常、ファイルシステムは固定されたディスク・パーテ イションに格納され、 c / の s んの形式のファイル名がえ られる ( / はコントローラ番号、ゾはコントローラ上のドラ イプ番号、んはドライプ上のパーティション番号 ) 。これら はすべて、 0 から始まる 1 桁の小文字の 16 進数である。コ ントローラ 0 のドライプ 0 である c0d はなくなり、 0s 々の 形式の名前が残っている。パーティション番号 0 は物理デ イスク全体を表す。これより、ルート・ファイルシステム のためのデバイス・スペシャルファイルは 0S1 になる。 ディスクデバイスには、プロック・スペシャルファイル とキャラクタ・スペシャルファイルがある。両者は同し名 UNIX MAGAZINE 1991.6 UNIX ファイルの復元■ 前だが、 / dev 下の別々のサプディレクトリに置かれる。プ ロック・スペシャルファイルは / dev / ホんに格納され、キ ャラクタ・スペシャルファイルは / dev / S んに格納され る。キャラクタ・デバイスドライバは raw デバイスドライ バとも呼ばれる。これは、キャラクタ・テンヾイスドライバ がバッファリングされていないためである。そこで、ディ レクトリ名が r 赤々なのである。 キャラクタ・テンヾイスドライバはバッファリングされて いないので、読取りと書込みは全プロックに対しておこな われなければならない。一方、プロック・テンヾイスドライ バはデータのバッファリングをおこなうので、プロセスが 一部のプロックにアクセスすることができる。また、対応 するキャラクタ・スペシャルファイルとプロック・スペシ ャルファイルは同しデバイスに結びつけられるので、どち らも同しメジャーデバイス番号とマイナーデバイス番号を もっことになる。 指定されたファイル・ディレクトリをそのファイルシス テムから読み取るには、ファイルシステムのデバイスファ イル名がなんらかの方法で得られなけれはならない。 stat システムコールは、ファイルシステムのデバイス id を提 供するので第 1 段階としてはよい。しかし、いかにしてこ れからファイル名を導くかがはっきりしない。この答は、 固定ディスクのマイナーデバイス番号がどのように作成さ れているかということにある。 SystemV/386 では、マイ ナーデバイス番号のピット 0 ~ 3 にパーティション番号が、 ピット 4 ~ 5 にドライプ番号が、そしてピット 6 ~ 7 にコ ントローラ番号が含まれている。ほかのシステムの方法も 似通っているが、これは明らかに可搬性がいちしるしく低 いと考えられる。このためデバイス id とファイル名の変換 は、次ページのリスト 1 に示した関数 devtonam および namtodev のなかにまとめられている。 前述したように、 bat はファイルシステムから i ノード を直接読み取ることによってのみ得られる。リスト 2 ( 113 ページ ) に getdinode 関数を示す。これは、 ここに小した 原理と技法を用いて、ファイルのパス名だけが与えられた マウント中のファイルシステムからディスク i ノードを読 み取るのに使う。このために getdinode 関数は、 statfs を 用いて論理プロックサイズを、 stat を用いてデバイス id と i ノード番号を取得し、 devtonam を用いてデバイス id をデバイスファイル名に変換する。 i ノードはプロックの 111

pluto% ls ー 1 total 349 306023 Feb 28 14 : 13 data3—50 1 baba 37862 Mar 1 11 : 29 device . tex 1 baba pluto% compress data3-50 device. tex pluto% ls ー 1 t ot al 98 80289 Feb 28 14 : 13 data3-50. Z 1 baba 19347 Mar 1 11 : 29 device . tex . Z 1 baba pluto% uncompress data3—50 device. tex pluto% ls ー 1 total 349 pluto% の 2 つがあります。ソフトリミットを超えるとメッセージ 圧縮されたファイルは、 xxxxxx. Z というファイル名 が表示され、そのまま使い続けてハードリミットを超える になります。圧縮されると、ファイルの大きさはファイル と、それ以上使えなくなってしまいます。そのような場合 ( データ ) の種類にもよりますが、 1 / 2 ~ 1 / 4 程度になりま には、不要なファイルを消去してソフトリミット以下に使 す。 用量を減らすしかありません。 これでディスクの空き領域がだいぶ大きくなったはすで 通常、 /etc/rc. local ( または /etc/rc) で /etc/quota- すが、これでも駄目なら思いきってあまり使わなくなった check 、 /etc/quotaon を実行するように設定します。どの 人のホームディレクトリを削除するという方法もあります。 次にファイルシステムが溢れないように、予防策として ファイルシステムでクオータシステムを使うかは、マウン ト時に参照する /etc/fstab にオプションで指定しておけ クオータシステムの利用を考えます。これは、ユーサーも は OK です。ただし、アンマウントすると自動的に / etc / しくはファイルシステムごとにファイルの使用領域を制限 q Ⅱ otaoff が実行されますから、ふたたびマウントすると して管理することができます。制限には、 きには明示的に / etc / quotaon を実行しなけれはなりま 1 ) ソフトリミ せん。各ューサーに対する制限は、 /etc/edquota で決定で きます。 これらのファイルはふつう、、ゴミファイル〃として扱われ、 ファイルに * ~ や # * などの名前はつけない 放っておくと溜まる一方なので定期的に整理しなけれはなり ません。これは、本文中でも紹介しているように cron などを 皆さんは、どのエデイタを使っていますか ? 「私は絶対 使えは自分の手を煩わすことなく整理することができます。 vi! 」とか「いやいや、やつはり emacs やで」など、いろい そのようなときに、大事なファイルに * ~ や # * などの名前を ろな声が聞こえてきそうですが、たいていのエデイタには不 つけておくといつの間にかなくなってしまい、取り返しのつ 慮の事故に備えてバックアップのための機能がサポートさ かないことになってしまいます。 れています。たとえば emacs の場合、 f00 というファイルを このような理山から、ファイル名に * ~ や # * などの名前を 編集しているとき、 auto ー save 機能を使っていれば # f00 # つけるのは避けたほうが賢明です。 UNIX に慣れてくると、 というファイルがバックアップ用に作られますし、ファイル 工デイタなどがこういった名前のファイルをバックアップ用 をセープすると編集前のファイルを残すために # f 。。 # が消 に作っておくことが分かってきますが、使い始めのうちは「そ されて f00 というファイルが作られます。 うか、皆はもとのファイルを残すとき、ファイル名の後ろに またメールで mh システムを使っているとき、メールを削 ~ をつけるんやな」などと勘違いしかねません。あなたの周 除する rmm コマンドなどは、デフォルトではメールを実際 りに、こうしたことを知らない人がいたら教えてあげましょ に削除するのではなく、ファイル名の先頭に , ( カンマ ) をつ けるようになっています。 306023 Feb 28 14 : 13 data3-50 37862 Mar 1 11 : 29 device . tex 1 baba 1 baba 44 UNIX MAGAZINE 1991.6

こうしておけば、各ューザーの使用可能領域をファイル システムの使用可能領域以上にするといった間抜けな割 当てをしないかぎり、ホームのファイルシステムが溢れる ことはほばなくなります。しかし、ユーザーからの文句は 多くなるかもしれません : ー ( どうしようもなくなったら、 物理的に解決 ( ディスクを増設 ) するしかないでしよう。 次に、ファイルシステムの検査の話に移りましよう。 「電源を切るときの注意」の項でお話ししたように、 UNIX では、ディスク上のファイル情報を更新するたびに いちいちディスクに書き出すのではなく、ディスク上のフ ァイル情報をいったんメモリ ( カーネル内 ) に取り込んで メモリ内で情報を更新し、定期的にディスクへ書き出す ( sync ) という方法をとっています。それにより、ディスク アクセス回数を減らして高速化を図っているのです。した がって、ディスク上のファイル情報とメモリ上のファイル 情報がつねに一致しているとはかぎりません。ですから、 突然停電した場合などは、ディスク上のファイル情報とカ ーネル内のファイル情報とが異なっていることがありま 第 * * Phase 5 ー Check Cy1 groups * * Phase 4 ー Check Reference Counts * * Phase 3 ー Check * * Phase 2 ー Check Pathnames * * Phase 1 ー Check B10cks 田 id Sizes * * Last Mounted 0 Ⅱ /mnt4 * * /dev/rhd2b mars# fsck /mnt4 Connectivity UNIX MAGAZINE 1991.6 ル名にした形で登録されます。このヾ迷子〃ファイルは、 わった名前のディレクトリの下に、 i ノード番号をファイ ムのルートの部分にある lost 十 found というちょっと変 レクトリが分からなくなりますから、そのファイルシステ とがあります。そのようなファイルは、ファイル名やディ ルシステムのなかのどのディレクトリにも見つからないこ fsck を実行した結果、あるファイルの i ノードがファイ が高速です。 のどちらでも指定できます。ただし、 raw デバイスのほう デバイスファイル名は、プロックデバイスと raw デバイス のようにデバイスファイル名を指定してもかまいません。 mars# fsck /dev/rhd2b ファイルシステムを指定するのではなく、 mars# 322 files , 14837 used , 16630 free ( 326 frags , ースーバーユーサーへの道 2 、、、す。そのようなときには、ファイルシステムの一貫性を保 っための作業が必要になります。そのためのコマンドが /etc/fsck です。 fsck は、さまざまな面からファイルシステムの整合性 をチェックし、矛盾があると自動的 ( あるいは対話式 ) に修 復してくれます。 fsck の実行は、シングルューザー・モー ドでかつアンマウントしておこなわなければなりません。 これは、次のように使います。 fsck ファイルシステム fsck -p ファイルシステム fsck ー y ( または一 n ) ファイルシステム ファイルシステムは省略可能で、その場合には / etc / fstab に書かれているすべてのファイルシステムが調査の 対象になります。 fsck は対話式に実行されますが、 -p オプ ションをつけると自動的に判断され、一 y ( ー n ) オプション をつけるとすべての質問に yes ( no ) と答えて進んでいき ます。さっそく、ファイルシステム Vmnt4" をチェック してみましよう。 45 きるのですが、ディスクが壊れるとそれまでの作業がパー ら、たいていは部品の交換などではは、もとどおりに修復で 場合と比べて被害が大きく感しられます。はかの部分な 確率が高くなります。ディスクが壊れると、はかの部分の り書いたり、いつも働いていますから、どうしても壊れる 計算機が動いているあいだ、ディスクはデータを読んだ バックアップとは・・・ に作るかどうかを訊ねてきます。 を実行したとき ) に作成されますが、存在しなけれは新た レクトリは新しくファイルシステムを作ったとき (newfs 定しなけれは・なりません。なお、 1 。 st 十 found というディ 所有者や中身を調べてどのようなファイルであったかを特 2038 blocks , 1 . 0 % fragnentation)

fsck は、ディスクのファイルシステムの内容に矛盾がな いかを調査し、矛盾があれはそれを修復します。たとえば、 前述したおかしなリンク数 ( 実際の i ノード参照数よりも 大きいなど ) を検出し、それを直したりします。また、実際 に i ノードは使われているけれども、その i ノード番号が どのディレクトリにも登録されていないなどの問題点も検 出します。 lost 十 found の話に戻りましよう。 lost 十 found は、遺失 物取扱用ディレクトリとして fsck が使用します。 fsck はい実際に使われてはいるが番号がどのディレクトリにも 登録されていない〃 i ノードを検出すると、その i ノード番 号を lost 十 found ディレクトリに登録します。また、ファ イル名を lost 十 found に登録し、あとからユーザーがその ファイルをファイル名で扱えるようにします。しかしこの とき、実際にユーサーがファイルにつけた名前は見つけよ UN Ⅸへの招待⑩ 、ゝうがありません ( ファイル名の情報はディレクトリにしか 置かれないからです ) 。そこで、 fsck は i ノード番号を一部 に使用した仮の名前をファイル名としてつけ、それを lost 十 found ディレクトリに登録します。もし自分のファ イルが lost 十 found に登録されたら、ユーサーは mv コマ ンドを使ってそれを適切なディレクトリに適切な名前で移 動します。 lost 十 found ディレクトリの役割はお分かりいただけた でしようか ? ところで、ツリー構造のなかにはルートディ レクトリの下だけでなく、あちらこちらのディレクトリに lost 十 found ディレクトリが存在します。 lost 十 found デ ィレクトリは、 1 つのファイルシステムに 1 つ存在させて おくからです。たとえは次に示すように、、ルート〃とソ usr 〃 の 2 つのファイルシステムからツリー構造が構築されてい るとしましよう。 % 矼 FiIesystem /dev/sdOc /dev/sdOd kbytes 7655 71551 us ed 6131 59071 avail capacity Mounted on 89 % 758 92 % 5324 この場合は、 / にも /usr にも lost 十 found が存在します。 % ls -dl /lost + found drwxr—xr—x 2 root 8192 Jan 1 1970 /lost + found % ls -dl /usr/lost + found drwxr—xr—x 2 root 4096 J 田 1 1 1970 /usr/lost + found fsck は、ファイルシステムの検査をおこなうコマンドで す。つまり、ルートを起点にしたツリー構造本ではなく ファイルシステムごとに検査をおこないます。ですから fsck が利用する lost 十 found は、それぞれのファイルシス ()d /tmp; find . ! -name ! —name 10St 十 found ! という言当があったのを思い出してください。 fsck にとっ て、 lost 十 found は必須のディレクトリです。このため、あ るパーティションにファイルシステムを作成した段階で自 動的に lost 十 found ディレクトリが作成されるようにな っています。 さて、あるファイルシステムを作成し、それを / tmp にマ ウントして使っていたとします (/tmp に 1 つのファイル システムをマウントして使用するということはよくおこな UNIX MAGAZINE 1991.6 、ゝテムに 1 っすっ存在しているのです。 fsck は、 lost 十 found が存在しないとファイルが宙に浮い ないとそれを作成するように拡張されています ( 以前の けです。もっとも、現在の fsck は、 lost 十 found が存在し 用いたファイルやディレクトリの削除をおこなっているわ found も消えてしまいます。そこで、 / etc / rc では find を レクトリを ()m -rf などで ) 全部消してしまうと、 lost 十 われます ) 。すると、立ち上げ時に / tmp のファイルやディ ーれ e quotas -exec -r { } \ ; ) こで、立ち上げ時のシェルスクリプト / etc / rc のなか たままになってしまいました ) 。 163

そこで、 4.2BSD からはシンポリックリンクの機能が提 供され 8 、ファイルの種類として、、シンポリックリンク〃と いう型が加えられました ( 従来の型としては、 f ( 通常のファ イル ) 、 d ( ディレクトリファイル ) 、 c(rawI/O デバイスフ ァイル ) 、 b ( プロック I/O デバイスファイル ) などがあり % cat 0 this is afo % pwd /usr/ snoopy % 1 -s /usr/snoopy/afo /tmp UN Ⅸへの招待⑩ 、ゝました ) 。 前述したように、シンポリックリンクでは異なるファイ ルシステム間のリンクが可能です。そのためのコマンドは ードリンクと同し ln ですが、オプションとして -s を指 ノ、 定しなければなりません。 % ls ー 1 /tmp lrwxrwxrwx 1 aya % cat /tmp/afo this is afo 15 Apr 15 00 : 23 /tmp/afo ー > /usr/snoopy/afo 、ゝとなります。もちろん、ファイルの型は、シンポリックリ シンポリックリンクの仕組みは、ハードリンクとは異な ります。シンポリックリンクでは、リンク先のファイルが 新たに作成され、その内容がリンク元のファイルのパス名 ンク型になっています。 ls ー 1 で / sys を見てみましよう。 % ls ー 1 /sys lrwxrwxrwx 1 root 8 Jan 1 1970 /sys ー > /usr/sys 先頭 1 文字目に表示されるファイルの型は、 1 となってい ます。これがシンポリック型です。 ls ー 1 のファイル名の部 分では、このファイルが実際にどのファイルをシンポリッ クして作成されたかが表示されます。 UNIX のツリー構造は、かってはきわめて単純なもので した。どこにどのようなファイルが存在しているかは、長 い ( といっても 10 年ほどの ) 歴史のなかであまり変化しま せんでした。ところが最近の UNIX では、機能の増加や NSF などの分散ファイルシステムの提供にともない、フ ァイルやディレクトリの位置も変化しています。しかし従 来からの習慣も残すため、 ( / sys のように ) シンポリックリ ンクをおこなって、あたかも昔からの位置にファイルやデ ィレクトリが存在しているように見せています。たとえは・、 SunOS では /bin が /usr/bin にシンポリックリンクされ ています ( / bin には何もコマンドがなく、かって / bin に存 在していたコマンドはすべて / usr / bin に置かれていま す ) 。また、シンポリックリンクは次号で紹介する / etc な どのディレクトリでも数多く使用されています。 /tmp ルートの下にある tmp ディレクトリの名前は、 tempo- rary を略してつけられました。 / bi 広 / dev 、 / lib などと異 なり、 /tmp には特定のファイルは存在しません。 / tmp は、 一時的に作成するファイルを置くディレクトリとして、い くつかのコマンドに使用されます。 たとえば、ⅵや ex はエデイタの実行中だけ、 / tmp に 8 SystemV では、 Release4 からシンポリックリンクがサポートされています。 UNIX MAGAZINE 1991.6 Ex???? や Rx???? などの一時ファイルを作っています。ま た、 cc は実行中に ctm???? という一時ファイルを /tmp に 作っています。ここで、 ? ? ? 〃と記しているのはそのプロ セスのプロセス識別子です。これらのファイルはコマンド 実行中だけ作成されていますので、コマンドが終了すると なくなります。 では、ⅵを中断して / tmp を覗いてみましよう。 159

UN Ⅸファイルの復元■ リスト 2 getdinode 関数 #include く error. h> #include く limits. 血> #include く fcntl. h> #include く tmistd. 五> #include く sys/types. h> #include く sys/ino. h> #include く sys/stat. h> #include く sys/statfs. h> " /dev/dsk" #def ine FSIEIDIR char * devtonam(dev—t dev) ; / * getdinode: ディスクの i ノードを取得する * / int getdinode (const char *path , struct dinode *d1P) int int fsfd = 0 ; / * ファイルシステムのデノヾイスファイル記述子 * / / * 読み取られた文字数 * / / * ファイルシステムのデハ・イスノくス名 * / fspath[PAn-I_MAX + 1 ] ; chal 、 / * 汎用 i ノード * / struct stat st ; / * 汎用スーノく一プロック * / struct statfs stfs ; / * ファイルシステムの論理プロックサイズの取得 * / if (statfs (path, &stfs , (int)sizeof (stfs) , の return ー 1 ; / * ファイルの i ノード番号とファイルシステムのデハ・イス id を取得 * / if ( stat (path , &st) return ー 1 ; / * ファイルシステムのプロック・スペシャルファイルをオープン * / sizeof(struct dinode) * (st. st-ino ー 1 ) ) , SEEK S€r) if (lseek(fsfd, (long) (stfs. f—bsize * 2 + / * i ノードのシーク * / return ー 1 ; if (fsfd = fsfd = open(fspath, 0 RDONLY) ; sprintf (fspath, "%s/%s" , FSDEVDIR, devtonam(st. st-dev)) ; / * ファイルシステムのプロック・スペシャルファイルをクロ return ー 1 ; if ( 皿 ! = sizeof(*dip)) { 皿 = read(fsfd, (char *)dip, (unsigned)sizeof(*dip) ) ; / * i ノードの読取り * / return ー 1 : close(fsfd) ; return 0 ; 常のオペレーティング・システム・サーピスではそのファ イルシステム上のファイルにアクセスできなくなる。ファ イルシステムのアンマウントは、ファイル復元のような日 常的な操作には実際的ではない。しかし、ディスク・オプ ティマイサなどには向いている。 ロ 削除されたファイルの復元 UNIX ファイルシステム上の削除されたファイルを復 元する方法は 2 つある。 1 つは、ちょうどオペレーティン グ・システムがファイルにアクセスするときと同様に、フ ァイルの bat と間接プロックをたどるものである。もう 1 つは、新しく解放されたプロックのアドレスを見つけるた UNIX MAGAZINE 1991.6 めにフリーリストをスキャンするものである。どちらのア プローチにも長所と矢可斤がある。 bat 方式の短所は、先行操作を必要とすることである。 ディレクトリ・エントリがいったんアンリンク (i ノード番 号フィールドを 0 にセット ) されると、ファイル名とファイ ル本体とのあいだにはもはやなんの関連もなくなる。つま り、ヾそこからここへ持ってこられない〃のである。削除さ れたファイルの位置を見つけるには、ディレクトリ・エン トリがアンリンクされる前に i ノード番号はどこかに保存 されている必要がある。大部分のシステムでは、 bat そのも のを保存しなけれはならない。というのは、解放時にすべ ての i ノードが初期化されてしまうからである。 フリーリスト方式の長所は、 bat が失われてしまったフ 113

IJN Ⅸへの招待⑩ 納されています。前述のとおり、 i ノード番号とは個々の i ノードにつけられた一意な番号です。さて、 1 つのファイ ルには 1 つの i ノードが割り当てられることになっており、 その i ノードにはファイルの所有者、リンク数、時刻情報、 ファイルの内容がディスク上のどのプロックに書き込まれ ているかなどの情報が格納されています。、、リンク数クと は、その i ノードを参照しているファイルの数のことです。 たとえば、ファイル A を B にハードリンクすると、 A に割 り当てられていた i ノードのリンク数は 2 となります。 ファイルシステム内には、このようにファイルが格納さ れています。したがってコマンドなどの引数でファイルを 指定すると、カーネルはディレクトリ内のファイル名から そのファイルに割り当てられている i ノード番号を検出し、 i ノード内の情報からファイルの実体を捜しあてていくわ けです。 今度は、ファイルの作成や削除の際のカーネルの働きを 考えてみます。皆さんがファイルを作成するとき、ごく大 雑把にいうと次のような作業がカーネルによっておこな われます ( カーネル内では、実際にはもっと複雑な操作がお こなわれています ) 。 cl ) ファイルの名前をメモリ上に読み込まれたディレクト リに書き込む。 (2) 未使用の i ノードが、新しいファイル用の i ノードとし て割り当てられる。 i ノードにはファイルの所有者や時 刻などに関する情報が書き込まれるが、それは ( ディス ク上に直接ではなく ) メモリ上でおこなわれる。 c3 ) 割り当てられた i ノードの番号が、メモリ上のディレク トリに書き込まれる。 (4) (2) の i ノードがメモリ上からディスク上へ書き込ま (5) (4) のディレクトリがメモリ上からディスク上へ書き 込まれる。 一方、ファイルを削除すると次のような作業がおこなわ れます。 % grep fsck /etc/rc /etc/fsck -p 162 dl ) 削除するファイルの名前が登録されているディレクト リで、該当ファイルに対する i ノード番号を 0 に設定す る。 (2) i ノード中のリンク数を 1 つ減らす。リンク数が 0 にな れば、その i ノードを未使用の i ノードとする ( さらに、 ファイルが使用していたディスク上のプロックを解放す る ) 。 こで、 UNIX マシンの電源がふいに切られてしまった としましよう。そのとき、不幸にもファイルを作成してお り、カーネルは c4 ) の作業が終ったところだったとします。 すると、ディスク中では使用されていることになっている i ノードの番号は、 c5 ) の作業が終っていないので、ディス ク上のどのディレクトリ中にも含まれないことになってし まいます。したがって、ファイルは作成したのにディスク 中のどのディレクトリにもその名前は登録されていないわ けですから、実際にはそのファイルが扱えなくなってしま います。 一方、電源が切られたとき、ファイルを削除していたと しましよう。カーネルは (l) の作業を終えたところだった とすると、 i ノードは未使用になってません ( 使用中になっ たままです ) 。そこで、ディレクトリから参照されていない i ノードが、使用中となったままになります。また、たとえ 別のディレクトリからその i ノードが参照されていたとし ても、リンク数が減らされていない ( (2) が終っていない ) ので、 i ノード中のリンク数は実際の参照数より 1 つ大き いままになってしまいます。 皆さんも、、、 UNIX ワークステーションの電源はいきな り切ってはいけない〃と聞いたことがあるのではないでし ようか。その理由は、このあたりにあるのです。ふいに電 源を切ると、ディスク中の情報が誤ったものになってしま います。そこで UNIX では、万が一ふいに電源を切った場 合でもディスクの情報を正しく回復できるよう、 fsck とい うコマンドが提供されています。そして、立ち上け時のシ ェルスクリプト / etc / rc では、この fsck コマンドが実行さ れるようになっています。 >/dev/console 2 > & 1 UNIX MAGAZINE 1991.6

い。順を追って見ていくと、 l)cd で /tmp に移り、 2 ) find でカレントディレクトリ ( / tmp ) を起点 0 3 ) それらをすべて rm で削除 からも ) すべて検出し、 ・ quotas ではない ・ lost 十 found ではない . ではない 度と使われませんから、単なるゴミのような存在です。そ こで UNIX では、システムの立ち上げ時に実行されるシ ェルスクリプト / etc / rc で、 / tmp 中のファイルをすべて % grep /tmp /etc/rc ()d /tmp ; /usr/Iib/ex3.7preserve —a) echo clearing /tmp というファイルを再帰的に ( / tmp 以下のディレクトリ IJN Ⅸへの招待① 、ゝ削除するようにしています。つまり、立ち上げるときにお >/dev/console 2 > & 1 その様子を見てみましよう。 掃除をするわけです。 ()d /tmp ; find . ! -name ! —name lost 十 found ! —name quotas —exec rm —r { } \ ; ) grep の実行結果のうち、最後の 1 行に注目してくださ こし、 名前 単に、、 rm -f /tmp" として / tmp ディレクトリに存在し ているファイルだけを消しています ) 。 lost 十 found や quotas を消していない理由については、彳あします。 余談になりますが、 /etc/rc では、、 cd /tmp;/usr/lib /ex3.7preserve -a" というコマンドが実行されています ( 上例を参照 ) 。これはⅵが異常終了した場合、ⅵで編集し ていたファイルの内容を回復するための処理です。ⅵが異 常終了しても、 / tmp には Ex や Rx などの一時ファイル が残ります。 ex3.7preserve では、 /tmp に残ったⅵの一 時ファイルをもとに / usr / tmp にファイルを回復するため ます。 してユーザーにファイルが回復できる旨をメールで知らせ のファイルを作成し、 / tmp に残った一時ファイルを削除 していますにの例は 4.3BSD での例です。 SunOS では、 lost 十 found 次に、ルートに存在する lost 十 found ディレクトリを紹 % ls —a /tmp/lost + found おや、ファイルは何もありません。念のため total 0 % ls ー 1 /tmp/lost + found 介しましよう。 UNIX MAGAZINE 1991.6 found といいますね。遊園地などに行くと、かならす lost 、、遺失物取扱所〃とか、、遺失物取扱備のことを lost and ます、その名前の由来から調べてみましよう。英語では、 レクトリなのでしようか。 やはり何もありません。いったい、どのような役割のディ and found というコーナーがあります。 lost 十 found とい 161 ます、ディレクトリには i ノード番号とファイル名が格 す。概略をかいつまんで説明しましよう。 レクトリが格納されていますが、その仕組みはやや複雑で 触れた UNIX のファイルシステムには、ファイルやディ ようか ? ちょっと考えてみましよう。前号ですこしは・かり リです。でも、なぜ UNIX に遺失物取扱所が必要なのでし found とは遺失物取扱所と同し役割を果たすディレクト こまでの説明でお分かりだと思いますが、 lost 十 lost 十 found という名前に落ち着いたそうです。 のメタキャラクタですから、かわりに、、十〃が使われて 前にでもすればよかったわけです。しかし、、、 & 〃はシェル んが、 lost and found ですから、、 lost&found" という名 人づてに聞いた話なので本当かどうかは定かではありませ う名前は、この lost and found からとられたそうです。