22 A Study of Framework for Semantic Filesystem

平成

22

年度

修士学位論文

セマンティックファイルシステムの

フレームワークに関する研究

A Study of Framework for Semantic Filesystem

1135075

宮元 裕樹

指導教員

酒居 敬一

2011

年

03

月

01

日

高知工科大学大学院 工学研究科 基盤工学専攻

情報システム工学コース

要 旨

セマンティックファイルシステムの

フレームワークに関する研究

宮元 裕樹

計算機で利用するアプリケーションの増加や新しいデバイスの登場とともに扱うファイル 数が増加している．それに伴って計算機を利用する人がファイルを目的や用途などに応じて 分類する手間が爆発的に増加している．しかし，現状の静的な木構造による分類では手間を 軽減することは困難である．そこでファイルが持つ意味情報を分類し木構造へとマッピング をするセマンティックファイルシステム(SFS)が提案されている．しかし，Linux系ディス トリビューションやFreeBSDなどのUnix系OSまたはWindowsといったOSがSFSを 採用した例は少ない．SFSが採用される例が少ない原因のひとつにSFSを有効に機能させ るために必要不可欠な整理規則や抽出可能なファイルの種類の追加変更が難しいことに問題 があると考えた． 本研究では，その問題を改善するためにスクリプト言語RubyとFUSEを用いてSFSの 機能を容易に追加変更可能なフレームワークを提案した．また，Ruby を用いて実装した ファイルシステムが実用的であることを，処理時間および拡張性の2点から評価した． キーワード セマンティックファイルシステム，ファイルシステム，FUSE，Ruby，SFS

Abstract

A Study of Framework for Semantic Filesystem

Hiroki MIYAMOTO

The number of files installed on the computer have been increasing according to increase of the application and appearance of new device. The file increase raise an increased cost that the user classify the files by their purposes, usages, etc. However, it is difficult to reduce time in the classification by a static conventional tree structure. Therefore, the semantic file system (SFS) have been proposed, it adopts the semantic information extracted from the file to classify the file. But there is no implementation of the semantic files system on the conventional OS such as Linux based distribution, FreeBSD, Windows, Mac OS, etc. We have pointed out major reason for no imple-mentation, that is difficult to update the classification rules and extract the necessary semantic information among the files.

In this thesis, a script language Ruby and an interface library FUSE are used to solve the problem and implement the function of SFS. We propose the framework that make semantic information change scheme easy. Moreover, we have evaluated the framework that the semantic file system implemented by Ruby is useful from two view points (the processing time and the extensibility).

目次

第1章 序論 1 第2章 コンピュータ上でのファイル管理方法 4 2.1 ファイルシステム . . . 4 2.2 セマンティックファイルシステム . . . 6 2.3 スクリプト言語によるファイルシステムの実装 . . . 7 第3章 フレームワーク 10 3.1 システムの構成 . . . 10 3.2 動作シーケンス . . . 12 3.3 ディレクトリ構造 . . . 13 3.4 マッピング . . . 14 3.4.1 システムコール . . . 14 3.4.2 ユーザコマンド . . . 15 3.4.3 パスシンタックス . . . 16 3.4.4 パス名の制約 . . . 17 3.5 コンシステンシ . . . 17 第4章 評価 19 4.1 処理時間 . . . 19 4.2 拡張性 . . . 21 第5章 結論 22 謝辞 24

目次 参考文献 25 付録A スクリーンショット 27 A.1 動作画面 . . . 27 付録B ソースコード 28 B.1 FLACの属性抽出用コード . . . 28 B.2 MP3の属性抽出用コード . . . 29 B.3 ソースコード（C言語）の属性抽出用コード . . . 30 B.4 ベンチマーク（lsコマンド）用コード . . . 31 B.5 予備実験用ベンチマーク（cpコマンド）コード. . . 31

図目次

2.1 VFSとFUSEの概念図 . . . 5 2.2 DRAMのセル面積（1999 – 2015） . . . 7 3.1 システム全体図 . . . 10 3.2 SFS Daemonのブロック図 . . . 11 3.3 SFSフレームワークのクラス図 . . . 11 3.4 lsコマンド実行時のシーケンス図 . . . 12 3.5 vimコマンドでファイル書き込み時のシーケンス図 . . . 12 3.6 ディレクトリ構造 . . . 13 3.7 パスシンタックス . . . 17 3.8 コンシステンシ問題の概念図 . . . 18 A.1 動作画面 . . . 27

表目次

2.1 各種ファイルが持つ属性例 . . . 9 3.1 システムコールのマッピングテーブル . . . 15 4.1 評価環境 . . . 19 4.2 Benchmark 10 Files . . . 20 4.3 Benchmark 1920 Files . . . 20 4.4 属性抽出用ソースコード行数 . . . 20

第

1

章

序論

