========================================================= これは、 Linux-2.6.29/Documentation/filesystems/ubifs.txt の和訳 です。 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > 更新日 ： 2009/03/25 翻訳者 ： Seiji Kaneko < skaneko at mbn dot or dot jp > 校正者 ： Masanori Kobayashi < zap03216 at nifty dot ne dot jp > ========================================================= #Introduction #============= はじめに ======== #UBIFS file-system stands for UBI File System. UBI stands for "Unsorted #Block Images". UBIFS is a flash file system, which means it is designed #to work with flash devices. It is important to understand, that UBIFS #is completely different to any traditional file-system in Linux, like #Ext2, XFS, JFS, etc. UBIFS represents a separate class of file-systems #which work with MTD devices, not block devices. The other Linux #file-system of this class is JFFS2. UBIFS ファイルシステムは UBI ファイルシステムから来ています。UBI とは「ソー トされていないブロックイメージ」の頭文字を取っています。UBIFS はフラッシュ 向けファイルシステムで、フラッシュデバイス上で動くよう設計されています。理 解の上で重要な点は、UBIFS は Linux の従来のファイルシステム (例えば Ext2、 XFS、JFS 等) のいずれとも全く異なるものであると言うことです。UBIFS は、ブロ ックデバイスではなく MTD デバイスで動く全く別のファイルシステムのクラスを代 表しています。これ以外にこのクラスに属するファイルシステムには JFFS2 があり ます。 #To make it more clear, here is a small comparison of MTD devices and #block devices. もう少し明確にするために、以下で MTD デバイスとブロックデバイスの簡単な比較 をしましょう。 #1 MTD devices represent flash devices and they consist of eraseblocks of # rather large size, typically about 128KiB. Block devices consist of # small blocks, typically 512 bytes. 1 MTD デバイスはフラッシュデバイスに対応し、比較的大きなサイズのイレーズブ ロック(消去単位)、通常 128KiB、から構成されます。ブロックデバイスは通常 512Byte の比較的小さなブロックで構成されます。 #2 MTD devices support 3 main operations - read from some offset within an # eraseblock, write to some offset within an eraseblock, and erase a whole # eraseblock. Block devices support 2 main operations - read a whole # block and write a whole block. 2 MTD デバイスは主に 3 つの操作をサポートしています。イレーズブロック内の指定 オフセット値から読む (read)、イレーズブロック内で指定オフセット値に書く (write)、イレーズブロックの全体を消去する (erase)、です。ブロックデバイス では主に 2 つの操作を行ないます。ブロック全体を読むか、ブロック全体に書くか、 です。 #3 The whole eraseblock has to be erased before it becomes possible to # re-write its contents. Blocks may be just re-written. 3 データを再書き込みできるようにするには、その前にイレーズブロック全体を消去 しなければなりません。ブロックなら単に上書きすることができます。 #4 Eraseblocks become worn out after some number of erase cycles - # typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC # NAND flashes. Blocks do not have the wear-out property. 4 イレーズブロックは決められたイレーズサイクル後、寿命を迎えます。SLC NAND や NOR フラッシュでは通常 100K-1G 回で、MLC NAND フラッシュでは 1K-10K 回です。ブロックは寿命という特性を持ちません。 #5 Eraseblocks may become bad (only on NAND flashes) and software should # deal with this. Blocks on hard drives typically do not become bad, # because hardware has mechanisms to substitute bad blocks, at least in # modern LBA disks. 5 イレーズブロックは (寿命により) 不良になる場合があり (NAND フラッシュのみで起き ます) ソフトウェアがその対処を行なわなければなりません。ハードドライブ上のブロッ クは通常不良にはなりません。これは最近の LBA ディスクには (自動的に) 不良ブロ ックを置き換えるハードウェア機能が内蔵されているためです。 #It should be quite obvious why UBIFS is very different to traditional #file-systems. これにより、UBIFS が従来のファイルシステムと大きく異なっている理由は明らか でしょう。 #UBIFS works on top of UBI. UBI is a separate software layer which may be #found in drivers/mtd/ubi. UBI is basically a volume management and #wear-leveling layer. It provides so called UBI volumes which is a higher #level abstraction than a MTD device. The programming model of UBI devices #is very similar to MTD devices - they still consist of large eraseblocks, #they have read/write/erase operations, but UBI devices are devoid of #limitations like wear and bad blocks (items 4 and 5 in the above list). UBIFS は UBI 上で動作します。UBI は独立のソフトウェアレイヤで、 drivers/mtd/ubi 以下にあります。UBI は基本的にはボリューム管理とウェアレベ リング (寿命管理) を行なうレイヤです。これにより、MTD デバイスより高位の抽 象化がなされた「UBI ボリューム」と呼ばれるボリュームが提供されます。UBI デ バイスのプログラミングモデルは、MTD デバイスのものとよく似ています - 両方と も大きなイレーズブロックからなり、read/write/erase 操作を持ちます。但し UBI デバイスは、寿命や不良ブロックなどの制限 (上記のリストの 4 と 5) は持ちませ ん。 #In a sense, UBIFS is a next generation of JFFS2 file-system, but it is #very different and incompatible to JFFS2. The following are the main #differences. UBIFS はいわば JFFS2 ファイルシステムの次世代版ですが、JFFS2 とは大きく異な っており互換性もありません。以下が主な相違点です。 #* JFFS2 works on top of MTD devices, UBIFS depends on UBI and works on # top of UBI volumes. #* JFFS2 does not have on-media index and has to build it while mounting, # which requires full media scan. UBIFS maintains the FS indexing # information on the flash media and does not require full media scan, # so it mounts many times faster than JFFS2. #* JFFS2 is a write-through file-system, while UBIFS supports write-back, # which makes UBIFS much faster on writes. * JFFS2 は MTD デバイス上で動きます。UBIFS は UBI に依存し、UBI ボリューム 上で動作します。 * JFFS2 にはメディア上にインデックスを持たず、マウント時に作成する必要があ るため、メディア全体のスキャンが必要になります。UBIFS では FS インデック ス情報をフラッシュメディア上に保持し、メディア全体のスキャンは必要ありま せん。したがって JFFS2 よりはるかに高速にマウント可能です。 * JFFS2 はライトスルータイプのファイルシステムで、UBIFS はライトバックタイ プのファイルシステムです。このため、UBIFS は書き込みがずっと高速です。 #Similarly to JFFS2, UBIFS supports on-the-flight compression which makes #it possible to fit quite a lot of data to the flash. JFFS2 と同様に UBIFS では読み出し・書き込み時の圧縮をサポートしており、フラ ッシュ上に実に多くのデータを入れることができます。 #Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts. #It does not need stuff like fsck.ext2. UBIFS automatically replays its #journal and recovers from crashes, ensuring that the on-flash data #structures are consistent. JFFS2 と同様に UBIFS もリブートや電源断に対する耐性を持ちます。fsck.ext2 の ような処理は必要ありません。UBIFS は自動的にジャーナルをリプレイし、クラッ シュから回復しますし、フラッシュ上のデータ構造は一貫したものに保たれます。 #UBIFS scales logarithmically (most of the data structures it uses are #trees), so the mount time and memory consumption do not linearly depend #on the flash size, like in case of JFFS2. This is because UBIFS #maintains the FS index on the flash media. However, UBIFS depends on #UBI, which scales linearly. So overall UBI/UBIFS stack scales linearly. #Nevertheless, UBI/UBIFS scales considerably better than JFFS2. UBIFS の (性能面での) 拡張性は、フラッシュサイズの対数に比例 (使用する殆どの データ構造は木構造であるため) し、JFFS2 のようにマウント時間とメモリ消費量が フラッシュサイズには一次比例することはありません。これは UBIFS がファイルシス テムインデックスをフラッシュメディア上に置いているためです。但し、UBIFS は UBI に依存し、UBI はフラッシュサイズに比例した性能面での拡張性を持つため、全 体とした UBI/UBIFS スタックの性能はフラッシュサイズに比例したものとなります。 それでも、UBI/UBIFS の拡張性は JFFS2 より有意に優れたものです。 #The authors of UBIFS believe, that it is possible to develop UBI2 which #would scale logarithmically as well. UBI2 would support the same API as UBI, #but it would be binary incompatible to UBI. So UBIFS would not need to be #changed to use UBI2 UBIFS の作者は、拡張性がフラッシュサイズの対数に比例する UBI2 のような UBI レ イヤは作成可能だと考えています。UBI2 は UBI と同じ API を持ちますが、UBI とバ イナリ非互換になるでしょう。UBIFS には UBI2 への変更は必要ないと考えています。 #Mount options #============= マウント時のオプション ====================== #(*) == default. (*) == 既定値 #bulk_read read more in one go to take advantage of flash # media that read faster sequentially #no_bulk_read (*) do not bulk-read bulk_read シーケンシャルリードが高速なフラッシュメディアの利点を 生かすため、一回に大きなデータを読み出す。 no_bulk_read (*) bulk_read を行なわない。 #no_chk_data_crc skip checking of CRCs on data nodes in order to # improve read performance. Use this option only # if the flash media is highly reliable. The effect # of this option is that corruption of the contents # of a file can go unnoticed. #chk_data_crc (*) do not skip checking CRCs on data nodes no_chk_data_crc リード高速化のため、データノードの CRC チェックを省 略する。このオプションはフラッシュメディアが非常に 信頼性が高い場合のみに使用すること。このオプション の副作用により、ファイルの内容の破壊が気づかれない ままとなる可能性があります。 chk_data_crc (*) データノードの CRC チェックを省略しない。 #compr=none override default compressor and set it to "none" #compr=lzo override default compressor and set it to "lzo" #compr=zlib override default compressor and set it to "zlib" compr=none 標準の圧縮設定を上書きし、「なし」にする。 compr=lzo 標準の圧縮設定を上書きし、「lzo」にする。 compr=zlib 標準の圧縮設定を上書きし、「zlib」にする。 #Quick usage instructions #======================== 簡単な利用方法 ============== #The UBI volume to mount is specified using "ubiX_Y" or "ubiX:NAME" syntax, #where "X" is UBI device number, "Y" is UBI volume number, and "NAME" is #UBI volume name. マウントとしようとする UBI ボリュームは ubiX_Y または ubiX:NAME の書式で指 定します。ここで X は UBI デバイス番号、Y は UBI ボリューム番号、NAME は UBI ボリューム名です。 #Mount volume 0 on UBI device 0 to /mnt/ubifs: /mnt/ubifs に UBI デバイス 0 ボリューム 0 をマウントする。 $ mount -t ubifs ubi0_0 /mnt/ubifs #Mount "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume #name): /mnt/ubifs に UBI デバイス 0 の "rootfs" をマウントする ("rootfs" はボリュ ーム名)。 $ mount -t ubifs ubi0:rootfs /mnt/ubifs #The following is an example of the kernel boot arguments to attach mtd0 #to UBI and mount volume "rootfs": #ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs 以下は、mtd0 を UBI にアタッチして、"rootfs" をマウントするカーネルブート パラメータの例です。 ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs #Module Parameters for Debugging #=============================== デバッグのためのモジュールパラメータ ==================================== #When UBIFS has been compiled with debugging enabled, there are 3 module #parameters that are available to control aspects of testing and debugging. #The parameters are unsigned integers where each bit controls an option. #The parameters are: UBIFS をデバッグ機能を有効にしてコンパイルした場合、テストやデバッグの機能 を制御するための 3 つのモジュールパラメータが提供されています。 パラメータは無符号整数で、各ビットがオプションを制御します。 パラメータは以下の通りです。 #debug_msgs Selects which debug messages to display, as follows: debug_msgs 以下のようにして表示したいデバッグメッセージを指定します。 # Message Type Flag value メッセージタイプ フラグ値 # General messages 1 # Journal messages 2 # Mount messages 4 # Commit messages 8 # LEB search messages 16 # Budgeting messages 32 # Garbage collection messages 64 # Tree Node Cache (TNC) messages 128 # LEB properties (lprops) messages 256 # Input/output messages 512 # Log messages 1024 # Scan messages 2048 # Recovery messages 4096 一般メッセージ 1 ジャーナルメッセージ 2 マウントメッセージ 4 コミットメッセージ 8 LEB サーチメッセージ 16 予算情報 32 ガベージコレクトメッセージ 64 Tree Node Cache(TNC) メッセージ 128 LEB プロパティ (lprops) メッセージ 256 入出力メッセージ 512 ログメッセージ 1024 スキャンメッセージ 2048 リカバリメッセージ 4096 #debug_chks Selects extra checks that UBIFS can do while running: debug_chks UBIFS が実行時に実施できる追加のチェック機能を選択する # Check Flag value チェック フラグ値 # General checks 1 # Check Tree Node Cache (TNC) 2 # Check indexing tree size 4 # Check orphan area 8 # Check old indexing tree 16 # Check LEB properties (lprops) 32 # Check leaf nodes and inodes 64 一般のチェック 1 Tree Node Cache (TNC) のチェック 2 インデックス木サイズチェック 4 orchan エリアチェック 8 旧インデックス木のチェック 16 LEB プロパティ (lprops) チェック 32 リーフノードと inode のチェック 64 #debug_tsts Selects a mode of testing, as follows: debug_tsts テストモードを以下のように設定する # Test mode Flag value テストモード フラグ値 # Force in-the-gaps method 2 # Failure mode for recovery testing 4 in-the-gap 方法を選択する 2 リカバリテストのための故障モード 4 #For example, set debug_msgs to 5 to display General messages and Mount #messages. 例えば、一般メッセージとマウントメッセージを表示させるには、debug_msgs を 5 にセットします。 #References #========== 参考文献 ======== #UBIFS documentation and FAQ/HOWTO at the MTD web site: UBIFS の解説文書と FAQ/HOWTO は MTD ウェブサイトにあります。 http://www.linux-mtd.infradead.org/doc/ubifs.html http://www.linux-mtd.infradead.org/faq/ubifs.html