节省磁盘空间——使用compFUSEd简明的压缩文件系统
Submitted by editor on Wed, 07/16/2008 - 13:11.
in
由Ben Martin提供
翻译者：17LAMP。NET Bob
Filesystem in Userspace（FUSE）项目允许你安装新的文件系统而无须触及你的linux内核。这个文件系统执行时像一般程序那样，可以使用共享函数库和执行一些Linux内核中很难进行的任务。FUSE文件系统只会被电脑上的其它程序视作普通的文件系统。本文中我将关注compFUSEd，这是一个压缩的FUSE文件系统。使用compFUSEd可以为那些高压缩比的文件节省出一大笔磁盘空间，这样文件包括文本文档和可执行文件。
compFUSEd被设计成一种表层的文件系统。这意味着它使用现存的基本文件系统，并对相同文件系统的进行一些修改。在这个情况下修改的是指（解）压缩文件。compFUSEd获取将要写入的数据，进行压缩后存入基本文件系统中。当你通过compFUSEd读取一个文件时，它从基本文件系统中读取并在提供给你数据之前对其解压缩。这表明程序可以使用compFUSEd文件系统而无须知道有关压缩的任何情况，甚至数据本身就是压缩存储在磁盘中的。
现在还没有可用的Ubuntu、Fedora或者openSUSE等环境下的compFUSEd软件包。在本文中我将会从源代码中编译200612321版本，安装在64位的Fedora8机器上。下载页面显示的compFUSEd的打包档为cf-GISMO-date。大概cf前缀指的是compFUSEd。展开的压缩文件会放在名为CompFused的目录下，目录名称不带任何版本信息。
CompFUSEd支持zilb、bzip2、lzo和lzo2压缩格式。我在Fedora 8下无法成功编译后两者的支持。你必须编辑Makefile文件，把不需要的和在Linux系统下编译失败的那些压缩函数库的支持项取消掉。我还发现compFUSEd的默认设置会试图连接profiler函数库，你必须编辑Rules.make文件将这些连接依赖关系移除。我还发现如果建立失败，错误信息会指出符号、共享对象和缺乏gfPIC position-independent code选项。PIC码有一个优点，它可以被载入到内存的不同地址；这对于编译共享函数库是非常有用的，因为在多个函数库要求相同地址时可以移动它们。在Rules.make里的CFLAGS加入-fPIC，并且运行make clean all可以解决这个问题，使得我顺利的完成编译。
$ tar xzvf /.../cf-GISMO-200712321.tgz
$ cd ./CompFused/Gismo/
$ vi Makefile
...
#
# Set to 1 to include support
#
USE_ZLIB=1
USE_BZIP2=1
USE_LZO=0
USE_LZO2=0
...
$ vi Rules.make
CC=gcc
AR=
CFLAGS= -Wall -pedantic -g -D_FILE_OFFSET_BITS=64 -fPIC
LIBS= -lfuse
...
$ make
...
这里没有make install 的目标，你必须手动实现这一步：
# mkdir -p /usr/local/etc/
# cp compFUSEd.conf /usr/local/etc/compFUSEd.conf
# cp cf_main /usr/local/bin/compFUSEd
# mkdir /usr/local/lib/compFUSEd/
# cp -av plugins /usr/local/lib/compFUSEd/
CompFUSEd会检查/usr/local/etc/compFUSEd.conf处文件的配置，也会在你的home目录中查找.compFUSEd文件而不需要.conf扩展。我复制了默认的配置，并在我的home目录设置了一个测试的挂载点。这文件中方括号内的字符是你想要挂载的压缩文件系统的路径。跟在方括号后面的key=value是设置这个挂载点的选项。后端选项告诉compFUSEd哪里是读写压缩文件的地方。压缩和写入的选项指定当数据写入的时候如何压缩文件和使用什么样策略。压缩的文件被compFUSEd内部分解为称为块的小碎片。chunk_size和chunk_max参数分别以字节单位指定每个块的大小和每个文件可以装载到内存中块的数量。写入插件的作用是保存每个文件的块修改。保持将写入插件从compFUSEd核心逻辑中分离出来是一个了不起的设计，因为高效的处理文件块是一个复杂的工作，并且很可能不同于你计划将使用文件系统的取决方式。排除参数的列表文件扩展不会被compFUSEd压缩。不方便的是你不能通过使用正则表达式来指定要排除的文件。
$ cd ~
$ cp /usr/local/etc/compFUSEd.conf .compFUSEd
$ vi .compFUSEd
...
[/home/ben/compFUSEd_test]
backend = /home/ben/.compFUSEd_test.backend
compression = /usr/local/lib/compFUSEd/plugins/cf_zlib.so
writer = /usr/local/lib/compFUSEd/plugins/writer_isimple.so
chunk_size = 8192 # That's 8K per chunk (uncompressed)
chunk_max = 100 # Up to 100 chunk of 8K open per file
exclude = gz # On this mount we compress everything except .gz files
...
$ compFUSEd ~/compFUSEd_test
done reading configuration file.
done reading configuration file.
---------------------------------------------
backend /home/ben/.compFUSEd_test.backend
compression /usr/local/lib/compFUSEd/plugins/cf_zlib.so
chunk writer /usr/local/lib/compFUSEd/plugins/writer_isimple.so
chunk size 8192
chunk max 100
compression threshold 0
...
| compFUSEd GISMO version 1
| by Johan Parent
|
| Please send bug reports, suggestion to compFUSEd.contact@gmail.com
|
| - DISCLAIMER: read it!
| - You run this program at your own risk!
| - Treat your backups with respect :-P
| - DO NOT store valuable data on this EXPERIMENTAL filesystem
| - NEVER modify anything in the backend directory
| while the compFUSEd filesystem is mounted
|
| Feedback at above mentioned address is welcome
+---------------------------------------------------------------------
$ df -h ~ ~/compFUSEd_test
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
compFUSEd
$ fusermount -u ~/compFUSEd_test
这两个可用的写入插件分别叫作wirter_isimple和writer_smarter。两者本质的不同是，wirter_smarter不会对那些压缩比不高的文件进行压缩。文件压缩的过程是把压缩过的文件块移动到文件中未使用的空间。例如，如果一个程序读取数据的第三个文件块并写入新数据，compFUSEd会这把这些新数据压缩成文件块3。如果这个数据变小了，那么块3之后的文件块可能都需要向前移动到离文件头更近的地方。这将花费很大代价，尤其是当文件比较大和文件头部数据频繁修改的时候。文件修改的通常模式是重命名一个已经存在的文件并且重新写入全部文件内容。这是很多文本编辑器所采用的方式，所以你用这个插件来处理compFUSEd中的文件写入将不会有任何不同，如果你只是在compFUSEd文件系统中用一个文本编辑器来编写文件。
在写入新文件或者整个文件重写的情形下，compFUSEd将不会一直在附近位置移动文件块，所以性能不会大幅下降。压缩只会在固定数据和重写文件数据中小文件块时才会真正影响到程序，如同一个关联的数据库所做的那样。你最好是在一个没有大量修改的文件系统上使用compFUSEd。
为了测试compFUSEd 我从Linux文件编制项目的帮助文件中下载了多页版本。这个tar.bz2文件大约有16MB，展开成无压缩文档是103MB，而compFUSEd把这个目录压缩到60MB。
我在运行帮助测试时发现了compFUSEd的一些问题。从8192修改chunk_size会导致大量的不稳定。我发现这个设置必须设到很大数值才是可以接受的，但是当我把这个数据在32KB的范围内修改时会导致compFUSEd崩溃的问题。其它一些稳定性问题似乎与在文件系统中存储目录树有关。如果我只是直接把每个文件直接复制到compFUSEd文件系统中而不创建任何子目录，一切都工作得很好。另一种情况下，如果我试图把帮助压缩档直接解压或者复制一个已经解开的目录树到compFUSEd文件系统中，compFUSEd就会崩溃。配置文件的相关部分和转移compFUSEd文件系统的命令显示在下面。
$ vi ~/.compFUSEd
...
[/home/ben/howto]
backend = /home/ben/.howto.backend
compression = /usr/local/lib/compFUSEd/plugins/cf_bzip2.so
writer = /usr/local/lib/compFUSEd/plugins/writer_isimple.so
chunk_max = 100
chunk_size = 1024000
exclude = gif png jpg jpeg xpm xpi gz tar.gz
...
$ mkdir ~/howto ~/.howto.backend
$ compFUSEd ~/howto
$ cd /tmp
$ tar xjf /.../Linux-html-HOWTOs.tar.bz2
$ find /tmp/HOWTO -exec cp {} ~/howto/ \;
...
如果你希望存储一个可以很好被压缩的文件目录，并且你想要在这个目录之外用一个不会处理压缩的程序来阅读这些文件，那么compFUSEd可能值得一看的。不妙的是compFUSEd中还存在一些bug，这使得直接拖动目录树并使之运行的压缩方式还无法在你的电脑上得以施展。
- editor's blog
- Login or register to post comments