コンピュータで利用するアプリケーションの増加やコンピュータに接続する新しいデバイ スの登場とともに扱うファイル数が増加し続けている．それらのファイルがアプリケーショ ンやデバイス固有のものであればよいが，コンピュータを利用する人がファイルをアプリ ケーション横断的に目的や用途などに応じて分類しようとすると，手間が爆発的に増加して しまう．しかしながら，現状のファイルシステムではそういった手間を軽減することが難し い．その原因のひとつとして，現在のファイルシステムでは，ディレクトリが木構造であり， その構造が静的であることが挙げられる．このため，ファイルは利用者が定めたひとつの整 理ポリシに則った静的なディレクトリ構造を作って，ファイルの整理をしなければならず， その整理ポリシに束縛され多様なファイル整理が不可能である．また，ファイルへのシンボ リックリンクもしくはハードリンクを用いて整理ポリシを柔軟にする方法は存在するが，必 要なファイル数だけ利用者がリンクを行う必要があり，整理する手間の軽減になっていない． 現在のファイルシステムでは，その実装の中にファイル名，作成年月日，更新年月日，最 終アクセス年月日，所有者，パーミッションといった意味情報を持たせるしくみがある [3]． しかしそれらの情報はファイルの並べ替えには使うが、通常ユーザがファイルの識別に利用 するのは，そういった情報よりもむしろどのディレクトリに置かれ，どのファイル名である かというふたつのパラメータである．一方で，ファイルにはアプリケーションが利用する データをファイルの中に持つのが普通であり，それを抽出して意味情報として扱うことも考 えられる．そのため本来複数の意味情報を持つファイルであっても，名前と場所というふた つのパラメータを除いた他の意味情報は，専用アプリケーションを別にすれば，Windows エクスプローラや Nautilusといったファイラーでもファイルの整理に利用されることは少

ない．これには，日々新しく考えられるアプリケーションごとに異なる分類ポリシを任意の

組み合わせで利用することができず，ディレクトリの中では拡張子などの概念やマジックナ

ンバを導入してある程度の分類はできるにせよ，やはり大域的にはファイルシステム由来の

静的なディレクトリ構造によってのみ分類するしかないという現実がある．このため，Unix

系OS やWindows といったOSでは，SFSを用いる代わりにファイルシステムとは別の サービスとして，WindowsではWindowsサーチ，Linux系ディストリビューションでは

locate，Tracker等が利用されている．これらのサービスでは，サービスによって差異は存 在するがファイル内容のインデックス化およびインデックス化された情報からファイルを検 索する事が出来る． さらに現在のOSはサービスというアプリケーションの一種でファイル整理の手間を軽減 する方法を模索している [7]．しかし，サービスでは対応したアプリケーション以外からは 利用が難しいという問題を抱えている．このため，アプリケーションの改変をすることなく 全てのアプリケーションから利用可能にするためには，これまでのファイルシステムと同じ ようにアプリケーションから利用可能にしなければならない．そのためにはアプリケーショ ンからは静的なディレクトリ構造のようにみえ，パスの移動といった操作によって動的に ディレクトリ構造が変化するといったような新しいファイルシステムが必要となる． ところで，従来から多くの研究者により，これまでに述べた問題を解決するためにファイ ルが持つ意味情報を分類し動的に木構造へとマッピングするセマンティックファイルシステ ム(SFS)が提案されている [1]．しかし，Linux系ディストリビューションやFreeBSDな どのUnix系OSまたはWindowsといったOSがSFSを採用した例は少ない．SFSが採用 される例が少ない原因のひとつにSFSを有効に機能させるために必要不可欠な整理ポリシ や抽出可能なファイルの種類の追加変更が難しいことに問題があると考えた．本論文では，

その問題を改善するためにスクリプト言語RubyとFilesystem in Userspace(FUSE)を用 いて SFS の機能を容易に追加変更可能なフレームワークを提案した．また，Rubyを用い て実装したファイルシステムが実用的であることを，処理時間および拡張性の2点から評価 した．

第2章では現在までのファイルの管理方法について述べ，これまでのファイル管理方法と SFSの問題点を示したあと，研究目的を明らかにしスクリプト言語によるファイルシステム 実装の妥当性について述べる． 第3章では，問題点の改善案の提案をし，これまでの木構造と各種シェル上での制約条件 を考慮した上で提案手法の実現をする． 第4章では，第3章で実現した提案手法の評価を処理速度および拡張性の2点から行った． 第5章では，これまで述べた内容をまとめ，今後の課題および展望について考察する．

第

2

章

コンピュータ上でのファイル管理

方法

2.1

ファイルシステム

ファイルシステムでは，あるデータの集合に対して名前付けをしたものをファイルとして 扱っている．ファイルは画像や音楽，テキスト等のデータやコンピュータプログラムを表現， 管理するための論理的な最小単位になっている．この論理的な最小単位であるファイルを， ファイルシステムはハードディスクドライブやフラッシュメモリ等の記録媒体に記録し，必 要に応じて読み出し，変更等を行っている．また近年のファイルシステムでは，ファイルの 一貫性の保持や，ジャーナリングを行っている場合があり，必要に応じてエラー等の訂正を 行っている．

そして近年のOSでは，Virtual File System(VFS)と呼ばれるさまざまなファイルシス テムを抽象化するための仕組みや，FUSEと呼ばれるユーザ空間上にファイルシステムを実 現するための仕組みが導入されている．

VFSでは図2.1のようにカーネルからext2やext3，ReiserFSといったファイルシステム の違いや，アクセスするデータがローカルディスク上にあるかNetwork File System(NFS)

