ZFS 预测性自愈在OpenSolaris中的一些问题

    我在下面介绍了一个ZFS的demo，是将以前在Solaris下的预测性自愈的实验放到OpenSolaris上来实验，但是在最后的时候却出现了一些问题，我现在把整个demo的过程写在下面，大家一起看看是什么问题？我现在认为问题可能是出现在我使用的是文件作为存储池资源，在最后要使用#zpool replace 命令替换硬盘的时候，不能使用文件信息。但是，问题的关键是，zfs并没有在OpenSolaris下实现应有的自愈功能，甚至于在我重起电脑后，之前的存储池数据都不能读取的情况。
 

一、 首先建立一个镜像结构的存储池
Tonsen@opensolaris:/# mkdir /mypool
Tonsen@opensolaris:/# mkfile -n 100m /mypool/a /mypool/b
Tonsen@opensolaris:/# zpool create mpool mirror  /mypool/a /mypool/b
 
 
二、 查看我们创建的存储池的健康状态,可以看到/mypool/a和/mypool/b组成了一个镜像池，并且这个池是online也没有任何错误。
Tonsen@opensolaris:/# zpool status
  pool: mpool
 state: ONLINE
 scrub: none requested
config:

        NAME           STATE     READ WRITE CKSUM
        mpool          ONLINE       0     0     0
          mirror       ONLINE       0     0     0
            /mypool/a  ONLINE       0     0     0
            /mypool/b  ONLINE       0     0     0

errors: No known data errors
 
 
三、 接下来我们随意找一个文件放到存储池中，并使用MD5加密该文件，以便于后面进行完整性检查。
Tonsen@opensolaris:/# cd /mpool
Tonsen@opensolaris:/mpool# cp /export/home/Tonsen/test_zfs.rar .
Tonsen@opensolaris:/mpool# digest -v  -a md5 test_zfs.rar
md5 (test_zfs.rar) = 86ca9bc8a35182195e426831b199d8bd
 
 
四、 然后就进入有趣的环节了，我们将镜像中的一个盘使用随机数据将它覆盖掉，等同于模拟了对一个盘产生的大数据冲突。
Tonsen@opensolaris:/mpool# dd if=/dev/urandom of=/mypool/a bs=1024 count=20480
20480+0 records in
20480+0 records out
20971520 bytes (21 MB) copied, 1.33936 s, 15.7 MB/s
 
 
五、然后我们再检查一下存储池的状态。从显示结果我们发现，它还是健康的，没有任何错误，为什么会出现这种情况呢？因为所有的ZFS的数据目前都保存在主存中，所以现在并没有检测出在磁盘上出现的问题。
Tonsen@opensolaris:/mpool# zpool status
  pool: mpool
 state: ONLINE
 scrub: none requested
config:

    NAME           STATE     READ WRITE CKSUM
    mpool          ONLINE       0     0     0
      mirror       ONLINE       0     0     0
        /mypool/a  ONLINE       0     0     0
        /mypool/b  ONLINE       0     0     0

errors: No known data errors
 
 
六、为了让ZFS进行必要的检查，也使得我们刚刚制作的错误数据发生作用，我们可以重新进行一次数据的导入，以便于系统刷新一次主存和cache。 但是我在执行下面的操作时，因为数据损坏，是不能将mpool这个存储池重新import回来的，所以，下面的操作是有问题的，大家不要仿效。
Tonsen@opensolaris:/mpool# cd /
Tonsen@opensolaris:/# zpool export mpool
Tonsen@opensolaris:/# zpool import -d /mypool mpool  这步将不能顺利执行
 
七、ZFS检测出了错误呢？我们接下来查看一下。我们可以发现，ZFS确实发现了这个错误，并且已经更改过了，真神奇。它甚至还给我们提供了接下来的操作计划。
Tonsen#zpool status
 
九、我们来跟踪一下ZFS实现预测性自愈的过程吧。在shell中输入下面的程序，可以发现，ZFS确实发现了这个错误。它甚至还给我们提供了一个说明的网站，让我们去查看相关信息。但是在我根据它提供的信息进行#zpool replace操作时，却不能成功，显示说我所使用的设备不是/dev/dsk中的设备，在这里我使用的是自建的文件，所以在这个目录下是找不到的。
Tonsen@opensolaris:/mpool# zpool scrub mpool;sleep 1;zpool status
  pool: mpool
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
    invalid.  Sufficient replicas exist for the pool to continue
    functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-4J
 scrub: scrub completed after 0h0m with 0 errors on Wed Jun 25 03:32:30 2008
config:

    NAME           STATE     READ WRITE CKSUM
    mpool          DEGRADED     0     0     0
      mirror       DEGRADED     0     0     0
        /mypool/a  UNAVAIL      0     0     0  corrupted data
        /mypool/b  ONLINE       0     0     0
 

十，重起电脑，我希望可以在重起后为我建立的镜像系统提供自愈的条件，但是事与愿违，下面就是结果，我之前未损坏的盘也不能打开了。
Tonsen@opensolaris:~# zpool status
  pool: mpool
 state: UNAVAIL
status: One or more devices could not be opened.  There are insufficient
    replicas for the pool to continue functioning.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-3C
 scrub: none requested
config:

    NAME           STATE     READ WRITE CKSUM
    mpool          UNAVAIL      0     0     0  insufficient replicas
      mirror       UNAVAIL      0     0     0  insufficient replicas
        /mypool/a  UNAVAIL      0     0     0  cannot open
        /mypool/b  UNAVAIL      0     0     0  cannot open
 

    本来是希望可以为大家制作一个进行预测性自愈的demo的，但是发现了OpenSolaris下面的这些问题，后面我将进一步寻找这个问题的原因，也希望大家熟悉ZFS的能帮我解答，谢谢。