JFSのソースを表示

[[Category:ファイルシステム]]
[[en:JFS Filesystem]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related articles end}}
この記事では JFS ファイルシステムを紹介します。特に、実装・メンテナンス・最適化の方法と、ファイルシステム自体の背景情報や不確かな実装の注意点を記載しています。

== 背景 ==

Journaled File System (JFS) は1999年に IBM によってオープンソース化された[[wikipedia:Journaling_file_system|ジャーナリングファイルシステム]]で、2002年から Linux カーネルでサポートされるようになりました。

* 1990年、JFS1 (JFS) が AIX バージョン 3.1 向けにリリースされました。IBM の UNIX サーバーの AIX ラインと密接に関係しており、プロプライエタリな設計になっていました。
* 1995年、スケーラビリティを改善したり機能を増やすなど、JFS を改良するための重点的な開発が開始されました。
* 1997年、改良した JFS のソースを AIX に戻す開発が並行して開始されました。
* 1999年、改良された JFS の設計が OS/2 向けにリリースされました。
* 2001年、改良されたファイルシステム (新しく JFS2 と命名) が AIX 5L 向けにリリースされました。
* 現在の GNU/Linux バージョンは OS/2 向けの JFS をベースにした移植です。

{{Note|1=潜在的な問題は存在しますが、OS/2 と GNU/Linux の JFS ファイルシステムは相互運用が可能です [http://72.14.253.104/search?q=cache:xrFItCW2XdUJ:osdir.com/ml/file-systems.jfs.general/2006-02/msg00008.html+jfs+os/2+linux&hl=en&ct=clnk&cd=1&gl=au&client=firefox-a]。}}

JFS と UNIX や UNIX ライクなオペレーティングシステムの他のファイルシステムを一概に比較するのは難しいですが、JFS は他の GNU/Linux ファイルシステムよりも CPU の使用量が少ないと謳われています [http://www.debian-administration.org/articles/388]。最適化を使うことで、特定のファイル操作で、他の GNU/Linux ファイルシステムと比べて、JFS は高速に動作するとも言われています ([http://www.redhat.com/archives/ext3-users/2005-July/msg00018.html], [[#ベンチマーク|ベンチマーク]]を参照)。 

=== GNU/Linux 開発チーム ===

GNU/Linux の JFS 移植の開発を率いているのは:
* Dave Kleikamp (dave dot kleikamp at oracle dot com)
* HP: http://jfs.sourceforge.net/

=== 技術的な特徴 ===

JFS は多数の機能をサポートする近代的なファイルシステムです。以下はその一部です:
* 完全に64ビット。
* i-node の動的な容量割り当て。小さなファイルが多数存在してもファイルシステムの i-node が不足することはありません。
* 速度と効率性にふったディレクトリ構造:
:- 8以下のエントリしか存在しないディレクトリの中身はディレクトリの i-node 内にインライン保存されます。
:- エントリが9以上あるディレクトリの中身は [[wikipedia:B%2B_tree|B+ 木]]による名前に保存されます。
* JFS は巨大なファイルのブロック割り当てにエクステントを利用します。
* 標準的な Unix のパーミッションに加えて拡張属性をサポート。
* 内部・外部ログをサポート ([[#外部ジャーナル|下を参照]])。
* きわめてスケーラブル。最小ファイル容量から4ペタバイトまでパフォーマンスが変わらない。
* 巨大なシステムで高い性能を発揮するように設計されたアルゴリズム。
* GNU/Linux 向けにチューンされたパフォーマンス。
* トランザクション/ログを提供するように根底から設計 (アドオンではない)。
* システム喪失からの再起動は1秒以下。
* 実績のあるジャーナリングファイルシステムテクノロジ (AIX で10年以上にわたって使用)。
* 元の設計目標: パフォーマンス, 堅牢性, SMP。
* オリジナルの AIX の JFS のチームメンバーが開発・設計したファイルシステム。
* SMP ハードウェアで動作するように作られ、最低でも4コアの SMP マシンを想定してコードを最適化済み。
* (カーネル 3.7 から) TRIM をサポート。

{{Note|JFS uses a journal to maintain consistency of metadata ''only''. Thus, only consistency of metadata (and not actual file contents) can be assured in the case of improper shutdown. This is also the case for XFS and ReiserFS. Ext3, on the other hand, does support journaling of ''both'' metadata and data [http://www.thehackademy.net/madchat/ebooks/FileSystem/up2-6Galli.pdf], though with a significant performance penalty, and not by default.}}

開発者の Steve Best による、JFS の特徴のもっと詳しい (技術的な) 解説が [http://jfs.sourceforge.net/project/pub/jfs.pdf JFS Overview] にあります。

== GNU/Linux での実装 ==

JFS ファイルシステムの実装は GNU/Linux の他のファイルシステムと同じように実装されています。JFS は Linux カーネルのバージョン 2.4 でマージされました [http://kerneltrap.org/node/385]。JFS のドライバーは Arch の標準カーネルパッケージでモジュールとしてビルドされています。JFS ファイルシステムを使用するマシンでカスタムカーネルをビルドする場合、カーネルコンフィグで JFS を有効にしてください:

 File systems
         ---> [*/M] JFS filesystem support

拡張属性を使う場合、"JFS POSIX Access Control Lists" や "JFS Security Labels" も有効にする必要があります:

 File systems
     ---> [*/M] JFS filesystem support 
         ---> [*] JFS POSIX Access Control Lists
         ---> [*] JFS Security Labels

次に、ファイルシステム関連の作業をするために {{Pkg|jfsutils}} パッケージが必要になります。

実際に JFS ファイルシステムを作成するには以下を実行します:

 # mkfs.jfs /dev/target_dev

または:

 # jfs_mkfs /dev/target_dev

どちらのコマンドも動作は同じです。

== 最適化 ==

JFS ファイルシステムでは性能をブーストする複数の方法があります:
* ファイルシステムの定期的なデフラグメンテーション。
* deadline I/O スケジューラの使用。
* 外部ジャーナルの利用。
* {{ic|/etc/fstab}} のファイルシステムに ''noatime'' 属性を付与。

=== JFS のデフラグメンテーション ===

他のファイルシステムと同じように、長い間使用しているとファイルの断片化が起こって JFS のパフォーマンスは劣化します [http://docs.hp.com/en/5576/JFS_Tuning.pdf]。JFS ユーティリティにはデフラグメンテーションのコードが存在しますが、このコードは OS/2 移植から持ち越されたもので手動で実行する必要があります [http://www.mail-archive.com/jfs-discussion@lists.sourceforge.net/msg00573.html]。暫くの間、ファイルシステムがオフライン状態になってもかまわない場合、以下のようなスクリプトを実行することで JFS ファイルシステムをデフラグできます。

{{Warning|This script is '''dangerous''' and may result in the wiping of an entire hard disk, if arguments get switched! Doing this type of operation is only recommended for people who have confidence in doing backups and file system operations.}}

 umount /dev/hdc1
 dd bs=4k if=/dev/hdc1 of=/dev/hdj1
 jfs_fsck /dev/hdj1
 mount -o ro /dev/hdj1 /fs/hdj1
 jfs_mkfs /dev/hdc1
 mount -o rw /dev/hdc1 /fs/hdc1
 (cd /fs/hdj1 && tar -cS -b8 --one -f - .) | (cd /fs/hdc1 && tar -xS -b8 -p -f -)
 umount /dev/hdj1

上記の例では、{{ic|/dev/hdc1}} デバイスにあるデータを {{ic|/dev/hdj1}} デバイスにバックアップしています。

おおまかに言うと、上記のスクリプトは JFS ファイルシステムのデータをバックアップドライブにコピーして、元の JFS ファイルシステムをフォーマットしてからバックアップからデータを書き戻して、最終的に、新しくフォーマットされたドライブに非断片化されたアロケーションツリーを JFS で書き込みます。

{{Warning|If a VMWare session is sitting on an underlying JFS partition that is highly fragmented, performance of the virtual machine may be significantly degraded.}}

=== Deadline I/O スケジューラ ===

カーネルが ''Deadline I/O Scheduler'' を使うように設定されているときに JFS はより良いパフォーマンスを発揮します。事実、このスケジューラを使えば他の GNU/Linux ファイルシステムよりも JFS のほうが高い性能を発揮できます [http://www.redhat.com/archives/ext3-users/2005-July/msg00018.html]。Deadline I/O スケジューラを使用する方法は複数存在します。Deadline I/O スケジューラをデフォルトに設定してリコンパイルする方法が一つです:

 Block layer
     ---> I/O Schedulers
         ---> [*] Deadline I/O scheduler
         ---> Default I/O scheduler (Deadline) --->

一般的な Arch パッケージのカーネルを使っている場合、カーネルコマンドラインに {{ic|1=elevator=deadline}} を追加するか、あるいは同じ設定を {{ic|/etc/default/grub}} に追加して {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} を実行することで永続的に設定できます。カーネルエントリは以下のようになります:

 # (0) Arch 2.6.22
 title   Arch Linux
 root    (hd0,0)
 kernel  /vmlinuz-linux root=/dev/sda3 elevator=deadline
 initrd /initramfs-linux.img

以下のコマンドを実行することで、特定のデバイスで Deadline I/O スケジューラを有効にすることもできます:

 echo deadline > /sys/block/sda/queue/scheduler 

上記のコマンドでは {{ic|/dev/sda}} (物理デバイス全体) のデフォルトとして Deadline スケジューラが設定されます。

=== 外部ジャーナル ===

{{Warning|As this is a relatively new feature to the GNU/Linux port of JFS, it is recommended to upgrade to the very latest version of jfsutils before attempting to implement an external journal (earlier versions seem to give errors when trying to create the journal device).}}

他のジャーナリングファイルシステムと同じように、ディスクの活動に従ってジャーナルには断続的にアクセスが行われます。ファイルシステムと同じデバイスにジャーナルログを保存すると I/O スループットが低下してしまいます。ジャーナルログを別のデバイスに配置することでこのスループットの低下を軽くすることが可能です。

ジャーナルデバイスを作成するには、まず 128MB のパーティションを作成してください。128MB 以上のパーティションを使用しても、超過分は mkfs.jfs によって無視されます。以下のコマンドを実行することで既存の JFS ファイルシステムの外部ログを作成することができます:

 # mkfs.jfs -J journal_dev /dev/external_journal             # creates a journal on device /dev/external_journal
 # mkfs.jfs -J device=/dev/external_journal /dev/jfs_device  # attaches the external journal to the existing file 
                                                           #   system on /dev/jfs_device

もしくは新しい外部ジャーナルの作成と JFS ファイルシステムの作成を同時に実行することもできます:

 # mkfs.jfs -j /dev/external_journal /dev/jfs_device

最後のコマンドは外部ジャーナルと JFS ファイルシステムの両方をフォーマットします。

{{Note|Obviously, an external journal is only effective if the journal and its file system exists on separate ''physical'' devices.}}

=== noatime fstab 属性 ===

Every time a file is accessed (read or write) the default for most file systems is to append the metadata associated with that file with an updated access time. Thus, even read operations incur an overhead associated with a write to the file system. This can lead to a significant degradation in performance in some usage scenarios. Appending ''noatime'' to the fstab line for a JFS file system stops this action from happening. As access time is of little importance in most scenarios, this alteration has been widely touted as a fast and easy way to get a performance boost out of one's hardware. Even Linus Torvalds seems to be a proponent of this optimization [http://kerneltrap.org/node/14148].

{{Note|
* One may also specify a '''relatime''' option which updates the atime if the previous atime is older than the mtime or ctime [http://kerneltrap.org/node/14148]. In terms of performance, this will not be as fast as the ''noatime'' mount option, but is useful if using applications that need to know when files were last read (like ''mutt'').
* Using the ''noatime/relatime'' option can improve disk performance with any file system, not just JFS.
}}

'''noatime''' タグを付けた {{ic|/etc/fstab}} エントリの例:

 /dev/sdb1 /media/backup jfs rw,users,noauto,noatime 0  0

もしくは以下のようにして '''noatime''' 属性を付けてファイルシステムをマウントすることもできます:

 # mount -o noatime -t jfs /dev/jfs_dev /mnt/jfs_fs

{{Note|Access time is NOT the same as the ''last-modified'' time. Disabling access time will still enable you to see when files were last modified by a write operation.}}

=== ジャーナルモード ===

JFS は [[ext3]] のように様々なジャーナルモードをサポートしているわけではありません。そのため、''mount'' や {{ic|/etc/fstab}} で ''data=writeback'' マウントオプションを指定しても JFS ファイルシステムに影響はありません。JFS の現在のジャーナリングモードは ext3 のデフォルトのジャーナリングモードである ''ordered'' と似ています[http://www.ibm.com/developerworks/linux/linux390/perf/tuning_res_journaling.html]。

=== 可変ブロックサイズ ===

JFS の OS/2 移植は 512, 1024, 2048, 4096 バイトのブロックサイズをサポートしていますが JFS の Linux 移植は 4k ブロックしか使用できません。JFS ユーティリティのコードでは可変サイズブロックを使用していますが、手動で実装する必要があります [http://osdir.com/ml/file-systems.jfs.general/2003-02/msg00017.html]。基本的にブロックサイズを大きくすると性能も向上します (ブロックサイズを小さくするとディスクの使用効率が上がります)。JFS 開発者による実装では Linux の JFS で小さいブロックサイズを使用することは優先度が低くなっていました。

== fsck とリカバリ ==

電源が落ちる前にファイルシステムが正しくアンマウントされていなかった場合、再マウントする前に JFS ファイルシステムで '''fsck''' を実行する必要があります。ログにダメージがなければ、数秒程度しかかかりません。fsck を実行して謎のファイルシステムエラーが返ってきた場合、問題のデバイスで '''fsck.jfs''' を実行してみてください。通常は、''fsck'' だけで十分です。

ファイルシステムのスーパーブロックが破壊された場合、ファイルシステムの一部を復元できる可能性があります。現在、復元することができるツールは '''jfsrec''' という名前のユーティリティだけです。JFSrec は AUR の {{AUR|jfsrec-svn}} パッケージでインストールできます。

''jfsrec'' という AUR パッケージも存在しますが、JFSrec の SVN の変更履歴は今のところ7回しかないので ''jfsrec-svn'' のプレースホルダにすぎません。インストールしたら以下を実行することでユーティリティの使用方法を説明するヘルプメニューが表示されます:

 # jfsrec

{{Warning|As stated above, JFSrec is only in its seventh SVN revision; and it is not known how actively the project is maintained. So use JFSrec with caution.}}

== 注意事項 ==

While JFS is very stable in its current stage of development, there are some cautionary notes on using this file system.

=== 起動時に JFS root が読み取り専用でマウントされる ===

Occasionally, a JFS root partition will be unable to mount in normal read-write mode. This is usually due to the fact that the JFS root file system fails its fsck after an unclean shutdown. It is rare that JFS fails out of fsck, and it's usually due to the JFS log itself being corrupted.

All that is required in this scenario is to boot your machine with a relatively recent Arch Linux LiveCD. Booting an Arch Linux livecd will give you access to all the JFS utilities and will load a kernel that is able to recognize JFS file systems. After booting the CD simply run ''fsck'' (or possibly ''fsck.jfs'') on your JFS root and it should recover just fine (even though the fsck will probably take longer than normal due to the log probably being damaged). Once the ''fsck'' finishes, you should be able to boot your machine like normal.

{{Note|This scenario happens less than 10% of the time in the case of an improper shutdown.}}

=== JFS と安全な削除 ===

{{Note|This section applies to any journaled file system, not just JFS.}}

The effectiveness of deleting files by overwriting their corresponding file system blocks with random data (i.e. using utilities like ''shred'') can not be assured [http://lists.kde.org/?l=kfm-devel&m=105770965822522&w=2]. Given the design of journaled file systems, maintenance issues, and performance liabilities; reliable shredding of files as a deletion method does not sit highly on the priority list for implementation on any journaled file system.

=== JFS root ファイルシステムで強制的に fsck ===

One may force a fsck file system check on the root file system by entering:
 touch /forcefsck
and rebooting. On Arch linux systems with a JFS root on a partition under control of ''device-mapper'' (i.e. the root device is a ''lvm'' or a LUKS encrypted one), forcing an fsck can sometimes remove the ''/usr/man/man3'' directory. The reason for this issue is not clear, but the problem has been able to be replicated [https://bbs.archlinux.org/viewtopic.php?id=41261]. 

It is suggested to get a list of Arch Packages that use {{ic|/usr/man/man3}} by issuing a command similar to
 find /var/lib/pacman/local/ -name files | xargs fgrep /man/man3/ | cut -d: -f1 | sort -u | awk -F/ '{print $6}' > man3_pkg_list
before attempting a forced fsck on a JFS root partition ([https://bbs.archlinux.org/viewtopic.php?id=41261] post #1). If {{ic|/usr/man/man3}} does indeed disappear, simply reinstall all the packages listed in ''man3_pkg_list''.

{{Note|1=If this problem does indeed happen, reinstalling all the packages using ''/usr/man/man3'' does appear to fix the issue ([https://bbs.archlinux.org/viewtopic.php?id=41261] post #4).}}

As stated above, the reason for this issue isn't clear at the moment; but it may have something to do with the fact that a forced fsck runs through higher phases of file system checks that only happen when a JFS log gets damaged in an improper dismounting of the partition.

=== JFS でファイルが消失する ===

In JFS; journal writes are indefinitely postponed until there is another trigger such as memory pressure or an unmount operation. This infinite write delay limits reliability, as a crash can result in data loss even for data that was written minutes or hours before.[https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf]

== ベンチマーク ==

As benchmarks measuring file system performance tend to be focused at specific types of disk usage, it is difficult to decipher good general comparisons rating how well JFS performs against other files systems. As mentioned before, it has been noted that JFS has a tendency to use less CPU resources than other GNU/Linux file systems and (with the right optimizations) is faster than other GNU/Linux file systems for certain types of file operations. It has been noted that JFS slows down when working with many files, however[http://fsbench.netnation.com/][http://www.debian-administration.org/articles/388]. In the references are some links to benchmarks; but as always, it is best to test and see what works best for your own system and work load.

== 結論 ==

JFS は安定していて機能豊富なファイルシステムですが、他の Linux ファイルシステムと比べると知名度が劣ります。最適化によって、JFS は安定でありながらも CPU の使用量が抑えられ高速に動作します。特に、VMWare セッションで (適切に最適化・デフラグされた) JFS ファイルシステムを使用すると多大な利益が得られる可能性があります。

== 参照 ==

* A more technical [http://jfs.sourceforge.net/project/pub/jfs.pdf overview] of JFS
* [http://www.linux.com/feature/119025 30 days with JFS]
* JFS [http://jfs.sourceforge.net/ Sourceforge] page
* Note on [http://www.sabi.co.uk/blog/anno06-2nd.html#060422b defragmenting] JFS file systems
* JFS Recovery [http://sourceforge.net/projects/jfsrec Sourceforge] page
* [http://conferences.oreillynet.com/presentations/os2002/best_steve.pdf Presentation] on JFS given by Steve Best (pdf)
* [http://www.debian-administration.org/articles/388 Debian file system comparison]
* [[Wikipedia:JFS (file system)]]
* Some [http://fsbench.netnation.com/ filesystem benchmarks]