のようにネットワーク上にあるかといったファイルシステムによって異なる部分を隠蔽し，

抽象化して扱っている．アプリケーションからのファイル操作に関するシステムコールは

VFSが受け取り，それを各ファイルシステムごとに存在するAPIに変換している．このた めユーザはファイルシステムがext3 なのかReiserFSなのかを意識することなく利用可能

2.1 ファイルシステム

VFS

FUSE

NFS

ext3

xfs

Block Device

Network

System Call (open, read, write, …...)

Kernel User FUSE Application 図2.1 VFSとFUSEの概念図 になった．また，VFS登場以前はNFSの仕組みを利用しSFSのような新しいファイルシ ステムの提案も行われてきた．しかし，VFS登場以降はVFSのインタフェースに合わせて 設計ができるようになったため，NFSの仕組みを利用する必要がなくなった． そして，FUSE はVFS の仕組みを利用したカーネルモジュールの一種で，Linux では Kernel 2.6.14から正式に取り込まれたものである．FUSEでは，図 2.1に示すようにアプ リケーションから送られてきたシステムコールをVFSを通してユーザ空間上で実行されて いるFUSEアプリケーションにリダイレクトする仕組みである．これにより，必ずしもファ イルシステムがカーネル空間上で実装される必要がなくなりWikipediaFS [5]やNTFS-3G [6]といったユーザ空間上で実行されるファイルシステムが実現された．

現状のLinux系ディストリビューションやFreeBSDなどのUnix系OS，Windowsなど では，ファイルシステム上にディレクトリ構造を木構造で整理し各種アプリケーションから 扱っている．このディレクトリ構造は，ext3やFAT，NTFSといった異なるファイルシス テムでも実装方法は異なるが似た構造となっている． しかしどのファイルシステムのディレクトリ構造も静的で，仮にファイルに複数の意味を 保持させたとしても，それらを任意の木構造に随時マッピングすることは困難である．ファ イルを移動するにせよリンクを張るにせよファイル数が多くなればそういったマッピングは 困難である．そこで，ファイルから抽出した意味情報を利用し分類を行うSFSが提案され

2.2 セマンティックファイルシステム ている．SFSでは，ファイルから抽出可能な意味情報を動的に木構造にマッピングすること で，ファイル名以外の視点から分類が可能となる． 次節からそのSFSの詳細と，その問題点を述べる．

2.2

セマンティックファイルシステム

SFSでは，ファイルをファイル名とパス情報以外の方法で分類し動的に木構造ディレクト リにマッピングすることができる．これはファイルが持つ意味情報を属性として抽出し，抽 出された属性を整理ポリシに基づいて分類することによって実現されている．このため現在 利用されているNTFSやext3といったファイルシステムとは異なりファイルから抽出する 属性や整理ポリシを追加，変更することによってさまざまな分類を提供でき，同時にディレ クトリの木構造を動的にマッピングできる．表 2.1では各種ファイルからどのような属性が 抽出可能かを示している． 例えば，JavadocやDoxygenの書式に則ってコメントを埋め込んだソースコードファイ ルでは，ファイル内に存在する関数名や作成者などを属性として抽出できる．また，構造体 名や変数名などを属性として追加したい場合には，ファイルから属性情報を抽出し整理ポリ シの作成をすれば新たにSFS上で扱うことも可能である． このようにSFSでは，ファイルの意味情報と整理ポリシからさまざまな分類を提供でき， ディレクトリの木構造に対して動的にマッピングできる．しかし，SFSは一般的に利用さ れているOSで採用された例は少ない．その理由としてSFSを有効に機能させるために必 要不可欠な整理ポリシや抽出可能なファイルの種類の追加変更といったことが難しいこと に原因があると考えた．このため，Unix 系OS やWindowsといったOS では，SFSを用 いる代わりにファイルシステムとは別のサービスとして，Windows ではWindows サーチ，

Linux 系ディストリビューションではlocate，Tracker等が利用されている．これらのサー ビスでは，サービスによって機能の差異は存在するがファイル内容のインデックス化および

2.3 スクリプト言語によるファイルシステムの実装 㪇㪅㪇㪇㪈 㪇㪅㪇㪈 㪇㪅㪈 㪈 㪈㪐㪐㪐 㪉㪇㪇㪇 㪉㪇㪇㪈 㪉㪇㪇㪉 㪉㪇㪇㪊 㪉㪇㪇㪋 㪉㪇㪇㪌 㪉㪇㪇㪍 㪉㪇㪇㪎 㪉㪇㪇㪏 㪉㪇㪇㪐 㪉㪇㪈㪇 㪉㪇㪈㪈 㪉㪇㪈㪉 㪉㪇㪈㪊 㪉㪇㪈㪋 㪉㪇㪈㪌 㪰㪼㪸㫉 㪚 㪼 㫃㫃㩷 㫊㫀 㫑㪼 㩷㩿 㱘 㫄 㪵㪉 㪀 図2.2 DRAMのセル面積（1999 – 2015） はサービスというアプリケーションの一種でファイル整理の手間を軽減する方法を模索して いる．しかし，サービスでは対応したアプリケーション以外からの利用が難しいという問題 を抱えている．このため，アプリケーションの改変をすることなく全てのアプリケーション から利用可能にするためには，これまでのファイルシステムと同じようにアプリケーション から利用でき，ディレクトリ構造を持つ新しいファイルシステムが必要となる． そこで，本研究ではSFSが採用されない原因のひとつであるSFSを有効に機能させるた めに必要不可欠な整理ポリシや抽出可能なファイルの種類の追加変更といったことが難しい ことを改善するためのフレームワークを 第 3章から改善案として提案する．

