Booting from ZFS raidz

Doug Rabson dfr at
Sat Dec 20 06:23:10 PST 2008

On 19 Dec 2008, at 21:46, Stefan Bethke wrote:

> Am 17.12.2008 um 19:25 schrieb Doug Rabson:
>> I've been working on adding raidz and raidz2 support to the boot  
>> code and I have a patch which could use some testing if anyone here  
>> is interested. This 
>>  adds support for raidz and raidz2. The easiest way to prepare a  
>> bootable pool is to put a GPT boot partition on each disk that will  
>> make up the raidz pool and install gptzfsboot on the boot partition  
>> of every drive.
> Not sure I did things the right way, and it doesn't appear to be  
> working correctly. I'm trying this in VMware Fusion, with three SCSI  
> disks, which I configured like this:
> Updated sources yesterday, then applied the patch and added  
> LOADER_ZFS_SUPPORT?=YES to make.conf, then make buildworld  
> buildkernel.
> Created a GPT label and one partition on each of the three drives:
> 	gpart create -s gpt $1
> 	gpart add -b 34 -s 128 -t freebsd-boot $1
> 	gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 $1
> 	gpart add -b 512 -s 41900000 -t freebsd-zfs $1
> 	gpart list $1
> (The disks are 20GB each)
> root at freebsd-current:~# gpart list da3
> ...
> Created a raidz pool:
> # zpool create tank raidz da1p2 da2p2 da3p2
> Populated the filesystem with
> # cd /usr/src && make installworld installkernel distribution  
> DESTDIR=/tank
> Added zfs_load="YES" and vfs.root.mountfrom="zfs:tank" to loader.conf
> When trying to boot, I get a number of "error 4 lba xxx", then "ZFS:  
> i/o error - all block copies are unavailable". The loader starts up,  
> but cannot load /boot/loader.conf or /boot/device.hints. The LBA  
> blocks are all towards the end of the disks, in the 4294626000 and  
> up range.

I did my testing in vmware too with a slightly different configuration  
(4x2G virtual disks in various arrangements).

I just tried to reproduce your exact sequence of steps and it worked  
fine up to the mountroot prompt. I don't think ZFS likes having the  
root filesystam at the root of the pool. A few things to check:

1. Are you absolutely sure you are using gptzfsboot built with the  
patch - the steps you list above show you building it but not  
installing it on the system which is initialising the pool.

2. Do you have the changes from r186243? This might cause something  
like your problem - there was an overflow in the code which looked up  
a ZFS object from an inode number.

3. I'm a little confused as to how you are getting LBA numbers above  
4G - a 20G virtual disk should only have 40 million 512 byte blocks.

More information about the freebsd-fs mailing list