差分
/* ファイルシステム */
== ファイルシステムの構造 ==
=== ツリー構造 ===
Unixのファイルシステムは/を頂点にしたツリー構造です。Windows系のオペレーティングシステムではCを頂点にしたツリー構造です。Windows系のオペレーティングシステムでは 「C:といったようにハードウェアである「ドライブ」を意識した構造になっていますが、Unixでは(Cドライブ)」 といったようにハードウェアである「ドライブ」を意識した構造になっていますが、Unixでは「/を頂点にしたきれいなツリー構造になっています。ディレクトリとはパソコンで言う所のフォルダです。ディレクトリがファイルの属性情報を知っています。ファイル自体はデータのみ入っています。先頭から連続したバイト列になっています。むかしファイルといえば大型汎用機のファイル構成しかなかった時代では説明するのが大変でしたが、今、この辺りは既に感覚的に馴染んでいるので、特に説明する必要はないでしょう。」を頂点にしたツリー構造になっています。ディレクトリとはパソコンで言う所のフォルダです。ディレクトリがファイルの属性情報を知っています。ファイル自体はデータのみ入っています。UNIXにおいてのファイルは先頭から連続したバイト列になっています。この事に関して、私達の身の回りにあるコンピュータでは何の不思議もありませんが、むかしの大型汎用機のファイル構成はこのようになっていませんでした。UNIXが登場した当時としては、このような形式はUNIXの特徴でもあったのですが、今やあたりまえになってしまっています。
まずは 「/ (ROOTと呼びます)」にどんなファイルやディレクトリがあるかコマンド ls で見てみましょう。オプション -F は名前の後ろにキャラクタをつけて、それがファイルなのかディレクトリなのか、あるいは他の属性を持つのかを表現してくれます。
<pre class="bash">
$ ls -F /
bin/ dev/ home/ lost+found/ proc/ tmp/ vmlinuz@
boot/ etc/ initrd/ mnt/ root/ usr/
cdrom/ floppy/ lib/ opt/ sbin/ var/
</pre>
; 調べてみよう : Linuxの標準的ファイルシステム階層のスペック(Filesystem Hierarchy Standard)はLinuxファンデーションがドキュメント化しています。<ref>
Filesystem Hierarchy Standard, ''FHS 2.3 was released January 29, 2004.''
http://refspecs.linuxfoundation.org/fhs.shtml
</ref>
* 主要なディレクトリの意味
** /bin : システムに最小限必要なコマンド群
** /dev : デバイススペシャルファイル群
** /home : 一般ユーザのディレクトリ
** /lost+found : 破損したファイルの断片を退逃させる (これはファイルシステムが作成するものでLinuxのファイルシステム階層には含まれない）
** /proc : システムの状況やパラメータをやり取りするファイルのように見せかけたインタフェース
** /tmp : テンポラリディレクトリ
** /boot : ブート時に使用するカーネルが入っている
** /etc : 各種システム設定ファイルのディレクトリ
** /root : ユーザrootのディレクトリ
** /usr : システムに必要なディレクトリ群が入っているディレクトリ
** /sbin : システム管理者に最低限必要なコマンド群
** /lib : システムに最低限必要なライブラリ群
** /var : ログファイルやスプールなど用のディレクトリ
むかしのUNIXではディレクトリは特殊なファイルで、catをすると本当に中身を表示できました。現在ではディレクトリはファイルではなく、ディレクトリという特別なファイルシステム上のノード情報という位置付けになっています。これはUNIXのファイルシステムが抽象化されたレイヤ構造になったためです。
=== ファイルシステムのマウント ===
MOでもUSBメモリでもハードディスクでも、あるいはファイルであってもブロックデバイスとみなせるものなら同じですが、話を単純化するために、ここではハードディスクということで話を勧めましょう。
<pre class="bash">
$ df
; 調べてみよう
: Linux以前のUnixも一つのオペレーティングシステムは主たるファイルシステムは1つだけでした。それは何故でしょう。
ファイルシステムの構築とマウントは非常に簡単です。ハードディスクを指定してフォーマットし、それとマウントポイントとなるディレクトリへマウントするだけです。
=== inode ===
できません。ls -iを使えばinode番号が表示されます。
<pre class="bash">
$ ls -i *.txt
540463 memo.txt 540446 section-4.txt 540452 section-8.txt
540416 section-2.txt 540420 section-6.txt
540443 section-3.txt 540447 section-7.txt
</pre>
inode番号はディレクトリ中にあるファイル名とinode番号を管理するデータ構造
struct dirent
<ref>httphttps://lxrgithub.com/torvalds/linux.no/sourceblob/master/include/linux/dirent.h?v=2.6.8.1</ref>
に格納されています。
カーネル内の関数nameiによりファイル名はinode番号に変換されます。
inode自体は
struct inode
<ref>httphttps://lxrgithub.com/torvalds/linux.no/sourceblob/master/include/linux/fs.h?v=2.6.8.1</ref>
を参照するとわかりますが、ファイルの属性に関する情報などを持っています。
一方でユーザはinode番号はわかりますがinodeが持っている情報には直接アク
これはLinuxのような今日的なUnix系のオペレーティングシステムでは、
複数のファイルシステムの方式を同時に持っているからです。
=== VFS ===
[[File:Filesystem-layer-1.png|thumb|right|300px|VFSレイヤ概念図]]複数のファイルシステム方式があるのに、何故ユーザは統一したインタフェースでファイルにアクセスできるのでしょう複数のファイルシステム方式があるのに、何故ユーザは統一したインタフェースでファイルにアクセスできるのでしょう? それはVFS (Virtual FileSystem)<ref>VFSに関する資料 httphttps://wwwdeveloper.valinuxibm.cocom/tutorials/l-virtual-filesystem-switch/</ref><ref>Overview of the Linux Virtual File System https://www.kernel.jporg/docsdoc/pdfhtml/D-2latest/filesystems/vfs.pdfhtml</ref>
が用意されているからです。
VFSは個々のファイルシステムとユーザの間のクッションの役目を果たしており、
ユーザ側からはVFSしか見えないようになっています。
このVFSがファイルシステム間の違いを吸収し、統一したインタフェースをユーザ側に提供します。
むかしむかしのUNIXはディレクトリとファイルのアクセスの違いはありませんでした。
ディレクトリはシステムがファイルを管理するための内容を持ったファイルでしかありませんでした。
ファイルシステムが1種類しかなく自分のマシンに接続するハードディスク上にあった頃は、
これでも十分ですが、複数のファイルシステムが存在する場合はそうもいきません。
機能や仕様が個々に違う、すべてのファイルシステムに同じ方法でアクセスすることを提供しなければいけません。
ファイルシステムの上に仮想的なファイルシステムを加えて統一したインタフェースを提供するようになったのは1984年のSUN MicrosystemsがSunOS 2.0が最初です。<ref>Jim Mauro and Richard McDougall, "Solaris Internals: Core Kernel Components", Prentice Hall Professional, 2001</ref>
色々なファイルシステムを扱えるフレームワークは、Sunが開発した NFS(Network File System) が別のマシン上にあるファイルシステムをネットワーク経由でマウントするために必要でした。
VFSの下に位置するファイルシステムは、少なくともカーネルのソースコードで数えた所、50以上ありました。
<ref>https://github.com/torvalds/linux/tree/master/fs</ref>
個々のファイルシステムがどこまで利用可能なのか、つまり、常用のファイルシステムとして使えるのか、
互換性のために残しているのか、あるいは読み込みだけで書き込みができない、
あるいは一部の機能しか使えないなどに関しての資料が見当たらないので一概に50以上というのは不適切かも知れません。
しかし、数種類、あるいは十数種類というレベルではないことは確かです。
== ファイルシステム ==
ここでは下位レイヤでのファイルシステムを個別に説明します。
その前に、現在利用しているGNU/Linuxのシステムがどのようなファイルシステムをサポートしているのかを確認する時は [[/proc/filesystems]] を参照するとわかります。
<pre class="bash">
% cat /proc/filesystems
</pre>
=== ext2 ファイルシステム ===
<ref>ext2に関する資料
http://www.linux.or.jp/JF/JFdocs/Filesystems-HOWTO-6.html</ref>
は正式名称Second Extented Filesystemといい、ext2fsとも書きます。Linux のために開発されたファイルシステムです。とも書きます。Linuxのために開発されたファイルシステムです。前身である前身である Ext ファイルシステムの次のバージョンと位置づけられます。最大ファイルシファイルシステムの次のバージョンと位置づけられます。現在も /boot のファイルシステムは ext2 ファイルシステムを利用しているディストリビューションが多くあります。ステムサイズ4TB、最大ファイルサイズ2GB 最大ファイルシステムサイズ4TB (カーネル2.6からは32TB)、最大ファイルサイズ2GB まで扱えます。
ext2ファイルシステムはファイルの読み書きで良い局所性を出すための工夫がされています。
書き出しが行われる時、同じブロックグループ内で、隣接する8ブロックを先行して割り当てするので、連続しての書き込みの効率があがります。
このような書き方をするので当然、連続しての読み込みをする際のヒット率が高くなります。
ext3
<ref>ext3に関する資料 http://www.valinux.co.jp/docs/pdf/D-3.pdf</ref>
ext2 をベースにジャーナリングファイルシステム(Journaling Filesystem)に拡張したものです。
ジャーナリングファイルシステムとはメタデータと呼ばれるファイル属性などの変更履歴をジャーナルログに記録しておき、ファイルシステムの整合をチェックする時は、そのジャーナルを使う方式です。
ext2 ファイルシステムのように整合性をチェックするためにファイルシステム全部を走査する必要がないので高速に処理ができます。
最大ファイルシステムサイズ4TB、最大ファイルサイズ4TBまで扱えます。
=== ext4 ファイルシステム ===
ext4 は ext3 の後継として作られたファイルシステムです。カーネル2.6.19 から正式採用しています。ext4 のファイルシステムは1EB、ファイルサイズは16TBのサイズをサポートしています。
同時期に存在していた競合していたJFSやXFSファイルシステムから良い点を導入しするなど新しい機能や拡張を行い、また安定性も十分に備え、ext3に比べて大きく進化しています。
たとえばパフォーマンスに関してはブロックの遅延アロケーションが可能になりました。これはなるべくディスク上の物理ブロックを連続に確保するために書き込みを遅滞させます。連続した物理ブロックに書き込むことが出来るようになり、その後にファイルをリードする際に高速に読み込むことが出来るようになります。ファイルサイズが最初にわかっている場合はファイルのプリアロケーションの機能を使いディスク上の物理ブロックを予め確保することが出来ます。
* RED HAT ENTERPRISE LINUX ストレージ管理ガイド [https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/storage_administration_guide/ch-ext4 第6章 EXT4 ファイルシステム]
* AAnatomy of ext4 [https://developer.ibm.com/tutorials/l-anatomy-ext4/ Anatomy of ext4 ]
=== JFS / ReiserFS / XFS ===
ext4と比べるべきファイルシステムとして過去IBM社が開発しLinuxカーネルにマージされているJFSファイルシステム
<ref>
JFS
https://wiki.archlinux.jp/index.php/JFS
</ref>
、
ReiserFS ファイルシステム、
あるいは過去シリコングラフィックス社が開発しLinuxカーネルにマージされているXFSファイルシステム
<ref>
http://xfs.org/index.php/Main_Page
</ref>
などもあります。
これらはいずれもジャーナリング機能を持っており、かつ、特色ある機能を持っています。
JFS は IBM の AIX、
XFS はシリコングラフィックス社の IRIX といった実績のあるUNIX系OSで使われていたものであり、
それが Linux に移植され利用されるに至っています。
JFS にしても XFS にしても、これらの能力を最大限に生かしきるのはサーバやクラスタといったエンタープライズ環境であり、
熟練オペレーターによる運用が行われる場合、これらのエンタープライズ環境で必須な障害からの復帰などの能力や特性を十分に活かすことが出来るでしょう。
; 補足 : 日常利用するディスクトップのレベルであれば、GNU/Linuxのディストリビューショ
=== Reiser4 / NILFS2 / Btrfs ===
JFSやXFSやReiserFSの次の世代のファイルシステムです。
(TBD)
=== ISO9660 ファイルシステム ===
=== tmpfs、ramfsファイルシステム ===
=== ネットワークファイルシステム ===
==== NFS ====
NFS (Network filesystem) はUnixで最初に使われたネットワークを経由してはUnixで最初に使われたネットワークを経由してファイルシステムをマウントする仕組みです。ファイルシステムをマウントする仕組みです。NFSの仕様はUNIXだけではなくNFSの仕様はUNIXだけではなく抽象化したファイルシステムとなっています。抽象化したファイルシステムとなっています。たとえば異なるUnixの種類同士たとえば異なるUnixの種類同士(例えばFreeBSDのファイルシステムとLinuxとか、あるいはSUN SolarisとSystemV SolarisとSystemV IIIとか)、あるいはUnixとWindowsといったファイルシステムの種類、の異なるものでもネットワークを介して共有することができます。LANで接続あるいはUnixとWindowsといったファイルシステムの種類の異なるものでもネットワークを介して共有することができます。されたコンピュータ間でファイルを共有することを想定しています。LANで接続されたコンピュータ間でファイルを共有することを想定しています。
<pre class="bash">
$ echo 'abcd' > i
$ cat i
$ cat t
cat: t: そのようなファイルやディレクトリはありません
</pre>
ているので、ファイルの中身はまだ存在しています。
<pre class="bash">
$ echo 'abcd' > i
$ ln i t
合計 4
8488913 -rw-r--r-- 1 hironobu hironobu 5 2005-11-21 20:14 t
</pre>
ル実体への参照リンク数を表しています。最初のiとtがある時は、その実体を
参照している数は2です。ファイルiを消すと、数が減るので1になります。
== 脚注 ==
<references/>
----
[[目次]]へ