2.3

スクリプト言語によるファイルシステムの実装

これまで，ファイルシステムはカーネルなどとともにC言語で実装されてきた．これに は，CPUやメモリといったコンピュータリソースの問題，過去のソースコードの再活用， ファイルシステムを構築する手段や，ファイルシステムAPIの各プログラミング言語への

2.3 スクリプト言語によるファイルシステムの実装 対応などが背景にあると考えられる． しかし，現在ではコンピュータリソースおよびAPIの問題は既に解消されつつある．例 えばコンピュータリソースでは，10 年前と比較してCPUは周波数の向上やコア数の増加 によって高速化されており，メモリに関しても図 2.2からわかるように10倍以上の容量を 搭載できるようになっている [8] – [18]．また，APIの問題に関しても本研究で利用した FUSE を活用することによりさまざまなプログラミング言語を用いてファイルシステムを ユーザ空間上で実現可能になっている． 一方で近年ではWebアプリケーションのラピッドプロトタイピングやアジャイルソフト ウェア開発に代表されるように，より簡潔で迅速にプログラムを記述できることが求められ

るようになっているため，RubyやPython，JavaといったC言語よりも抽象度が高く簡潔 に記述できるプログラミング言語が広く使われるようになっている．例えば，Tomcatによ るJSP実装では，Javaをスクリプトレットのように使うことで，Javaの豊富なライブラリ とあいまって煩雑な文字列処理と複雑なモデル処理を生産性高く記述できる一方で，ある程 度速い処理も可能になっている． そこで本研究ではC言語よりも抽象度が高く簡潔に記述することができるプログラミン グ言語を用いて，最小限の手間で拡張可能なファイルシステムのフレームワークを，高い拡 張性が求められるSFSのフレームワークとして提案する．

2.3 スクリプト言語によるファイルシステムの実装 表2.1 各種ファイルが持つ属性例 ファイル 属性 ソースコードファイル(.c) 関数名 作成者 修正者 ソースコードファイル(.rb) クラス名 メソッド名 作成者 修正者 画像ファイル(.jpg) 撮影日 撮影機材名 撮影機材メーカ名 シャッタースピード ISO感度 測光モード フラッシュ GPS情報 音楽ファイル(.mp3, .flac) 作曲者 曲名 ジャンル アルバム名 トラック番号 コメント

第

3

章

フレームワーク

3.1

システムの構成

はじめに，システム全体図を図 3.1に示す．本研究では図 3.1のSFS Daemonのみ作成 した．そして，ユーザプログラムに対してファイルシステムを提供するためのAPIは全て FUSEを通じて提供されるため，カーネルの変更は不要である．

次に，SFS Daemonのブロック図を図 3.2に示す．SFS Daemonは主にSFS Daemon部 とTransducer部の 2つの機能に分割されている．一つ目のSFS Daemon部では，FUSE

インタフェースを通じてファイル操作に関わるシステムコールの処理やオリジナルファイル が更新された際に発生する通知の受け取りを行う．二つ目のTransducer部ではファイルか VFS ls /mount_point_of_sfs libfuse ruby ./sfs.rb FUSE NFS ext3 RDB User Space Program Kernel Space Program

User Program SFS Daemon

3.1 システムの構成

FUSE Interface

SFS Daemon

Transducer

RDB

Original Files

Attributes

System Calls

File

Add/Update/Delete

Notification

File Data

Kernel

User

図3.2 SFS Daemonのブロック図 図3.3 SFSフレームワークのクラス図 ら意味情報の抽出や，抽出された意味情報をSFSが利用するデータベースに対して追加変 更削除をしている．このように，本研究のフレームワークでは FUSEを用いることでカー ネルソースに変更をすることなく，シンプルなインタフェースを通じてアプリケーションか ら送られてくるシステムコールを処理している． さらに，実装したプログラムのクラス図を図 3.3に示す．本フレームワークでは，これま でに述べたように SFS Daemon部とTransducer 部の二つに分かれておりクラスも同様に SFSとTransducersに分かれている．そして，Transducers を継承しファイルの種類ごと

3.2 動作シーケンス 図3.4 lsコマンド実行時のシーケンス図 図3.5 vimコマンドでファイル書き込み時のシーケンス図 に新たなクラスを作成することによって新しい種類のファイルに対応でき，それらのファイ ルは最小限の行数で記述できる．

3.2

動作シーケンス

本研究のSFSフレームワークでは， 3.1節で述べたように，SFS Daemon部と Trans-ducer部に分割されている．そのため，各部とそれ以外のソフトウェアが協調して動作する 必要がある．本節では，ディレクトリの参照をする場合およびファイルに対して書き込みを する場合という二つの異なる動作をするコマンドを例に挙げ，図 3.4および 3.5をもとに動 作シーケンスを述べる． まず，lsコマンドを例にした図 3.4では，lsコマンドのようなコマンドはファイルに対し

