Copyright © 2009, The e. Publishing Dept. of Morpho Studio (Spruce Int. Found.® ) All rights reserved.
今天无意中发现一个zfs文件系统的bug :
zpool create命令可以接受rpool所在物理磁盘分区所对应的raw设备作为池的成员设备创建新的ZFS存储池,此操作可导致系统重新引导时GRUB程序装载stage失败,系统将无法正常引导。
此问题的详细描述:
对于使用ZFS作为根文件系统的opensolaris和solaris系统,
系统分区通常是基于物理磁盘上第一个solaris分区上的0号盘片创建的,
如下是一个典型的2块磁盘的镜像系统盘配置:
root@egoodbtr-rac1:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rpool 15.9G 4.29G 11.6G 27% ONLINE -
root@egoodbtr-rac1:~# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c8t0d0s0 ONLINE 0 0 0
c8t1d0s0 ONLINE 0 0 0
errors: No known data errors
从逻辑上讲,c8tod0s0 的完整设备号是 c8t0d0p1s0 (磁盘控制器号、通道号、磁盘号、分区号、盘片号)
或许有人说这是错的,因为传统的solaris分区在一个物理磁盘上只能有一个!
但是通过我的实践证明,现在事实是solaris分区在最近版本的solaris系统中已经更新为solaris2版本,一个物理磁盘上可以创建多个solaris2类型的分区,并且创建ZFS存储池时zpool create 命令接受诸如c8t0d0p1 (磁盘控制器号、通道号、磁盘号、分区号、盘片号)这样的RAW设备。
例如:
root@egoodbtr-rac1:~# zpool create dpool raidz c8t0d0p1 c8t1d0p1
root@egoodbtr-rac1:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
dpool 31.8G 149K 31.7G 0% ONLINE -
rpool 15.9G 4.29G 11.6G 27% ONLINE -
root@egoodbtr-rac1:~# zpool status
pool: dpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
dpool ONLINE 0 0 0
raidz1 ONLINE 0 0 0
c8t0d0p1 ONLINE 0 0 0
c8t1d0p1 ONLINE 0 0 0
errors: No known data errors
pool: rpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c8t0d0s0 ONLINE 0 0 0
c8t1d0s0 ONLINE 0 0 0
errors: No known data errors
如果是对物理磁盘上的第二个solaris分区(实际为solaris2分区类型) 进行以上操作,实践证明不会有任何问题:但是从逻辑上讲:对于根文件系统所在的磁盘:rpool 的成员设备 /dev/rdsk/c8t0d0s0 是 设备/dev/rdsk/c8t0d0p1 的次级设备。或许把solaris分区比作windows扩展分区、把solaris分区上的盘片比作windows扩展分区上的逻辑驱动器可能不够恰当,但是这有助于大家理解solaris系统分区和盘片的层次关系。
在每个逻辑驱动器作为RAW设备使用的情况下,还能将整个扩展分区作为RAW设备使用,这个听上去是不是有点荒谬?当事实证明ZFS存储池的确可以这么建,难道是因为使用动态条带的原因?
虽然我不知道是在如此创建新存储池时,还是在之后消此新建的存储池时,造成的对某些特殊磁盘数据的破坏导致了再次引导系统时GRUB加载失败,系统无法继续引导的问题,但是我觉得zpool create命令可以接受rpool所在物理磁盘分区所对应的raw设备作为池的成员设备创建新的ZFS存储池,这一设计是非常不合理的,并且因为其“出乎意料得”导致系统无法引导(说“出乎意料”是因为创建和销毁这一包含“特殊成员设备”的存储池时,系统未有任何警告或提示),所以我认为这是ZFS的一个重大bug。
今天无意中发现一个zfs文件系统的bug :
zpool create命令可以接受rpool所在物理磁盘分区所对应的raw设备作为池的成员设备创建新的ZFS存储池,此操作可导致系统重新引导时GRUB程序装载stage失败,系统将无法正常引导。
此问题的详细描述:
对于使用ZFS作为根文件系统的opensolaris和solaris系统,
系统分区通常是基于物理磁盘上第一个solaris分区上的0号盘片创建的,
如下是一个典型的2块磁盘的镜像系统盘配置:
root@egoodbtr-rac1:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rpool 15.9G 4.29G 11.6G 27% ONLINE -
root@egoodbtr-rac1:~# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c8t0d0s0 ONLINE 0 0 0
c8t1d0s0 ONLINE 0 0 0
errors: No known data errors
从逻辑上讲,c8tod0s0 的完整设备号是 c8t0d0p1s0 (磁盘控制器号、通道号、磁盘号、分区号、盘片号)
或许有人说这是错的,因为传统的solaris分区在一个物理磁盘上只能有一个!
但是通过我的实践证明,现在事实是solaris分区在最近版本的solaris系统中已经更新为solaris2版本,一个物理磁盘上可以创建多个solaris2类型的分区,并且创建ZFS存储池时zpool create 命令接受诸如c8t0d0p1 (磁盘控制器号、通道号、磁盘号、分区号、盘片号)这样的RAW设备。
例如:
root@egoodbtr-rac1:~# zpool create dpool raidz c8t0d0p1 c8t1d0p1
root@egoodbtr-rac1:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
dpool 31.8G 149K 31.7G 0% ONLINE -
rpool 15.9G 4.29G 11.6G 27% ONLINE -
root@egoodbtr-rac1:~# zpool status
pool: dpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
dpool ONLINE 0 0 0
raidz1 ONLINE 0 0 0
c8t0d0p1 ONLINE 0 0 0
c8t1d0p1 ONLINE 0 0 0
errors: No known data errors
pool: rpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c8t0d0s0 ONLINE 0 0 0
c8t1d0s0 ONLINE 0 0 0
errors: No known data errors
如果是对物理磁盘上的第二个solaris分区(实际为solaris2分区类型) 进行以上操作,实践证明不会有任何问题:但是从逻辑上讲:对于根文件系统所在的磁盘:rpool 的成员设备 /dev/rdsk/c8t0d0s0 是 设备/dev/rdsk/c8t0d0p1 的次级设备。或许把solaris分区比作windows扩展分区、把solaris分区上的盘片比作windows扩展分区上的逻辑驱动器可能不够恰当,但是这有助于大家理解solaris系统分区和盘片的层次关系。
在每个逻辑驱动器作为RAW设备使用的情况下,还能将整个扩展分区作为RAW设备使用,这个听上去是不是有点荒谬?当事实证明ZFS存储池的确可以这么建,难道是因为使用动态条带的原因?
虽然我不知道是在如此创建新存储池时,还是在之后消此新建的存储池时,造成的对某些特殊磁盘数据的破坏导致了再次引导系统时GRUB加载失败,系统无法继续引导的问题,但是我觉得zpool create命令可以接受rpool所在物理磁盘分区所对应的raw设备作为池的成员设备创建新的ZFS存储池,这一设计是非常不合理的,并且因为其“出乎意料得”导致系统无法引导(说“出乎意料”是因为创建和销毁这一包含“特殊成员设备”的存储池时,系统未有任何警告或提示),所以我认为这是ZFS的一个重大bug。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
蝴蝶
20th,Aug.2009 8:30 pm GMT+1 最后更新
Copyright
© 2009,The e. Publishing Dept. of Morpho Studio (Spruce Int. Found.®
) All rights reserved.







发表评论 评论 (1 个评论)