========================================================= これは、 linux-2.6.26.5/Documentation/filesystems/cramfs.txt の和訳 です。 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > 更新日 ： 2008/10/06 翻訳者 ： Seiji Kaneko < skaneko at mbn dot or dot jp > ========================================================= # Cramfs - cram a filesystem onto a small ROM Cramfs - 小さな ROM 向けのファイルシステム詰め合わせ #cramfs is designed to be simple and small, and to compress things well. cramfs は単純で小さく、よく圧縮できるよう設計されています。 #It uses the zlib routines to compress a file one page at a time, and #allows random page access. The meta-data is not compressed, but is #expressed in a very terse representation to make it use much less #diskspace than traditional filesystems. このファイルシステムは、zlib ルーチンを使ってファイルを 1 ページ毎に圧縮し、 ランダムページアクセスを可能にしています。メタデータは圧縮されていませんが、 極めて密度の高い表現になっており、従来のファイルシステムにくらべてずっと小さ なディスク容量しか消費しません。 #You can't write to a cramfs filesystem (making it compressible and #compact also makes it _very_ hard to update on-the-fly), so you have to #create the disk image with the "mkcramfs" utility. cramfs ファイルシステムには書き込みは行なえません (圧縮可能でコンパクトにす ることは、実行時の更新をとても難しくしています)。従って、mkcramfs ユーティリ ティを使ってディスクイメージを作成する必要があります。 #Usage Notes 使い方のメモ ------------ #File sizes are limited to less than 16MB. ファイルサイズは 16MB 以下に制限されます。 #Maximum filesystem size is a little over 256MB. (The last file on the #filesystem is allowed to extend past 256MB.) ファイルシステムの最大容量は 256MB を少々超えたあたりです (ファイルシステム の最後のファイルは 256MB の境界を越えて拡張することができます)。 #Only the low 8 bits of gid are stored. The current version of #mkcramfs simply truncates to 8 bits, which is a potential security #issue. gid は下位 8bit しか格納されません。現在の版の mkcramfs は単に 8bit への切捨 てを行ないますが、これはセキュリティリスクとなる可能性があります。 #Hard links are supported, but hard linked files #will still have a link count of 1 in the cramfs image. ハードリンクはサポートしていますが、ハードリンクされたファイルは cramfs イメ ージ上では link 数は 1 のままです。 #Cramfs directories have no `.' or `..' entries. Directories (like #every other file on cramfs) always have a link count of 1. (There's #no need to use -noleaf in `find', btw.) cramfs ディレクトリには `.' や `..' エントリはありません。ディレクトリ、およ び cramfs 上のすべてのファイルのリンク数は 1 です (従って find などで -noleaf を使う必要はありません)。 #No timestamps are stored in a cramfs, so these default to the epoch #(1970 GMT). Recently-accessed files may have updated timestamps, but #the update lasts only as long as the inode is cached in memory, after #which the timestamp reverts to 1970, i.e. moves backwards in time. cramfs にはタイムスタンプは格納されていないため、初期時刻 (1970 GMT) になっ ています。最近アクセスされたファイルのタイムスタンプは更新されているかも知れ ませんが、その変更は inode がメモリにキャッシュされている間にとどまり、その 後はタイムスタンプは 1970 年に戻ります (時間が逆行します)。 #Currently, cramfs must be written and read with architectures of the #same endianness, and can be read only by kernels with PAGE_CACHE_SIZE #== 4096. At least the latter of these is a bug, but it hasn't been #decided what the best fix is. For the moment if you have larger pages #you can just change the #define in mkcramfs.c, so long as you don't #mind the filesystem becoming unreadable to future kernels. 現時点では、cramfs はエンディアンが同じアーキテクチャで作成・読み出しを行な う必要があり、PAGE_CACHE_SIZE が 4096 のカーネルからだけ読み出し可能です。少 なくとも後者はバグだと考えていますが、最善の修正の判断がまだできていません。 現時点では、もしページサイズがより大きい場合、将来のカーネルでファイルシステ ムが読み出しできなくなるのがかまわないならば、mkcramfs.c の #define を変更し て対応することもできます。 #For /usr/share/magic /usr/share/magic 向け --------------------- 0 ulelong 0x28cd3d45 Linux cramfs offset 0 >4 ulelong x size %d >8 ulelong x flags 0x%x >12 ulelong x future 0x%x >16 string >\0 signature "%.16s" >32 ulelong x fsid.crc 0x%x >36 ulelong x fsid.edition %d >40 ulelong x fsid.blocks %d >44 ulelong x fsid.files %d >48 string >\0 name "%.16s" 512 ulelong 0x28cd3d45 Linux cramfs offset 512 >516 ulelong x size %d >520 ulelong x flags 0x%x >524 ulelong x future 0x%x >528 string >\0 signature "%.16s" >544 ulelong x fsid.crc 0x%x >548 ulelong x fsid.edition %d >552 ulelong x fsid.blocks %d >556 ulelong x fsid.files %d >560 string >\0 name "%.16s" #Hacker Notes ハッカー向けメモ ---------------- #See fs/cramfs/README for filesystem layout and implementation notes. fs/cramfs/README にファイルシステムレイアウトと実装メモが収録されています。