3.3 ディレクトリ構造 Original Directory music0.flac music1.flac music2.flac Artists Genres music0.flac music2.flac music1.flac Artist A Artist B

Semantic Filesystem Directory

Symbolic Links 図3.6 ディレクトリ構造 て書き込みをしないためオリジナルファイルに変更を加えることはない．このために，VFS が受け取ったシステムコールは FUSEを経由し SFS Daemonにリダイレクトされ，SFS Daemonはパス名をもとにデータベースに対してクエリを送信し，その結果をlsコマンド に返すようになっている． 次に，vimコマンドを例にした図 3.5では，vimコマンドのようなコマンドはファイル に対して書き込みをするためオリジナルファイルに変更を加える場合がある．このため，図 3.5のようにファイルに対して書き込みを行う場合ext3上に存在するオリジナルファイルを 変更した後，inotifyを用いて SFS Daemonに通知を行った後，SFS Daemonは変更され たファイルの意味情報をTransducer部を利用し更新する．

3.3

ディレクトリ構造

次に，ディレクトリ構造を示す．図 3.6 では，3 つの音楽ファイルを例に上げ SFS の 整理対象のディレクトリを Original Directory とし，整理後のディレクトリを Semantic Filesystem Directory としている．また，Semantic Filesystem Directory 下に存在する ファイルは全て図 3.6の破線が示すファイルへのシンボリックリンクとなっている．

3.4 マッピング

今回のSFSでは，Original Directoryに存在する3つの音楽ファイルから属性を抽出し， 図 3.6に図示されているArtists，GenresのようにSemantic Filesystem Directory下に属 性順に整理を行っている．この整理方法以外にも，新たに整理ポリシにの作成を行えば例と は異なった整理が可能となっている．

3.4

マッピング

SFSでは，NTFSやext3等のファイルシステムとは異なり，各種コマンドの動作，パス 名の解釈等の違いや，FUSE を利用するためのシステムコールのマッピングが必要となる． その為既存のOS上でSFSを動作させる場合コマンドやシステムコールのマッピングをフ レームワーク内で行う必要がある． 次の節から各レイヤーでのマッピングについて述べ，マッピングの際に発生するパス名の 制約を合わせて検討する．

3.4.1

システムコール

FUSEでは，ユーザプログラムからカーネルに対しての open，read，write等のシステ ムコールをVFS経由しユーザ空間で動作するプログラムに対してリダイレクトを行ってい る．これには，FUSEのプログラムを実行する際に，fuse operations構造体とよばれる構 造体を FUSEに対して受け渡すことによってシステムコールが発行された時に呼び出され る関数を設定している．また，fuse operationsでは，open，read，writeといったシステム コールと一対一で対応付けが行われている．

さらに，RubyでFUSEからの呼出しを処理するためのバインディングがFUSEとRuby

のコード間に存在している．この為，各システムコールとRubyの各メソッドの対応付けを する必要がある．本研究では，RubyのFUSEバインディングにFuseFSを用いているため 表 3.1のように対応付けが行われている．

3.4 マッピング

表3.1 システムコールのマッピングテーブル

システムコール FUSE API Ruby Binding open open read file read read

write write write to readdir readdir directory? utime utime touch mkdir mkdir mkdir rmdir rmdir rmdir

rename rename delete, write to

の FUSE バインドの Open 関数に相当する関数を呼び出した後に，Ruby で書かれたの

read file メソッドが呼び出される様になっている．また，Rubyのコード上では open と

readシステムコールは一つのメソッドとしてバインダ上で扱われているため違いが現れて いない．

3.4.2

ユーザコマンド

次にユーザコマンドのマッピングについて述べる． まず，フレームワーク上ではユーザコマンドを2種類に分類できる．はじめに，SFS上 に存在するファイル本体に変更を加えるようなユーザコマンドをファイルエディットコマン ドと定義する．ファイルエディットコマンドではファイルの内容を変更するがファイル間や ディレクトリ等との関係性を変更しないようなコマンドのことを指し，例としては vimや Emacs等が挙げられる．2つ目の分類は，リレーションエディットコマンドと定義する．リ レーションエディットコマンドは，ファイルの変更は行わないが，そのファイルが持つ意味 付け等を変更するコマンドのことを指し，例としては cpやlink，mv等のユーザコマンド が対象となる．

3.4 マッピング 今回のフレームワークではファイルエディットコマンドの動作変更は行っていない．しか し，リレーションエディットコマンドに制約を設けている．なぜならば， 3.4.4節及び 3.5 で述べるパス名の制約およびコンシステンシ問題によって制約を受けるからである．このた め，リレーションエディトコマンドのようなSFSに対して何らかの変更を加えるようなコ マンドはエラーとなる．

3.4.3

パスシンタックス

