技術討論區 > Embedded 討論版

[分享] 壓縮檔案系統 (三)

<< < (2/2)

hata:
用 squashfs 比較沒有限制,而且壓縮比較好。

duan:

--- 引述: "hata" ---用 squashfs 比較沒有限制,而且壓縮比較好。
--- 引用結尾 ---


hata?  看這篇留言, 應該就是我認識的那位 hata  吧?   :P
問一下, 後來有真的使用 squashfs 這個 filesystem 嗎?   :)

thyme:

--- 引述: "hata" ---用 squashfs 比較沒有限制,而且壓縮比較好。
--- 引用結尾 ---


cramfs 不用另外 patch kernel ,比較省事一點 ,
咦,好像做 embedded 的人是不能怕麻煩的 ;p


--- 引述: "duan" ---
hata?  看這篇留言, 應該就是我認識的那位 hata  吧?   :P
問一下, 後來有真的使用 squashfs 這個 filesystem 嗎?   :)
--- 引用結尾 ---


我也想知道這個好不好用,也許將來用來改進 24MB 的 java 問題,
奇怪,沒事弄一個這麼大的檔會好用嗎??

SaPow:
路過補充一下, cramfs-1.1.tar.gz 裡的 readme 有說



--- 代碼: --- 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_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.


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.
--- 程式碼結尾 ---

siyou:
現在要算squashfs + lzma 最棒了.
squashfs default use gzip, but you can try to patch it to use lzma,
of course you have to change mksquashfs to use lzma too.

siyou.

導覽

[0] 文章列表

[*] 上頁

前往完整版本