close
壓縮檔案系統
eg. 有片光碟片，裡面都是資料，現在要把全部放入硬碟，以
方便隨時查閱，也會分享給別人看，甚至可能會全部 copy 給別人，
你會如何做？
代碼:
# cat /dev/cdrom > /mnt/data.iso
# mount -t iso9660 -o loop /mnt/data.iso /mnt/data/
如果，你有一個空的partition，比光碟容量大一點點，要全部放進去的話，可以這麼做
代碼:
# dd if=/mnt/data.iso of=/dev/hdax
# mount -t iso9660 /dev/hdax /mnt/data
怎麼製作 ext2 的檔案系統
代碼:
# mke2fs /dev/hdax
# mount -t ext2 /dev/hdax /mnt/tmp
如何製作軟碟開機片
代碼:
#!/bin/sh
echo "create 4,096KB "
dd if=/dev/zero of=/tmp/tmp_loop bs=1k count=4096
losetup /dev/loop0 /tmp/tmp_loop
mke2fs -m 0 /dev/loop0
mount -t ext2 /dev/loop0 /mnt/tmp
代碼:
#!/bin/sh
#先把一些你需要的檔案copy進入 /mnt/tmp
umount /mnt/tmp
losetup -d /dev/loop0
echo "建立 ramdisk image : initrd.img"
dd conv=sync if=/tmp/tmp_loop | gzip -9 > /tmp/initrd.img.gz
看initrd.img.gz 的內容
代碼:
# gunzip /tmp/initrd.img.gz
# mount -t ext2 -o loop /tmp/initrd.img /mnt/tmp
上面程式有看到 gzip ，好像有談到縮壓了，沒錯，這是很普通嵌入
式所應用的縮壓方式，但是，我們不用這個方式，因為，要應用時，
要先做一個 ramdisk ，然後把檔案 gunzip 到 ramdisk 上，才能使
用，有什麼缺點呢？舉個例子來說明，假設總共要8MB，縮壓後只要
4MB，你 flash 有 4MB 剛好放得下，記憶體有 16MB ，那開機後
要劃 8MB 的 ramdisk 給解開的檔案系統用，記憶體就憑空少了
8MB，所以這並不是一個很好的方法。當然，也有好處，一切唯讀，
隨便重開機也不會掛，重開機一切恢復正常。
「cramfs」
代碼:
# mkdir /tmp/tmp_root
# copy你所要的檔案到 /tmp/tmp_root
# mkcramfs /tmp/tmp_root.img /tmp/tmp_root
# mount -t cramfs -o loop /tmp/tmp_root.img /mnt/tmp
你會發覺，/mnt/tmp 和 /tmp/tmp_root 的內容是相同的，用 du 去查，
大小也差不多，但是，/tmp/tmp_root.img 的大小卻小很多，而且
也不用另外解開才能讀，不會另外再佔一個非壓縮的空間唷!
說明一下，mkcramfs 主要目的就是做一個壓縮的檔案系統，它做法是
直接把一個目錄轉成一個檔案系統，你可以直接做用 mount 的方式來
掛載，就如同前面的 iso9660 、 ext2 的使用方式。放入嵌入式系統
時，也不用另外再把有限的記憶體割一塊來放檔案系統了。另外，
你或許要重編 kernel 才可支援 cramfs。
這有什麼限制？當然有，最大限制就是，它是一個唯讀的，你對它寫
入是無效的，由於要即時解壓縮，效能上也會差一點點，但不會影響
很大。
那有沒有像 Windows 一樣的，可以對某些檔案、目錄壓縮，也可以
即時寫入的？有的，要 patch C library 及 Kernel。
cramfs 有一些很重要的限制要注意：
一、檔案最大限制為 16MB。
二、檔案系統最大上限為 256MB。
三、所有檔案的 timestamps 都是 1970/01/01 。
其他的請參考 kernel source 的文件 /usr/src/linux/Documentation/filesystems/cramfs.txt
用 squashfs 比較沒有限制，而且壓縮比較好。現在要算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.
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.
eg. 有片光碟片，裡面都是資料，現在要把全部放入硬碟，以
方便隨時查閱，也會分享給別人看，甚至可能會全部 copy 給別人，
你會如何做？
代碼:
# cat /dev/cdrom > /mnt/data.iso
# mount -t iso9660 -o loop /mnt/data.iso /mnt/data/
如果，你有一個空的partition，比光碟容量大一點點，要全部放進去的話，可以這麼做
代碼:
# dd if=/mnt/data.iso of=/dev/hdax
# mount -t iso9660 /dev/hdax /mnt/data
怎麼製作 ext2 的檔案系統
代碼:
# mke2fs /dev/hdax
# mount -t ext2 /dev/hdax /mnt/tmp
如何製作軟碟開機片
代碼:
#!/bin/sh
echo "create 4,096KB "
dd if=/dev/zero of=/tmp/tmp_loop bs=1k count=4096
losetup /dev/loop0 /tmp/tmp_loop
mke2fs -m 0 /dev/loop0
mount -t ext2 /dev/loop0 /mnt/tmp
代碼:
#!/bin/sh
#先把一些你需要的檔案copy進入 /mnt/tmp
umount /mnt/tmp
losetup -d /dev/loop0
echo "建立 ramdisk image : initrd.img"
dd conv=sync if=/tmp/tmp_loop | gzip -9 > /tmp/initrd.img.gz
看initrd.img.gz 的內容
代碼:
# gunzip /tmp/initrd.img.gz
# mount -t ext2 -o loop /tmp/initrd.img /mnt/tmp
上面程式有看到 gzip ，好像有談到縮壓了，沒錯，這是很普通嵌入
式所應用的縮壓方式，但是，我們不用這個方式，因為，要應用時，
要先做一個 ramdisk ，然後把檔案 gunzip 到 ramdisk 上，才能使
用，有什麼缺點呢？舉個例子來說明，假設總共要8MB，縮壓後只要
4MB，你 flash 有 4MB 剛好放得下，記憶體有 16MB ，那開機後
要劃 8MB 的 ramdisk 給解開的檔案系統用，記憶體就憑空少了
8MB，所以這並不是一個很好的方法。當然，也有好處，一切唯讀，
隨便重開機也不會掛，重開機一切恢復正常。
「cramfs」
代碼:
# mkdir /tmp/tmp_root
# copy你所要的檔案到 /tmp/tmp_root
# mkcramfs /tmp/tmp_root.img /tmp/tmp_root
# mount -t cramfs -o loop /tmp/tmp_root.img /mnt/tmp
你會發覺，/mnt/tmp 和 /tmp/tmp_root 的內容是相同的，用 du 去查，
大小也差不多，但是，/tmp/tmp_root.img 的大小卻小很多，而且
也不用另外解開才能讀，不會另外再佔一個非壓縮的空間唷!
說明一下，mkcramfs 主要目的就是做一個壓縮的檔案系統，它做法是
直接把一個目錄轉成一個檔案系統，你可以直接做用 mount 的方式來
掛載，就如同前面的 iso9660 、 ext2 的使用方式。放入嵌入式系統
時，也不用另外再把有限的記憶體割一塊來放檔案系統了。另外，
你或許要重編 kernel 才可支援 cramfs。
這有什麼限制？當然有，最大限制就是，它是一個唯讀的，你對它寫
入是無效的，由於要即時解壓縮，效能上也會差一點點，但不會影響
很大。
那有沒有像 Windows 一樣的，可以對某些檔案、目錄壓縮，也可以
即時寫入的？有的，要 patch C library 及 Kernel。
cramfs 有一些很重要的限制要注意：
一、檔案最大限制為 16MB。
二、檔案系統最大上限為 256MB。
三、所有檔案的 timestamps 都是 1970/01/01 。
其他的請參考 kernel source 的文件 /usr/src/linux/Documentation/filesystems/cramfs.txt
用 squashfs 比較沒有限制，而且壓縮比較好。現在要算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.
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.
全站熱搜
留言列表