セマンティックファイルシステムでは，ファイルを検索するために検索対象の属性と値を 入力が必要となる．しかし既存のファイルシステムでは，ファイルにアクセスする手段とし てパスを利用する方法しか存在しない．その為，既存のオペレーティングシステム上でセマ ンティックファイルシステムを利用するには属性と値をパス名を利用して指定できるような 仕組が必要となる．そこで，今回は，パス名に対して一定の条件を設定することによって， フレームワーク内で属性と値の判別を可能にした．そして，利用するパス名のシンタックス は図 3.7のように定めている． 例えば，アーティスト名でファイルを検索したい場合は ls /mount_point_of_sfs/:Artists を実行すればアーティスト名の一覧が表示される．また， ls /mount_point_of_sfs/:Artists/Artist0 を実行すればArtist0が作曲者したファイルが表示される． また，本ファイルシステムでは動作検証および処理時間の検証用にFileNameという特別 なディレクトリを作成している．このディレクトリは，SFS内にある全てのファイルを表示 するためのディレクトリでありこれを用いてベンチマークを第 4章で行った．

3.5 コンシステンシ

<sfs-path> ::= /<pn> | <pn>

<pn> ::= <name> | <attribute>

<field-name> | <name>/<pn> <attribute>/<pn>

<attribute> ::= field: | <field-name>/<value> <field-name> ::= <string>: <value> ::= <string> <name> ::= <string> 図3.7 パスシンタックス

3.4.4

パス名の制約

Unix系OSでは，ファイル名として使用できない文字は’/’ および’\0’のみであるため， 利用出来る文字はWindows等と比べ多い．しかし，習慣上用いない方が良い文字が存在す る．例えば，’<’，’>’，’"’，’*’等である．これらの文字はシェル上等で他の意味付けをされ て利用されており，ファイル名として用いない方が入力の際に手間が軽減され，さらには誤 動作をする危険性を軽減できるためである． 一方でファイルから意味情報を抽出した場合，先に述べたようにパス名に含めることが出 来ないもしくは用いない方が良い文字が含まれている場合がある．この場合本研究が提案す るフレームワークでは全て表示の際に’ ’で置き換える処理を行なっている．このため，実際 に抽出された意味情報とアプリケーション側から見たファイル名が一致しない場合がある．

3.5

コンシステンシ

ファイルシステムにおいてコンシステンシは非常に重要な問題である．例えば，図 3.8が 示すように，ユーザや他のアプリケーションによってファイルが追加，変更，削除された場 合を想定する．この場合，それぞれの場合において早急にSFSのデータベースに対して意

3.5 コンシステンシ

File Create

SFS Database

Add

File Update

SFS Database

Update

Consistency Problem

File Delete

SFS Database

Delete

Consistency Problem

_Time

Consistency Problem File Operation SFS Operation 図3.8 コンシステンシ問題の概念図 味情報を追加，変更，削除をしなければコンシステンシの問題が発生し，そのファイルを利 用した場合，存在すべきファイルが存在しない，異なる意味情報が表示される，存在しない ファイルが存在する等の問題が発生しえる．このためSFSでは常にファイルを監視し，こ れらの変更に対応する必要がある． このため本研究では，Linux カーネル 2.6.13から利用可能なinotifyと呼ばれる仕組みを 利用し，ファイルの監視を行なっている．これによって，オリジナルのディレクトリから追 加，変更，削除された場合はOS側からinotifyを通じてSFS Daemonに通知されるのを利 用しSFSのデータベースの追加，更新，削除をしている．

第

4

章

評価

評価を行った環境を表 4.1 に示す．本研究ではWindows7をホストOSとし，仮想マシ ン上で32bit版Fedora Linuxを動作させ評価環境の構築をした．

そして，評価基準はRubyを用いて実装したファイルシステムのフレームワークが実用的 なことである．そのことを処理時間および拡張性の2点から評価した．

4.1

処理時間

まずは，処理時間が実用的であるかを評価する．測定では，測定対象のディレクトリを ext3 およびSFS上に用意し，10または1920ファイルの音楽データを配置した．そして， 配置したディレクトリに対してlsコマンドを1万回実行し平均した結果を示す． 表 4.2および表 4.3 から分かるように，ext3 上に直接ファイルを配置した場合と比べ， 表4.1 評価環境

CPU Intel Core 2 Duo E6600(2.4GHz) Host Memory Dual-Channel DDR2-800 4GB Guest Memory 1GB

Virtual Machine VMware Player 3.1.4

Host OS Windows 7 Professional(64bit) Guest OS Fedora Linux 14(32bit)

4.2 拡張性

表4.2 Benchmark 10 Files

Filesystem second/10k count second/count ext3 40.49 4.049∗ 10−3 SFS 52.26 5.226∗ 10−3

表4.3 Benchmark 1920 Files

Filesystem second/10k count second / count ext3 404.77 4.047∗ 10−2 SFS 614.64 6.146∗ 10−2 SFS上にファイルを配置した場合でも合計の処理時間が1.2∼1.5倍程度のオーバーヘッド で収まっている．また1コマンドあたりの実行速度に関しても，処理時間のオーバーヘッド が0.001∼0.02秒程度となるため実用的な範囲といえる． また，表 4.2および表 4.3では，ファイル数が10ファイルから1920ファイルと192倍 に増加をさせ評価を行ったが，処理時間の増加は10倍程度とファイル数の増加に比べて比 較的緩やかな増加となっておりファイル数の爆発的な増加にも対応できると考えられる． 表4.4 属性抽出用ソースコード行数 Extensions Lines .mp3 18 .flac 13 .c 27

4.2 拡張性

