JFS - 版の履歴

Kusakata.bot2: Pkg/AUR テンプレートの更新

2020-12-31T05:44:36Z

Pkg/AUR テンプレートの更新

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

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

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

Kusakata.bot: 文字列「http://www.ibm.com/」を「https://www.ibm.com/」に置換

2018-02-06T14:43:40Z

文字列「http://www.ibm.com/」を「https://www.ibm.com/」に置換

← 古い版		2018年2月6日 (火) 23:43時点における版
172行目:		172行目:
	=== ジャーナルモード ===		=== ジャーナルモード ===

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

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

Kusakata.bot: 文字列「http://www.linux.com/」を「https://www.linux.com/」に置換

2018-02-06T14:42:38Z

文字列「http://www.linux.com/」を「https://www.linux.com/」に置換

← 古い版		2018年2月6日 (火) 23:42時点における版
237行目:		237行目:

	* A more technical [http://jfs.sourceforge.net/project/pub/jfs.pdf overview] of 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]		* [https://www.linux.com/feature/119025 30 days with JFS]
	* JFS [http://jfs.sourceforge.net/ Sourceforge] page		* JFS [http://jfs.sourceforge.net/ Sourceforge] page
	* Note on [http://www.sabi.co.uk/blog/anno06-2nd.html#060422b defragmenting] JFS file systems		* Note on [http://www.sabi.co.uk/blog/anno06-2nd.html#060422b defragmenting] JFS file systems

Kusakata.bot: 文字列「http://sourceforge.net/」を「https://sourceforge.net/」に置換

2018-02-06T14:09:56Z

文字列「http://sourceforge.net/」を「https://sourceforge.net/」に置換

← 古い版		2018年2月6日 (火) 23:09時点における版
240行目:		240行目:
	* JFS [http://jfs.sourceforge.net/ Sourceforge] page		* JFS [http://jfs.sourceforge.net/ Sourceforge] page
	* Note on [http://www.sabi.co.uk/blog/anno06-2nd.html#060422b defragmenting] JFS file systems		* 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		* JFS Recovery [https://sourceforge.net/projects/jfsrec Sourceforge] page
	* [http://conferences.oreillynet.com/presentations/os2002/best_steve.pdf Presentation] on JFS given by Steve Best (pdf)		* [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]		* [http://www.debian-administration.org/articles/388 Debian file system comparison]

Kusakata.bot: 文字列「http://www.mail-archive.com/」を「https://www.mail-archive.com/」に置換

2018-02-06T14:09:20Z

文字列「http://www.mail-archive.com/」を「https://www.mail-archive.com/」に置換

← 古い版		2018年2月6日 (火) 23:09時点における版
89行目:		89行目:
	=== JFS のデフラグメンテーション ===		=== 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 ファイルシステムをデフラグできます。		他のファイルシステムと同じように、長い間使用しているとファイルの断片化が起こって JFS のパフォーマンスは劣化します [http://docs.hp.com/en/5576/JFS_Tuning.pdf]。JFS ユーティリティにはデフラグメンテーションのコードが存在しますが、このコードは OS/2 移植から持ち越されたもので手動で実行する必要があります [https://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.}}		{{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.}}

Kusakata: 言語間リンク修正

2016-11-15T12:19:08Z

言語間リンク修正

← 古い版		2016年11月15日 (火) 21:19時点における版
1行目:		1行目:
	[[Category:ファイルシステム]]		[[Category:ファイルシステム]]
	[[en:JFS ~~Filesystem~~]]		[[en:JFS]]
	{{Related articles start}}		{{Related articles start}}
	{{Related\|ファイルシステム}}		{{Related\|ファイルシステム}}

2015年11月28日 (土) 04:10にKusakataによる

2015-11-28T04:10:58Z

← 古い版		2015年11月28日 (土) 13:10時点における版
153行目:		153行目:
	=== noatime fstab 属性 ===		=== noatime fstab 属性 ===

			大抵のファイルシステムではデフォルトで、ファイルにアクセス (読み取りまたは書き込み) するたびにファイルに関連付けられたメタデータのアクセス日時が更新されます。そのため、読み取り操作だけでもファイルシステムに書き込みを行うオーバーヘッドが発生します。場合によってパフォーマンスに大きな影響を与えることがあります。''noatime'' を fstab の行に追加することで JFS ファイルシステムはアクセス日時の記録を止めます。アクセス日時は基本的にあまり重要ではないため、これはハードウェアのパフォーマンスを上げることができると広くうたわれています。Linus Torvalds もこの最適化の支持者です [http://kerneltrap.org/node/14148]。
	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\|		{{Note\|
192行目:		192行目:
	== 注意事項 ==		== 注意事項 ==

			JFS の今の開発状態はとても安定していますが、ファイルシステムの使用にあたっては注意事項がいくつかあります。
	While JFS is very stable in its current stage of development, there are some cautionary notes on using this file system.

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

			ときどき、JFS root パーティションが通常の読み書きモードでマウントできなくなることがあります。大抵はシャットダウンが正常に終了しなかったために JFS root ファイルシステムが fsck で引っかかっているのが原因です。fsck 以外で JFS が使えなくなるのは稀です。
	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.

			この場合、比較的新しい Arch Linux LiveCD でマシンを起動する必要があります。Arch Linux livecd を起動すると JFS ユーティリティを使用して JFS ファイルシステムを認識できるカーネルがロードされます。CD の起動後 JFS root で ''fsck'' (もしくは ''fsck.jfs'') を実行すればリカバリされます (おそらくログが破損しているために通常よりも fsck の実行時間は長くなります)。''fsck'' が完了したら、通常通りにマシンを起動できるようになります。
	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.}}		{{Note\|This scenario happens less than 10% of the time in the case of an improper shutdown.}}
206行目:		206行目:
	{{Note\|This section applies to any journaled file system, not just JFS.}}		{{Note\|This section applies to any journaled file system, not just JFS.}}

			(''shred'' などのユーティリティを使って) ファイルシステムブロックをランダムなデータを上書きするだけではファイルが確実に削除される保証はありません [http://lists.kde.org/?l=kfm-devel&m=105770965822522&w=2]。ジャーナリングファイルシステムの設計では、メンテナンス性やパフォーマンスが優先されて、ファイルを安全に削除する方法はあまり優先されません。
	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 ===		=== JFS root ファイルシステムで強制的に fsck ===

			以下を入力して再起動することで root ファイルで強制的に fsck ファイルシステムチェックを行うことができます:
	One may force a fsck file system check on the root file system by entering:
	touch /forcefsck		touch /forcefsck
			''device-mapper'' の制御下にあるパーティションで JFS root を使っている Arch Linux 環境では (つまり root デバイスが ''lvm'' や LUKS 暗号化デバイスの場合)、fsck を強制的に実行すると {{ic\|/usr/man/man3}} ディレクトリが削除されてしまうことがあります。この問題の原因は定かではありませんが、再現可能な問題です [https://bbs.archlinux.org/viewtopic.php?id=41261]。
	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].

			{{ic\|/usr/man/man3}} を使用する Arch パッケージのリストを取得するには以下のようなコマンドを実行します:
	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		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''.		JFS root パーティションで強制的に fsck をする前に実行してみてください ([https://bbs.archlinux.org/viewtopic.php?id=41261] post #1)。{{ic\|/usr/man/man3}} が消えてしまったら、''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).}}		{{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).}}

			上述のとおり、今のところ問題の原因ははっきりしていませんが、パーティションの不適切なアンマウントによって JFS のログが破損した場合にファイルシステムのチェックを行うのと何か関係があるようです。
	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 でファイルが消失する ===		=== JFS でファイルが消失する ===

			JFS では、メモリが少なくなったりアンマウント操作などを行わない限り、ジャーナルの書き込みは無期限に延期されます。クラッシュすると数分・数時間前に書き込んだデータも飛んでしまうことがあるので、この無期限の書き込み遅延は信頼性を損ねます [https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf]。
	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]

	== ベンチマーク ==		== ベンチマーク ==

			ファイルシステムのパフォーマンスのベンチマークは特定の種類のディスク利用法に限られるため、他のファイルシステムと JFS を一般的に比較付けするのは簡単ではありません。先に書いたとおり、JFS は他の GNU/Linux ファイルシステムよりも (適切な最適化を行えば) CPU の使用量が少なくて、特定のファイル操作においては他の GNU/Linux ファイルシステムよりも高速だとされています。ただし、多数のファイルを扱うようなときは JFS は遅くなるとも言われています [http://fsbench.netnation.com/][http://www.debian-administration.org/articles/388]。下の参照セクションにベンチマークのリンクがあります。といっても、自分の作業環境でテストして結果を確認するのが一番良いでしょう。
	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.

	== 結論 ==		== 結論 ==

2015年11月27日 (金) 14:45にKusakataによる

2015-11-27T14:45:37Z

← 古い版		2015年11月27日 (金) 23:45時点における版
180行目:		180行目:
	== fsck とリカバリ ==		== fsck とリカバリ ==

			電源が落ちる前にファイルシステムが正しくアンマウントされていなかった場合、再マウントする前に JFS ファイルシステムで '''fsck''' を実行する必要があります。ログにダメージがなければ、数秒程度しかかかりません。fsck を実行して謎のファイルシステムエラーが返ってきた場合、問題のデバイスで '''fsck.jfs''' を実行してみてください。通常は、''fsck'' だけで十分です。
	In the event that the file system does not get properly unmounted before being powered down, one will usually have to run '''fsck''' on a JFS file system in order to be able to remount it. This procedure usually only takes a few seconds, unless the log has been damaged. If running fsck returns an unrecognized file system error, try running '''fsck.jfs''' on the target device. Normally, ''fsck'' is all that is needed.

			ファイルシステムのスーパーブロックが破壊された場合、ファイルシステムの一部を復元できる可能性があります。現在、復元することができるツールは '''jfsrec''' という名前のユーティリティだけです。JFSrec は AUR の {{AUR\|jfsrec-svn}} パッケージでインストールできます。
	If the superblock on your file system gets destroyed, it may be possible to recover some parts of the file system. Currently, the only tool able to do this is a utility called '''jfsrec'''. JFSrec is currently available from the AUR using the {{AUR\|jfsrec-svn}} package.

			''jfsrec'' という AUR パッケージも存在しますが、JFSrec の SVN の変更履歴は今のところ7回しかないので ''jfsrec-svn'' のプレースホルダにすぎません。インストールしたら以下を実行することでユーティリティの使用方法を説明するヘルプメニューが表示されます:
	There is also an AUR package called ''jfsrec'', but this is merely a placeholder for ''jfsrec-svn'' as JFSrec is currently only in its seventh SVN revision. Once installed, one simply need to type:

	# jfsrec		# jfsrec

	to get a help menu explaining how to use this utility.

	{{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.}}		{{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.}}
234行目:		232行目:
	== 結論 ==		== 結論 ==

			JFS は安定していて機能豊富なファイルシステムですが、他の Linux ファイルシステムと比べると知名度が劣ります。最適化によって、JFS は安定でありながらも CPU の使用量が抑えられ高速に動作します。特に、VMWare セッションで (適切に最適化・デフラグされた) JFS ファイルシステムを使用すると多大な利益が得られる可能性があります。
	JFS is a stable, feature-rich file system that hasn't been publicized as much as some of the other Linux file systems. With optimizations, JFS is stable, CPU efficient and fast. In particular, VMWare sessions stand to benefit enormously from a properly optimized and defragmented, underlying JFS file system.

	== 参照 ==		== 参照 ==

2015年11月27日 (金) 13:15にKusakataによる

2015-11-27T13:15:14Z

← 古い版		2015年11月27日 (金) 22:15時点における版
135行目:		135行目:
	{{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).}}		{{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 スループットが低下してしまいます。ジャーナルログを別のデバイスに配置することでこのスループットの低下を軽くすることが可能です。
	As with any journaled file system, a journal is constantly accessed in accordance with disk activity. Having the journal log on the same device as the its corresponding file system thus can cause a degradation in I/O throughput. This degradation can be alleviated by putting the journal log on a separate device all together.

			ジャーナルデバイスを作成するには、まず 128MB のパーティションを作成してください。128MB 以上のパーティションを使用しても、超過分は mkfs.jfs によって無視されます。以下のコマンドを実行することで既存の JFS ファイルシステムの外部ログを作成することができます:
	To make a journal device, first create a partition that is 128MB. Using a partition that is bigger than 128MB results in the excess being ignored, according to mkfs.jfs. You can either create an external log for an already-existing JFS file system by executing the following:

	# mkfs.jfs -J journal_dev /dev/external_journal # creates a journal on device /dev/external_journal		# mkfs.jfs -J journal_dev /dev/external_journal # creates a journal on device /dev/external_journal
143行目:		143行目:
	# system on /dev/jfs_device		# system on /dev/jfs_device

			もしくは新しい外部ジャーナルの作成と JFS ファイルシステムの作成を同時に実行することもできます:
	or a command can be issued to create both a new external journal and its corresponding JFS file system:

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

			最後のコマンドは外部ジャーナルと JFS ファイルシステムの両方をフォーマットします。
	This last command formats BOTH the external journal and the JFS file system.

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

	~~Here~~ ~~is an example~~ {{ic\|/etc/fstab}} ~~entry with the '''noatime''' tag~~:		'''noatime''' タグを付けた {{ic\|/etc/fstab}} エントリの例:

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

			もしくは以下のようにして '''noatime''' 属性を付けてファイルシステムをマウントすることもできます:
	One may also mount a file system with the '''noatime''' attribute by invoking something similar to the following:

	# mount -o noatime -t jfs /dev/jfs_dev /mnt/jfs_fs		# mount -o noatime -t jfs /dev/jfs_dev /mnt/jfs_fs
172行目:		172行目:
	=== ジャーナルモード ===		=== ジャーナルモード ===

	JFS ~~does not support various journal modes like~~ [[ext3]]~~. Thus, passing the mount option ''data=writeback'' with~~ ''mount'' ~~or in~~ {{ic\|/etc/fstab}} ~~will~~ ~~have no effect on~~ a JFS ~~file system.~~ JFS's ~~current~~ ~~journaling~~ ~~mode is similar to Ext3's default journaling mode:~~ ''ordered'' [http://www.ibm.com/developerworks/linux/linux390/perf/tuning_res_journaling.html].		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 で小さいブロックサイズを使用することは優先度が低くなっていました。
	While the OS/2 port of JFS supports block sizes of 512, 1024, 2048, and 4096 bytes, the Linux port of JFS is only able to use 4k blocks. Even though code exists in JFS utilities that correspond to file systems using variable size blocks, this has yet to be implemented [http://osdir.com/ml/file-systems.jfs.general/2003-02/msg00017.html]. As larger block sizes tend to favor performance (smaller ones favor efficient space usage), implementing smaller block sizes for JFS in Linux has been given a low priority for implementation by JFS developers.

	== fsck とリカバリ ==		== fsck とリカバリ ==

2015年11月27日 (金) 11:32にKusakataによる

2015-11-27T11:32:32Z

差分を表示