요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
===========================================
Cramfs - cram a filesystem onto a small ROM
===========================================
cramfs is designed to be simple and small, and to compress things well.
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.
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.
Usage Notes
-----------
File sizes are limited to less than 16MB.
Maximum filesystem size is a little over 256MB. (The last file on the
filesystem is allowed to extend past 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.
Hard links are supported, but hard linked files
will still have a link count of 1 in the cramfs image.
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.)
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.
Currently, cramfs must be written and read with architectures of the
same endianness, and can be read only by kernels with PAGE_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.
Memory Mapped cramfs image
--------------------------
The CRAMFS_MTD Kconfig option adds support for loading data directly from
a physical linear memory range (usually non volatile memory like Flash)
instead of going through the block device layer. This saves some memory
since no intermediate buffering is necessary to hold the data before
decompressing.
And when data blocks are kept uncompressed and properly aligned, they will
automatically be mapped directly into user space whenever possible providing
eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped
read-write (hence they have to be copied to RAM) may still be compressed in
the cramfs image in the same file along with non compressed read-only
segments. Both MMU and no-MMU systems are supported. This is particularly
handy for tiny embedded systems with very tight memory constraints.
The location of the cramfs image in memory is system dependent. You must
know the proper physical address where the cramfs image is located and
configure an MTD device for it. Also, that MTD device must be supported
by a map driver that implements the "point" method. Examples of such
MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap
(Flash device in physical memory map). MTD partitions based on such devices
are fine too. Then that device should be specified with the "mtd:" prefix
as the mount device argument. For example, to mount the MTD device named
"fs_partition" on the /mnt directory::
$ mount -t cramfs mtd:fs_partition /mnt
To boot a kernel with this as root filesystem, suffice to specify
something like "root=mtd:fs_partition" on the kernel command line.
Tools
-----
A version of mkcramfs that can take advantage of the latest capabilities
described above can be found here:
https://github.com/npitre/cramfs-tools
For /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.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
작고 압축된 read-only filesystem
1-18cramfs는 filesystem을 작은 ROM에 밀어 넣기 위해 단순하고 작으며 압축률이 좋도록 설계되었습니다.
zlib routine으로 file을 한 page씩 압축하므로 임의 page 접근이 가능합니다. metadata는 압축하지 않지만 매우 간결한 표현을 사용해 전통적인 filesystem보다 disk space를 훨씬 적게 씁니다.
압축 가능성과 compact layout 때문에 동작 중 update가 매우 어려워 cramfs에는 write할 수 없습니다. `mkcramfs` utility로 disk image를 미리 생성해야 합니다.
빌드 시 압축과 runtime read-only page 접근을 분리합니다.
.. SPDX-License-Identifier: GPL-2.0
===========================================
Cramfs - cram a filesystem onto a small ROM
===========================================
cramfs is designed to be simple and small, and to compress things well.
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.
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.
형식 한계와 timestamp·endianness
19-50file size는 16 MB 미만으로 제한되고 filesystem 최대 크기는 256 MB를 조금 넘는 정도입니다. 마지막 file은 256 MB 경계를 넘어 확장될 수 있습니다.
gid는 하위 8 bit만 저장됩니다. 이 문서 당시 `mkcramfs`는 단순히 8 bit로 truncate하므로 potential security issue입니다.
hard link를 지원하지만 image 안의 hard-linked file도 link count가 1로 표시됩니다. directory에는 `.`과 `..` entry가 없고 다른 cramfs file처럼 link count가 항상 1이므로 `find`에 `-noleaf`를 줄 필요는 없습니다.
timestamp를 저장하지 않아 기본값은 epoch인 1970 GMT입니다. 최근 접근한 file은 memory의 inode cache에 있는 동안 timestamp가 갱신될 수 있지만 inode가 사라지면 다시 1970으로 돌아가므로 시간이 뒤로 이동합니다.
cramfs image는 write한 architecture와 read할 architecture의 endianness가 같아야 하고 `PAGE_SIZE == 4096`인 kernel에서만 읽을 수 있습니다. 후자는 bug지만 최선의 수정법이 정해지지 않았습니다. 큰 page system에서는 `mkcramfs.c`의 `#define`을 바꿀 수 있으나 future kernel에서 image를 읽지 못할 수 있습니다.
compact on-disk format이 만드는 크기·identity·호환성 제한입니다.
Usage Notes
-----------
File sizes are limited to less than 16MB.
Maximum filesystem size is a little over 256MB. (The last file on the
filesystem is allowed to extend past 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.
Hard links are supported, but hard linked files
will still have a link count of 1 in the cramfs image.
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.)
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.
Currently, cramfs must be written and read with architectures of the
same endianness, and can be read only by kernels with PAGE_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.
Memory-mapped image와 XIP
51-83`CRAMFS_MTD` Kconfig option은 block device layer를 거치지 않고 보통 Flash 같은 non-volatile physical linear memory range에서 data를 직접 load합니다. decompression 전 intermediate buffer가 필요 없어 memory를 절약합니다.
data block을 압축하지 않고 적절히 align하면 가능한 경우 userspace에 직접 map되어 read-only segment를 ROM에서 eXecute-In-Place(XIP)할 수 있습니다. read-write data segment는 RAM으로 copy해야 하므로 같은 file 안에서도 압축 상태로 둘 수 있고, uncompressed read-only segment와 함께 존재할 수 있습니다. MMU·no-MMU system을 모두 지원해 memory가 매우 제한된 embedded system에 유용합니다.
memory의 cramfs image physical address를 알고 해당 범위의 MTD device를 구성해야 합니다. MTD device는 `point` method를 구현한 map driver가 지원해야 하며 `cfi_cmdset_0001`과 `physmap`, 그리고 그 device 기반 partition이 예입니다.
mount device argument에는 `mtd:` prefix를 사용합니다. `fs_partition`을 `/mnt`에 mount하려면 `mount -t cramfs mtd:fs_partition /mnt`를 실행합니다. root filesystem으로 boot하려면 kernel command line에 `root=mtd:fs_partition`을 지정합니다.
Flash image가 decompression 또는 XIP 경로로 소비되는 방식입니다.
Memory Mapped cramfs image
--------------------------
The CRAMFS_MTD Kconfig option adds support for loading data directly from
a physical linear memory range (usually non volatile memory like Flash)
instead of going through the block device layer. This saves some memory
since no intermediate buffering is necessary to hold the data before
decompressing.
And when data blocks are kept uncompressed and properly aligned, they will
automatically be mapped directly into user space whenever possible providing
eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped
read-write (hence they have to be copied to RAM) may still be compressed in
the cramfs image in the same file along with non compressed read-only
segments. Both MMU and no-MMU systems are supported. This is particularly
handy for tiny embedded systems with very tight memory constraints.
The location of the cramfs image in memory is system dependent. You must
know the proper physical address where the cramfs image is located and
configure an MTD device for it. Also, that MTD device must be supported
by a map driver that implements the "point" method. Examples of such
MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap
(Flash device in physical memory map). MTD partitions based on such devices
are fine too. Then that device should be specified with the "mtd:" prefix
as the mount device argument. For example, to mount the MTD device named
"fs_partition" on the /mnt directory::
$ mount -t cramfs mtd:fs_partition /mnt
To boot a kernel with this as root filesystem, suffice to specify
something like "root=mtd:fs_partition" on the kernel command line.
도구, file magic과 구현 문서
84-123위 기능을 활용할 수 있는 최신 `mkcramfs` 변형은 `https://github.com/npitre/cramfs-tools`에 있습니다.
`/usr/share/magic` 규칙은 offset 0 또는 512에서 little-endian magic `0x28cd3d45`를 찾습니다. 이어서 size, flags, future field, 16-byte signature, `fsid.crc`, `fsid.edition`, `fsid.blocks`, `fsid.files`, 16-byte name을 해석합니다.
filesystem layout과 구현 상세는 source path `fs/cramfs/README`에서 확인합니다.
offset 0과 512에서 동일하게 해석하는 superblock field를 구조화합니다.
Tools
-----
A version of mkcramfs that can take advantage of the latest capabilities
described above can be found here:
https://github.com/npitre/cramfs-tools
For /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.
요약·해설
cramfs.rst:1-123cramfs는 page 단위 zlib 압축과 terse metadata를 사용하는 작은 read-only image filesystem입니다. 16 MB file·약 256 MB filesystem·8-bit gid·4 KB page와 same-endian 제한이 있으며 timestamp와 link count 표현도 축약됩니다.
CRAMFS_MTD는 Flash physical mapping에서 block layer buffer를 생략하고 aligned uncompressed segment를 XIP로 직접 map합니다. image format은 offset 0 또는 512의 magic `0x28cd3d45`로 식별합니다.
일반 compressed image와 MTD XIP 경로의 차이입니다.