4.2

拡張性

ファイルから属性を抽出する際に，SFSではファイルの種類ごとに抽出用のプログラムが 必要となる．そのため，より少ないソースコード量で多彩なファイルを対応できることが望 ましい．本研究では，ファイル属性の抽出部と実際にデータベースへ追加する部分を分離し ている．ファイル属性の抽出部の行数をコメントや改行のみの行も含めた形で表 4.4に示 す．表 4.4 から分かるように30行程度で実装できることが分かる．ファイル属性の抽出部 では，既存のライブラリや外部コマンドを活用することを優先し実装を行ったため，このよ うな少ないコード量で実装可能という結果になったと考えられる． しかし，既存のライブラリや外部コマンドが存在しない場合はユーザがファイルから属性 を抽出するためのプログラムを全て記述しなければならず今回の評価結果よりも多くのコー ドを記述する必要があると考えられる．ただし，Rubyを含むスクリプト言語を用いた場合， C言語と比べ抽象度が高いため既存ライブラリや外部コマンドが存在しない場合であっても 実装規模は小さくなると考えられる． このことから，ライブラリや外部コマンドが存在する場合は最小限の手間で拡張が出来る ことを確認した．また，ライブラリや外部コマンドが存在しない場合でも抽象度が高いスク リプト言語ではC言語での実装に比べ比較的小さい実装規模になると考えられる．

第

5

章

結論

コンピュータで利用するアプリケーションの増加やコンピュータに接続する新しいデバイ スの登場とともに扱うファイル数が増加し続けている．それらのファイルがアプリケーショ ンやデバイス固有のものであればよいが，コンピュータを利用する人がファイルをアプリ ケーション横断的に目的や用途などに応じて分類しようとすると，手間が爆発的に増加して しまう．しかしながら，現状のファイルシステムではそういった手間を軽減することが難し い．このため従来から多くの研究者により，これまでに述べた問題を解決するためにファイ ルが持つ意味情報を分類し動的に木構造へとマッピングするSFSが提案されてきた． しかし，Linux系ディストリビューションやFreeBSDなどのUnix系OSまたはWindows

といったOS がSFS を採用した例は少ない．SFS が採用される例が少ない原因のひとつに SFSを有効に機能させるために必要不可欠な整理ポリシや抽出可能なファイルの種類の追加 変更が難しいことに問題があると考えた．そしてその問題を改善するためにスクリプト言語 RubyとFUSEを用いてSFSの機能を容易に追加変更可能なフレームワークを提案した． 本論文では，提案したフレームワークをスクリプト言語Ruby および FUSE を用いて ユーザー空間で実装し，その処理時間および拡張性を評価した．そして，処理時間ではオー バヘッドが1.2倍∼1.5倍程度と既存のファイルシステムであるext3 との差が少なく，ファ イルシステム内に置かれるファイル数が192倍になったとしても処理時間の増加は10倍程 度という評価結果を得られた．このことから実際にスクリプト言語 RubyとFUSEを用い て実用的な処理時間でファイルシステムが動作することを確認した．また，拡張性では，ス クリプト言語 Rubyが持つ既存のライブラリや外部コマンドを利用することによってSFS の拡張が容易であることが示された．

最後に今後の課題を挙げる．まず，現在のフレームワークでは整理ポリシをRubyのコー ドとして記述をしている．しかし整理ポリシはYAMLやXMLといったプログラミング言 語ではない記述法を用いる方がより分かりやすく拡張可能と考える．そのため，YAMLや XMLといったフォーマットで記述可能な整理ポリシの実装が望まれる．また，整理ポリシ 自体も現在のフレームワークでは意味情報を一覧にするのみとなっているためより高度な整 理ポリシの提案が課題となっている．

謝辞

本研究を進めるにあたり，終始御指導と御鞭撻を賜りました，酒居 敬一 講師に心より感 謝致します．また研究室に配属されてから四年間もの間，長いようで短く感じた期間でした が研究以外の事についてもお世話になり本当にありがとうございました． ご多忙な中，本研究の副査をお引き受け下さり，梗概および論文本体について様々な疑問 点や改善点等を指摘していただいた高田 喜朗 准教授に心より感謝致します． 同じくご多忙な中，本研究の副査をお引き受け下さり，梗概および論文本体について様々 な疑問点や改善点等を指摘していただいた松崎 公紀 准教授に心より感謝致します． 本研究を進めるにあたり，日頃から様々な御助言，御指導を賜りました高知工科大学情報 システム工学科教員，スタッフの方々に心より感謝致します． また，あまり研究を見ることはできませんでしたが，頑張っていた研究室の後輩である学 部四回生の國廣 至 氏，浜田 康平 氏，前川 勇人 氏，お疲れ様でした． 研究室の後輩である学部三回生の岡崎 翔平 氏には，先輩としてあまり助言ができなくて 申し訳ありませんでしたが，学部四回生になるともっと忙しくなるとは思いますが研究にも それ以外にも全力を尽くしてください． 最後に，六年間もの間お世話になった高知工科大学の全ての方々に心より感謝致します．

参考文献

[1] David K. Gifford, Pierre Jouvelot, Mark A. Sheldon, and James W. O’Toole, Jr.,

