原文 ,可以下附件
该系列以前的文章：
OpenSolaris新特性解析之一: opensolaris之前身今世
这篇帖子我想介绍下ZFS，这个文件系统LINUX的老大LINUS眼馋好久了，他想把ZFS移植到LINUX，取代EXT3，成为下一代LINUX内核默认的文件系统，好像两边的老大一直在讨论这个事情，也不知道现在商量得怎么样了，呵呵。
在具体解释之前，先说说传统文件系统和卷管理的一些缺点。
我们知道在NTFS和EXT3里面我们划分分区的时候，分区的大小在那个时候就定义好了，比如我们在windows下面把硬盘划了2个区，一个C盘，一个 D盘，我们在进行分区的时候就把C和D的大小都定义好了，比如C盘20个G，D盘20个G，以后随着我们不断的安装软件，下载电影，C盘的空间越来越小，终于有一天，C盘的空间只有1个G不到了，如果我们这个时候要安装个2个G的软件，这个软件只能安装到C盘，那我们的空间就不够了，但是这个时候我们的D 盘还有10个G的空间，这真是让人烦，明明我的硬盘还有剩余的空间，但是我的软件却安装不上了，有的朋友说这个不要紧，用PGMAGIC，重新划分空间，但是对于企业级的服务器，你敢这样用吗？这是问题之一。
在企业应用里面，还有一个比较常见的问题，比如我有个专门存储数据的硬盘，这个硬盘平时挂载在/data之下，随着企业的数据越来越多，这个盘迟早有装满的一天，这个时候我想加块硬盘，把这两块硬盘都挂载到/data之下，并且骗过操作系统，让操作系统认为在/data下面只有一块连续的硬盘，针对这种应用，卷管理应时而生，但是卷管理过程和命令常常比较复杂，让人觉得这个东西不是好弄的。这是问题之二。
针对这两个问题，企业级的文件系统ZFS诞生了，不得不说这又是SUN的一次杰作。
ZFS的设计思想认为我们对硬盘的访问为什么不能就像我们对内存的访问一样，我们的数据存储在内存中时，并不会说内存条上的那个CHIP满了我们的数据就不能放了，只要整个内存还有空间我们的数据就能够放入内存（和问题一对应）。如果我们的内存不够了，我们只需要加根内存条就能够使用了，操作系统并不会认为这根内存条和以前的内存条有什么不同。（对应问题二）。
好了，弄清楚了ZFS的设计思路，我们可以说些ZFS的细节。
ZFS是一个128位的文件系统，存储量级是Zetta级，1Z=1024的3次方个T，而一个T又等于1024个G，我们可以看出zfs是一个海量级的文件系统。有的朋友可能要说搞得那么大有什么用，我们先看看16位的文件系统是个什么情况，我们现在的高清电影一集就是4.3个G左右，在16位的文件系统里面能存得下吗？我们知道2的32次方才等于4G，也就是说要存放这样的高清电影，32位的文件是最低配置，否则如果单个文件就超过4G，那32位的文件系统是支持不了的。那对于我们的企业应用又如何呢？我们所使用的数据库在物理上都是对应的数据库文件，如果企业和科学研究的数据量很大，单个数据库文件的大小至少上百个G，所以我们知道ZFS的128设计的好处了，按照128位的宽度，用zfs存放整个地球的信息都是没有问题的。
在ZFS的架构里，最下面是存储池，所有的存储介质都放在这个存储介质里面，然后再在这个存储池上面布ZFS的文件系统，为了说明问题，让我们先看一个例子，大家如果能做一做，我相信不会浪费大家的时间。
先切换到root用户
#su
我们使用文件盘而不是实际的物理硬盘来建立存储池，当然使用物理盘也是一样的，我们先建立5个文件盘，每个文件盘100M
#mkfile 100M disk1 disk2 disk3 disk4 disk5
接着我们利用zpool create命令来使用这些文件盘建立存储池tank，注意了在ZFS里面是不需要对磁盘进行分区和格式化的，系统会为我们做这一切的工作，并且速度很快.
#zpool create tank `pwd`/disk1 `pwd`/disk2 (这里你可以只使用disk1,zpool create tank `pwd`/disk1,也可以5个磁盘全用，zpool create tank `pwd`/disk1......`pwd`/disk5)
在这个命令之后我们利用zpool list来查看
#zpool list
结果如下,可以看到ZFS的存储池tank已经建立好了
NAME SIZE USED AVAILBLE CAP HEALTH ALTROOT
tank 191M 95.5K 191M ...........
在我们创建ZFS存储池的时候，系统已经默认在这个存储池上面创建了一个ZFS系统，名字和存储池的名字一样，并且已经为我们挂载好了，方便吧，并且这种挂载是持久的，也就是说我们重启后，这种挂载关系还在，并不需要我们去修改vfstable之类的文件，我们用zfs list来查看
#zfs list
结果如下,其中根目录下的tank目录是系统自动为我们创建的，不需要我们手动
NAME USED AVAIL REFER MOUNTPOINT
TANK 108K 159M 18K /tank
接下来我们可以根据自己的需要在这个存储池上创建其他的ZFS文件系统。
#zfs create tank/test1 (tank是存储池的名字，表明我们要在tank这个存储池上建立test1这个ZFS文件系统)
相应的我们可以创建test2
#zfs create tank/test2
用zfs list来看下效果
NAME USED AVAIL REFER MOUNTPOINT
TANK 108K 159M 18K /tank
tank/test1 18K 159M 18K /tank/test1
tank/test2 18K 159M 18K /tank/test2
这里需要注意两点：一是/tank/test1这样的目录是系统自动为我们创建和挂载的,二是我们可以看到test1和test2他们的可用空间是一样的，都等于存储池的可用空间159M,这样就解决了我们前面提到的问题一，在ZFS里面分区的大小是自动扩展的，并不象windows和linux一样，需要事先确定。
我们也可以动态设置ZFS文件系统的挂载点，比如:
#zfs set mountpoint=/mnt tank/test1
#zfs list
NAME USED AVAIL REFER MOUNTPOINT
TANK 108K 159M 18K /tank
tank/test1 18K 159M 18K /mnt
tank/test2 18K 159M 18K /tank/test2
改变之后的挂载关系也是持久的，重启之后也会保持，不需要我们去改变vfstable之类的文件。
下面我们说说前面提到的第二个问题在ZFS里面的解决办法，如果disk1和disk2都被用完了，我想要加硬盘怎么办？这在ZFS里面很简单
#zpool add tank `pwd`/disk3 (将disk3加入到tank这个存储池里面)
#zpool list
NAME SIZE USED AVAILBLE CAP HEALTH ALTROOT
tank 286M 185K 286M ...........
我们可以看到存储池的可用空间已经变大，我们还可以详细看看
#zpool status
这个命令的输出比较长，我就不列出来了，在里面我们可以看到在存储池里面有disk1 disk2 disk3三个盘。
前面提到的问题二，我们看到在ZFS里面有了非常简洁的解决办法。
如果我要撤销ZFS的文件系统怎么办呢？2个命令就可以非常干净的把ZFS撤销掉
#zfs destroy tank/test1
#zfs destroy tank/test2
#zpool destroy tank
总的思路就是先撤销掉ZFS文件系统，用zfs destroy命令，然后撤销掉ZFS文件系统使用的存储池，用zpool destroy命令。
原文 ,可以下附件
该系列以前的文章：
OpenSolaris新特性解析之一: opensolaris之前身今世
这篇帖子我想介绍下ZFS，这个文件系统LINUX的老大LINUS眼馋好久了，他想把ZFS移植到LINUX，取代EXT3，成为下一代LINUX内核默认的文件系统，好像两边的老大一直在讨论这个事情，也不知道现在商量得怎么样了，呵呵。
在具体解释之前，先说说传统文件系统和卷管理的一些缺点。
我们知道在NTFS和EXT3里面我们划分分区的时候，分区的大小在那个时候就定义好了，比如我们在windows下面把硬盘划了2个区，一个C盘，一个 D盘，我们在进行分区的时候就把C和D的大小都定义好了，比如C盘20个G，D盘20个G，以后随着我们不断的安装软件，下载电影，C盘的空间越来越小，终于有一天，C盘的空间只有1个G不到了，如果我们这个时候要安装个2个G的软件，这个软件只能安装到C盘，那我们的空间就不够了，但是这个时候我们的D 盘还有10个G的空间，这真是让人烦，明明我的硬盘还有剩余的空间，但是我的软件却安装不上了，有的朋友说这个不要紧，用PGMAGIC，重新划分空间，但是对于企业级的服务器，你敢这样用吗？这是问题之一。
在企业应用里面，还有一个比较常见的问题，比如我有个专门存储数据的硬盘，这个硬盘平时挂载在/data之下，随着企业的数据越来越多，这个盘迟早有装满的一天，这个时候我想加块硬盘，把这两块硬盘都挂载到/data之下，并且骗过操作系统，让操作系统认为在/data下面只有一块连续的硬盘，针对这种应用，卷管理应时而生，但是卷管理过程和命令常常比较复杂，让人觉得这个东西不是好弄的。这是问题之二。
针对这两个问题，企业级的文件系统ZFS诞生了，不得不说这又是SUN的一次杰作。
ZFS的设计思想认为我们对硬盘的访问为什么不能就像我们对内存的访问一样，我们的数据存储在内存中时，并不会说内存条上的那个CHIP满了我们的数据就不能放了，只要整个内存还有空间我们的数据就能够放入内存（和问题一对应）。如果我们的内存不够了，我们只需要加根内存条就能够使用了，操作系统并不会认为这根内存条和以前的内存条有什么不同。（对应问题二）。
好了，弄清楚了ZFS的设计思路，我们可以说些ZFS的细节。
ZFS是一个128位的文件系统，存储量级是Zetta级，1Z=1024的3次方个T，而一个T又等于1024个G，我们可以看出zfs是一个海量级的文件系统。有的朋友可能要说搞得那么大有什么用，我们先看看16位的文件系统是个什么情况，我们现在的高清电影一集就是4.3个G左右，在16位的文件系统里面能存得下吗？我们知道2的32次方才等于4G，也就是说要存放这样的高清电影，32位的文件是最低配置，否则如果单个文件就超过4G，那32位的文件系统是支持不了的。那对于我们的企业应用又如何呢？我们所使用的数据库在物理上都是对应的数据库文件，如果企业和科学研究的数据量很大，单个数据库文件的大小至少上百个G，所以我们知道ZFS的128设计的好处了，按照128位的宽度，用zfs存放整个地球的信息都是没有问题的。
在ZFS的架构里，最下面是存储池，所有的存储介质都放在这个存储介质里面，然后再在这个存储池上面布ZFS的文件系统，为了说明问题，让我们先看一个例子，大家如果能做一做，我相信不会浪费大家的时间。
先切换到root用户
#su
我们使用文件盘而不是实际的物理硬盘来建立存储池，当然使用物理盘也是一样的，我们先建立5个文件盘，每个文件盘100M
#mkfile 100M disk1 disk2 disk3 disk4 disk5
接着我们利用zpool create命令来使用这些文件盘建立存储池tank，注意了在ZFS里面是不需要对磁盘进行分区和格式化的，系统会为我们做这一切的工作，并且速度很快.
#zpool create tank `pwd`/disk1 `pwd`/disk2 (这里你可以只使用disk1,zpool create tank `pwd`/disk1,也可以5个磁盘全用，zpool create tank `pwd`/disk1......`pwd`/disk5)
在这个命令之后我们利用zpool list来查看
#zpool list
结果如下,可以看到ZFS的存储池tank已经建立好了
NAME SIZE USED AVAILBLE CAP HEALTH ALTROOT
tank 191M 95.5K 191M ...........
在我们创建ZFS存储池的时候，系统已经默认在这个存储池上面创建了一个ZFS系统，名字和存储池的名字一样，并且已经为我们挂载好了，方便吧，并且这种挂载是持久的，也就是说我们重启后，这种挂载关系还在，并不需要我们去修改vfstable之类的文件，我们用zfs list来查看
#zfs list
结果如下,其中根目录下的tank目录是系统自动为我们创建的，不需要我们手动
NAME USED AVAIL REFER MOUNTPOINT
TANK 108K 159M 18K /tank
接下来我们可以根据自己的需要在这个存储池上创建其他的ZFS文件系统。
#zfs create tank/test1 (tank是存储池的名字，表明我们要在tank这个存储池上建立test1这个ZFS文件系统)
相应的我们可以创建test2
#zfs create tank/test2
用zfs list来看下效果
NAME USED AVAIL REFER MOUNTPOINT
TANK 108K 159M 18K /tank
tank/test1 18K 159M 18K /tank/test1
tank/test2 18K 159M 18K /tank/test2
这里需要注意两点：一是/tank/test1这样的目录是系统自动为我们创建和挂载的,二是我们可以看到test1和test2他们的可用空间是一样的，都等于存储池的可用空间159M,这样就解决了我们前面提到的问题一，在ZFS里面分区的大小是自动扩展的，并不象windows和linux一样，需要事先确定。
我们也可以动态设置ZFS文件系统的挂载点，比如:
#zfs set mountpoint=/mnt tank/test1
#zfs list
NAME USED AVAIL REFER MOUNTPOINT
TANK 108K 159M 18K /tank
tank/test1 18K 159M 18K /mnt
tank/test2 18K 159M 18K /tank/test2
改变之后的挂载关系也是持久的，重启之后也会保持，不需要我们去改变vfstable之类的文件。
下面我们说说前面提到的第二个问题在ZFS里面的解决办法，如果disk1和disk2都被用完了，我想要加硬盘怎么办？这在ZFS里面很简单
#zpool add tank `pwd`/disk3 (将disk3加入到tank这个存储池里面)
#zpool list
NAME SIZE USED AVAILBLE CAP HEALTH ALTROOT
tank 286M 185K 286M ...........
我们可以看到存储池的可用空间已经变大，我们还可以详细看看
#zpool status
这个命令的输出比较长，我就不列出来了，在里面我们可以看到在存储池里面有disk1 disk2 disk3三个盘。
前面提到的问题二，我们看到在ZFS里面有了非常简洁的解决办法。
如果我要撤销ZFS的文件系统怎么办呢？2个命令就可以非常干净的把ZFS撤销掉
#zfs destroy tank/test1
#zfs destroy tank/test2
#zpool destroy tank
总的思路就是先撤销掉ZFS文件系统，用zfs destroy命令，然后撤销掉ZFS文件系统使用的存储池，用zpool destroy命令。
ZFS的用法就介绍到这里，更多的用法如何配置raid之类的，可以下载附件，总的来讲ZFS的使用是非常简单的。
最后想介绍下ZFS系统的一些设计原理，1是自我恢复，2是事务性的操作。这部分光说不容易说清楚，上几个图。
先看图1，ZFS里面我们的每一个文件的内容，ZFS都会帮我们存放一个校验和，这个校验和存放在这个文件的父目录的文件节点里，再看图2，
在传统的mirror设置里面，如果有一个盘里面的数据是坏的，系统并不能够检查出来，如果运气不好，应用程序可能会在存放坏数据的那个盘里面去读，这样读出来的就是坏数据，并且可能导致应用程序和OS的崩溃。我们再看图3，在ZFS里面如果遇到这样的情况，校验和会告诉系统说目前读到的数据是坏数据，这时系统会自动到另外一个盘里面去拿数据，并且在把另一个盘里面的数据向上传给应用程序的同时，会用好数据覆盖掉mirror盘里面的坏数据。这就是自我恢复。
关于事务性的操作，我们可以看图4，ZFS里面所有的操作都是事务性的，要么全做，要么不做，这就保证了我们文件系统的完整性。比如我们要修改图4里面左下方的两个文件，系统会在修改之前，先将这两个文件做拷贝，这就是copy on write,拷贝出来后，在拷贝的附件里面做我们的修改，只有等修改完成后，才会将这两个文件的父目录做一个拷贝，然后在拷贝里面作出修改，将文件指针指向最新的两个文件，这样的过程依次上推，直到根目录，根目录不会做拷贝的动作，直接是一个原子操作，将文件指针指向最新的节点，完成所有的修改操作。大家可以看到在这个过程中的任何一部掉电都不会影响到我们系统的文件完整性。
这部分就基本上更新完成了，后面我会写这个系列的第三部OpenSolaris新特性解析之三:SMF
ZFS的用法就介绍到这里，更多的用法如何配置raid之类的，可以下载附件，总的来讲ZFS的使用是非常简单的。
最后想介绍下ZFS系统的一些设计原理，1是自我恢复，2是事务性的操作。这部分光说不容易说清楚，上几个图。
先看图1，ZFS里面我们的每一个文件的内容，ZFS都会帮我们存放一个校验和，这个校验和存放在这个文件的父目录的文件节点里，再看图2，
在传统的mirror设置里面，如果有一个盘里面的数据是坏的，系统并不能够检查出来，如果运气不好，应用程序可能会在存放坏数据的那个盘里面去读，这样读出来的就是坏数据，并且可能导致应用程序和OS的崩溃。我们再看图3，在ZFS里面如果遇到这样的情况，校验和会告诉系统说目前读到的数据是坏数据，这时系统会自动到另外一个盘里面去拿数据，并且在把另一个盘里面的数据向上传给应用程序的同时，会用好数据覆盖掉mirror盘里面的坏数据。这就是自我恢复。
关于事务性的操作，我们可以看图4，ZFS里面所有的操作都是事务性的，要么全做，要么不做，这就保证了我们文件系统的完整性。比如我们要修改图4里面左下方的两个文件，系统会在修改之前，先将这两个文件做拷贝，这就是copy on write,拷贝出来后，在拷贝的附件里面做我们的修改，只有等修改完成后，才会将这两个文件的父目录做一个拷贝，然后在拷贝里面作出修改，将文件指针指向最新的两个文件，这样的过程依次上推，直到根目录，根目录不会做拷贝的动作，直接是一个原子操作，将文件指针指向最新的节点，完成所有的修改操作。大家可以看到在这个过程中的任何一部掉电都不会影响到我们系统的文件完整性。
这部分就基本上更新完成了，后面我会写这个系列的第三部OpenSolaris新特性解析之三:SMF
阅读(1926) | 评论(0) | 转发(0) |
