MooseFS 很不错，已经实用了半月了，易用，稳定，对小文件很高效。
MogileFS 据说对于 Web 2.0 应用存储图片啥的很好。
GlusterFS 感觉广告宣传做的比产品本身好。
OpenAFS/Coda 是很有特色的东西。
Lustre 复杂，高效，适合大型集群。
PVFS2 搭配定制应用会很好，据说曙光的并行文件系统就是基于 PVFS。
适合做通用文件系统的有 MooseFS，GlusterFS，Lustre。
================================================================
dCache
- 依赖 PostgreSQL
xtreemfs
* 服务端是 Java 实现的
- 性能不高
CloudStore (KosmosFS)
+ 被 Hadoop 作为分布式文件系统后端之一
- 不支持文件元信息
- kfs_fuse 太慢，不可用
MogileFS 据说对于 Web 2.0 应用存储图片啥的很好。
GlusterFS 感觉广告宣传做的比产品本身好。
OpenAFS/Coda 是很有特色的东西。
Lustre 复杂，高效，适合大型集群。
PVFS2 搭配定制应用会很好，据说曙光的并行文件系统就是基于 PVFS。
适合做通用文件系统的有 MooseFS，GlusterFS，Lustre。
================================================================
dCache
- 依赖 PostgreSQL
xtreemfs
* 服务端是 Java 实现的
- 性能不高
CloudStore (KosmosFS)
+ 被 Hadoop 作为分布式文件系统后端之一
- 不支持文件元信息
- kfs_fuse 太慢，不可用
cramfs 文件系统修改方法
[ 2010/09/18 09:59 | by selboo ]
cramfs是一个只读的压缩文件系统,由linus本人亲自编写。
1、cramfs的特点
在嵌入式的环境之下，内存和外存资源都需要节约使用。如果使用RAMDISK方式来使用文件系统，那么在系统运行之后，首先要把外存(Flash)上的映像文件解压缩到内存中，构造起RAMDISK环境，才可以开始运行程序。但是它也有很致命的弱点。在正常情况下，同样的代码不仅在外存中占据了空间(以压缩后的形式存在)，而且还在内存中占用了更大的空间(以解压缩之后的形式存在)，这违背了嵌入式环境下尽量节省资源的要求。
使用cramfs就是一种解决这个问题的方式。cramfs是一个压缩式的文件系统，它并不需要一次性地将文件系统中的所有内容都解压缩到内存之中，而只是在系统需要访问某个位置的数据的时侯，马上计算出该数据在cramfs中的位置，将其实时地解压缩到内存之中，然后通过对内存的访问来获取文件
1、cramfs的特点
在嵌入式的环境之下，内存和外存资源都需要节约使用。如果使用RAMDISK方式来使用文件系统，那么在系统运行之后，首先要把外存(Flash)上的映像文件解压缩到内存中，构造起RAMDISK环境，才可以开始运行程序。但是它也有很致命的弱点。在正常情况下，同样的代码不仅在外存中占据了空间(以压缩后的形式存在)，而且还在内存中占用了更大的空间(以解压缩之后的形式存在)，这违背了嵌入式环境下尽量节省资源的要求。
使用cramfs就是一种解决这个问题的方式。cramfs是一个压缩式的文件系统，它并不需要一次性地将文件系统中的所有内容都解压缩到内存之中，而只是在系统需要访问某个位置的数据的时侯，马上计算出该数据在cramfs中的位置，将其实时地解压缩到内存之中，然后通过对内存的访问来获取文件
优化ext2/ext3文件系统
[ 2010/02/07 18:10 | by selboo ]
一、块大小的优化
块意为最小的存储单位
假设：Block size 1K
每个分区被格式化后，都会创建很多块
如果一个文件有4K，要使用4个块
即使一个块不到1K，但也会使用1个块
假设：Block size 4K
如果一个文件有4K，只使用1个块
即使一个块不到4K，也会使用1个块，直到填满才使用下一个块
这样我们就可以看到一个现象，如果你的文件很大，而数据块很小，这个文件就会被分割成很小的很多块，这样分割的时间和寻址的时间都会花费比较多的时间，相反如果数据块大点就会减少相应的时间！但并非块越大越好
块意为最小的存储单位
假设：Block size 1K
每个分区被格式化后，都会创建很多块
如果一个文件有4K，要使用4个块
即使一个块不到1K，但也会使用1个块
假设：Block size 4K
如果一个文件有4K，只使用1个块
即使一个块不到4K，也会使用1个块，直到填满才使用下一个块
这样我们就可以看到一个现象，如果你的文件很大，而数据块很小，这个文件就会被分割成很小的很多块，这样分割的时间和寻址的时间都会花费比较多的时间，相反如果数据块大点就会减少相应的时间！但并非块越大越好
开源分布式文件系统&文件系统
[ 2010/01/26 15:11 | by selboo ]
GFS(Google File System):
http://www.codechina.org/doc/google/gfs-paper/
MogileFS:
http://www.danga.com/mogilefs
Hadoop/HDFS:
http://hadoop.apache.org/core
KFS(Kosmos Distributed File System):
http://kosmosfs.sourceforge.net
NDFS(Nutch Distributed File System):
http://lucene.apache.org/nutch/
http://wiki.apache.org/nutch/NutchDistributedFileSystem
Gluster(Gluster File System):
http://www.gluster.org
Coda(Coda File System):
http://www.coda.cs.cmu.edu/
Global(Red Hat Global File System Redhat并购):
http://www.redhat.com/gfs
Lustre(Lustre File System Sun并购):
http://www.lustre.org
PVFS(Parallel Virtual File System，非开源):
http://www.parl.clemson.edu/pvfs
GPFS(IBM General Parallel File System, 非开源):
http://www-03.ibm.com/systems/clusters/software/gpfs
OpenAFS(Open Andrew File System IBM):
http://www.openafs.org
XFS(SGI, 不算分布式文件系统):
http://oss.sgi.com/projects/xfs
MOSIX:
http://www.mosix.org
还有一个国内牛人写的FastDFS一个高效的分布式文件系统
http://code.google.com/p/fastdfs/
http://www.codechina.org/doc/google/gfs-paper/
MogileFS:
http://www.danga.com/mogilefs
Hadoop/HDFS:
http://hadoop.apache.org/core
KFS(Kosmos Distributed File System):
http://kosmosfs.sourceforge.net
NDFS(Nutch Distributed File System):
http://lucene.apache.org/nutch/
http://wiki.apache.org/nutch/NutchDistributedFileSystem
Gluster(Gluster File System):
http://www.gluster.org
Coda(Coda File System):
http://www.coda.cs.cmu.edu/
Global(Red Hat Global File System Redhat并购):
http://www.redhat.com/gfs
Lustre(Lustre File System Sun并购):
http://www.lustre.org
PVFS(Parallel Virtual File System，非开源):
http://www.parl.clemson.edu/pvfs
GPFS(IBM General Parallel File System, 非开源):
http://www-03.ibm.com/systems/clusters/software/gpfs
OpenAFS(Open Andrew File System IBM):
http://www.openafs.org
XFS(SGI, 不算分布式文件系统):
http://oss.sgi.com/projects/xfs
MOSIX:
http://www.mosix.org
还有一个国内牛人写的FastDFS一个高效的分布式文件系统
http://code.google.com/p/fastdfs/
EXT3 文件系统错误的修复
[ 2009/12/02 08:59 | by selboo ]
最近处理的一件linux服务器断电导致文件系统启动后文件系统不可读写，数据不可用的桉例，现总结下Linux 文件系统错误的修复方法。
EXT3-fs error (device hda3) in start_transaction: Journal has aborted
If your system abruptly loses power, or if a RAID card is beginning to fail, you might see an ominous message like this within your logs:
EXT3-fs error (device hda3) in start_transaction: Journal has aborted
Basically, the system is telling you that it’s detected a filesystem/journal mismatch, and it can’t utilize the journal any longer. When this situation pops up, the filesystem gets mounted read-only almost immediately. To fix the situation, you can remount the partition as ext2 (if it isn’t your active root partition), or you can commence the repair operations.
If you’re working with an active root partition, you will need to boot into some rescue media and perform these operations there. If this error occurs with an additional partition besides the root partition, simply unmount the broken filesystem and proceed with these operations.
Remove the journal from the filesystem (effectively turning it into ext2):
# tune2fs -O ^has_journal /dev/hda3
Now, you will need to fsck it to correct any possible problems (throw in a -y flag to say yes to all repairs, -C for a progress bar):
# e2fsck /dev/hda3
Once that's finished, make a new journal which effectively makes the partition an ext3 filesystem again
# tune2fs -j /dev/hda3
You should be able to mount the partition as an ext3 partition at this time:
# mount -t ext3 /dev/hda3 /mnt/fixed
Be sure to check your dmesg output for any additional errors after you’re finished!
硬盘故障导致的数据丢失有可能是惨重的，但如果已经发生了，就需要最大程度地将数据恢复出来。这介绍当磁盘因严重问题无法访问后(但BIOS还能识别)，数据的抢救方法，并讨论ext2&ext3格式分区的磁盘短读(short read)错误。首先约定：需要手动输入的字符用黑体字给出，其余的为终端输出。
如果使用ext2或ext3文件系统，可能会收到类似下面一些警告信息，该警告信息来自e2fsck实用程序：
e2fsck /dev/hda1
e2fsck: Attempt to read block from filesystem resulted in short read
如果看到这个消息，首先想到可能是磁盘的主超级块损坏。而在创建文件系统的时候，mke2fs已经自动创建了磁盘的超级块的备份。可以告诉e2fsck程序使用一个备用超级块检查文件系统。备用超级块一般创建于块8193、16384或32768，取决于磁盘的大小(可以使用mkfs.ext3 -n /dev/hda1查看)。假设是块大硬盘，则使用：
e2fsck -b 32768 /dev/hda1
如果是超级块的问题，则程序返回后，备用超级块被启用，磁盘恢复正常。如果提示下面的问题：
e2fsck: Attempt to read block from filesystem resulted in short read while checking ext3 journal for /dev/hda1
说明问题不是出在超级块，出自日志文件系统的日志。此时可以安全地删除ext3文件系统的日志：
tune2fs -f -O ^has_journal /dev/hda1
这样就删除了/dev/hda1文件系统上的日志，这时可以重新尝试挂载分区，必要的话可以重建日志系统(使用tune2fs -j /dev/xxx)。
如果tune2fs提示下面的错误：
tune2fs: Attempt to read block from filesystem resulted in short read while reading journal inode
则说明指向日志的inode坏了，意味着无法清除日志。这时可以尝试debugfs命令，它是ext2&3文件系统的调试器。也可以再次使用e2fsck，加上-c参数检查文件系统的坏块。至此，因为无法检查或修复问题磁盘上的文件系统，该拿出杀手锏了。
使用ddrescue克隆损坏的磁盘
如果磁盘因为坏块而妨碍了读取，可以使用一个原始的磁盘复制实用程序创建磁盘的一个副本。Unix/Linux系统自带了一个简单实用程序dd，它把一个文件/分区/磁盘复制到另一个(在第一个专题里用到过)。前提条件时必须在系统里添加一块容量不小于问题磁盘的新硬盘。
新硬盘准备就绪后，输入下面命令：
dd if=/dev/hda of=/dev/hdb conv=noerror,sync
上面的命令将坏磁盘(/dev/hda)复制到新磁盘(/dev/hdb)，忽略读取时遇到的错误(noerror)，当遇到不能访问的块时用适当数量的空值填充输出(sync)。
但是dd有几个缺点：首先是速度太慢；然后是不显示进度信息，直到完成前它都是沉默的；不重新尝试失败的读取，这会减少能从坏盘恢复的数据量。因此在这里介绍另一个软件——ddrescue，可以从 http://www.gnu.org/software/ddrescue/ddrescue.html 获取最新版（Fedora8用户可以直接用yum install dd_rescue安装） 。目前ddrescue最新版本是1.7，直接下载链接： http://ftp.gnu.org/gnu/ddrescue/ddrescue-1.7.tar.bz2
编译、安装后，可以使用下面命令完成相同的任务：
ddrescue --max-retries=-1 /dev/hda /dev/hdb
其中max-retries=-1参数表示无论遇到多少错误都不要停止。程序从hda读取数据并写到hdb中时，不断更新各项数据，可以方便地查看工作进行情况。
在ddrescue结束磁盘复制后，在新硬盘上运行e2fsck，以消除原始磁盘的坏块引起的文件系统错误。由于肯定会有大量错误，可以用-y参数运行e2fsck，指示e2fsck对每个问题都回答yes：
e2fsck -y /dev/hdb
此时，可以使用mount命令挂载文件系统，看看数据的恢复情况了。记得检查驱动器根目录下的lost+found文件夹，fsck把不能正确链接的文件和目录放在了这个文件夹里。
EXT3-fs error (device hda3) in start_transaction: Journal has aborted
If your system abruptly loses power, or if a RAID card is beginning to fail, you might see an ominous message like this within your logs:
EXT3-fs error (device hda3) in start_transaction: Journal has aborted
Basically, the system is telling you that it’s detected a filesystem/journal mismatch, and it can’t utilize the journal any longer. When this situation pops up, the filesystem gets mounted read-only almost immediately. To fix the situation, you can remount the partition as ext2 (if it isn’t your active root partition), or you can commence the repair operations.
If you’re working with an active root partition, you will need to boot into some rescue media and perform these operations there. If this error occurs with an additional partition besides the root partition, simply unmount the broken filesystem and proceed with these operations.
Remove the journal from the filesystem (effectively turning it into ext2):
# tune2fs -O ^has_journal /dev/hda3
Now, you will need to fsck it to correct any possible problems (throw in a -y flag to say yes to all repairs, -C for a progress bar):
# e2fsck /dev/hda3
Once that's finished, make a new journal which effectively makes the partition an ext3 filesystem again
# tune2fs -j /dev/hda3
You should be able to mount the partition as an ext3 partition at this time:
# mount -t ext3 /dev/hda3 /mnt/fixed
Be sure to check your dmesg output for any additional errors after you’re finished!
硬盘故障导致的数据丢失有可能是惨重的，但如果已经发生了，就需要最大程度地将数据恢复出来。这介绍当磁盘因严重问题无法访问后(但BIOS还能识别)，数据的抢救方法，并讨论ext2&ext3格式分区的磁盘短读(short read)错误。首先约定：需要手动输入的字符用黑体字给出，其余的为终端输出。
如果使用ext2或ext3文件系统，可能会收到类似下面一些警告信息，该警告信息来自e2fsck实用程序：
e2fsck /dev/hda1
e2fsck: Attempt to read block from filesystem resulted in short read
如果看到这个消息，首先想到可能是磁盘的主超级块损坏。而在创建文件系统的时候，mke2fs已经自动创建了磁盘的超级块的备份。可以告诉e2fsck程序使用一个备用超级块检查文件系统。备用超级块一般创建于块8193、16384或32768，取决于磁盘的大小(可以使用mkfs.ext3 -n /dev/hda1查看)。假设是块大硬盘，则使用：
e2fsck -b 32768 /dev/hda1
如果是超级块的问题，则程序返回后，备用超级块被启用，磁盘恢复正常。如果提示下面的问题：
e2fsck: Attempt to read block from filesystem resulted in short read while checking ext3 journal for /dev/hda1
说明问题不是出在超级块，出自日志文件系统的日志。此时可以安全地删除ext3文件系统的日志：
tune2fs -f -O ^has_journal /dev/hda1
这样就删除了/dev/hda1文件系统上的日志，这时可以重新尝试挂载分区，必要的话可以重建日志系统(使用tune2fs -j /dev/xxx)。
如果tune2fs提示下面的错误：
tune2fs: Attempt to read block from filesystem resulted in short read while reading journal inode
则说明指向日志的inode坏了，意味着无法清除日志。这时可以尝试debugfs命令，它是ext2&3文件系统的调试器。也可以再次使用e2fsck，加上-c参数检查文件系统的坏块。至此，因为无法检查或修复问题磁盘上的文件系统，该拿出杀手锏了。
使用ddrescue克隆损坏的磁盘
如果磁盘因为坏块而妨碍了读取，可以使用一个原始的磁盘复制实用程序创建磁盘的一个副本。Unix/Linux系统自带了一个简单实用程序dd，它把一个文件/分区/磁盘复制到另一个(在第一个专题里用到过)。前提条件时必须在系统里添加一块容量不小于问题磁盘的新硬盘。
新硬盘准备就绪后，输入下面命令：
dd if=/dev/hda of=/dev/hdb conv=noerror,sync
上面的命令将坏磁盘(/dev/hda)复制到新磁盘(/dev/hdb)，忽略读取时遇到的错误(noerror)，当遇到不能访问的块时用适当数量的空值填充输出(sync)。
但是dd有几个缺点：首先是速度太慢；然后是不显示进度信息，直到完成前它都是沉默的；不重新尝试失败的读取，这会减少能从坏盘恢复的数据量。因此在这里介绍另一个软件——ddrescue，可以从 http://www.gnu.org/software/ddrescue/ddrescue.html 获取最新版（Fedora8用户可以直接用yum install dd_rescue安装） 。目前ddrescue最新版本是1.7，直接下载链接： http://ftp.gnu.org/gnu/ddrescue/ddrescue-1.7.tar.bz2
编译、安装后，可以使用下面命令完成相同的任务：
ddrescue --max-retries=-1 /dev/hda /dev/hdb
其中max-retries=-1参数表示无论遇到多少错误都不要停止。程序从hda读取数据并写到hdb中时，不断更新各项数据，可以方便地查看工作进行情况。
在ddrescue结束磁盘复制后，在新硬盘上运行e2fsck，以消除原始磁盘的坏块引起的文件系统错误。由于肯定会有大量错误，可以用-y参数运行e2fsck，指示e2fsck对每个问题都回答yes：
e2fsck -y /dev/hdb
此时，可以使用mount命令挂载文件系统，看看数据的恢复情况了。记得检查驱动器根目录下的lost+found文件夹，fsck把不能正确链接的文件和目录放在了这个文件夹里。