“Semantic File Systems”, ACM Operating Systems Review, pp. 16 – 25, Oct. 1991. [2] Bryan Mills, “Metadata Driven Filesystem”, http://bryanmills.net:8086/

uploads/metafs/bmills-final.pdf, Sept. 15, 2010.

[3] 高橋浩和，小田逸郎，山幡為佐久,“Linux カーネル2.6 解読室 ”, ソフトバンククリ エイティブ株式会社, p.253, 2006年12月25日.

[4] John K. Ousterhout,“Scripting: Higher Level Programming for the 21st Century”, IEEE Computer , Volume 31 Issue No.3, pp. 23 – 30.

[5] Mathieu Blondel,“WikipediaFS”,

http://wikipediafs.sourceforge.net/, Jan. 12, 2011. [6] Tuxera Inc.,“NTFS-3G”,

http://www.tuxera.com/community/ntfs-3g-download/, Jan. 12, 2011.

[7] The GNOME Project,“Tracker”, http://projects.gnome.org/tracker/, Jan. 12, 2011.

[8] ITRS,“ITRS 2000 Update, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2000UpdateFinal/ProcessInt2000final.pdf, Jan. 12, 2011.

[9] ITRS,“ITRS 2001 Edition, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2001ITRS/PIDS.pdf, Jan. 12, 2011.

[10] ITRS,“ITRS 2002 Update, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2002Update/2002UpdatePIDS.pdf, Jan. 12, 2011. [11] ITRS,“ITRS 2003 Edition, Process Integration, Devices, and Structures”,

参考文献

[12] ITRS,“ITRS 2004 Update, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2004Update/2004_03_PIDS.pdf, Jan. 12, 2011. [13] ITRS,“ITRS 2005 Edition, Process Integration, Devices, and Structures”,

http://www.itrs.net/Links/2005ITRS/PIDS2005.pdf, Jan. 12, 2011. [14] ITRS,“ITRS 2006 Update, Process Integration, Devices, and Structures”,

http://www.itrs.net/Links/2006Update/FinalToPost/04_PIDS2006Update. pdf, Jan. 12, 2011.

[15] ITRS,“ITRS 2007 Edition, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2007ITRS/2007_Chapters/2007_PIDS.pdf, Jan. 12, 2011.

[16] ITRS,“ITRS 2008 Update, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2008ITRS/Update/2008Tables_FOCUS_A.xls, Jan. 12, 2011.

[17] ITRS,“ITRS 2009 Edition, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2009ITRS/2009Chapters_2009Tables/2009_ PIDS.pdf, Jan. 12, 2011.

[18] ITRS,“ITRS 2010 Update, Process Integration, Devices, and Structures”, http://www.itrs.net/Links/2010ITRS/2010Update/ToPost/2010Tables_ PIDS_FOCUS_C_ITRS.xls, Jan. 12, 2011.

付録

A

スクリーンショット

A.1

動作画面

付録

B

ソースコード

B.1

FLAC

の属性抽出用コード

require ’rubygems’ require ’flacinfo’ class Flac < Transducer

def run_parse

flac = FlacInfo.new(@path)

hash0 = Hash["artist", flac.tags[’ARTIST’], "genre", flac.tags[’GENRE’]] ary = ["filename", File::basename(@path), "path", @path, "attr", hash0] return Hash[*ary]

end end

B.2 MP3の属性抽出用コード

B.2

MP3

の属性抽出用コード

require ’rubygems’ require ’mp3info’ require ’kconv’ class Mp3 < Transducer def run_parse mp3 = Mp3Info.open(@path)

artist = mp3.tag.artist == nil ? "none" : mp3.tag.artist artist = Kconv.toutf8(artist)

genre = mp3.tag.genre_s == nil ? "none" : mp3.tag.genre_s genre = Kconv.toutf8(genre)

hash0 = Hash["artist", artist, "genre", genre]

ary = ["filename", File::basename(@path), "path", @path, "attr", hash0] return Hash[*ary]

end end

B.3 ソースコード（C言語）の属性抽出用コード

B.3

ソースコード（

C

言語）の属性抽出用コード

require ’rubygems’ require ’lpt’

require File.dirname(__FILE__) + "/transducer.rb" class Clang < Transducer

def run_parse File.open( @path ) { |fd| clang_file = fd.read() tokenizer = LPT::CTokenizer.new( ) tokenizer.parse( clang_file ) languagescanner = LPT::CLanguageScanner.new() languagescanner.parse( tokenizer.tokens ) ary0 = Array.new(); languagescanner.prototypes.each{ |proto| ary0 << proto.method_name.to_s }

hash0 = Hash["functions", ary0]

ary = ["filename", File::basename(@path), "path", @path, "attr", hash0] return Hash[*ary]

} end end

B.4 ベンチマーク（lsコマンド）用コード

B.4

ベンチマーク（

ls

コマンド）用コード

#!/bin/bash cd /tmp/dbfs for i in ‘seq 1 10000‘ do

ls FileName >& /dev/null done cd /tmp

B.5

予備実験用ベンチマーク（

cp

コマンド）コード

#!/bin/bash cd /tmp/dbfs/Artists/Various for i in ‘seq 1 10000‘ do cp music2.flac /tmp/ done cd /tmp