Clone a ZFS-root
A user wanted to clone an existing ZFS-root system to another disk so I wrote clone-gptzfsroot.sh, which behaves a bit like create-zfsboot-gpt_livecd.sh when it comes to creating GPT labels and partition etc.
This script is useful not only when converting from an MBR style ZFS-root to GPT, but also when shrinking your root-pool, moving it from mirror to raidz or just cloning your system to another disk. I have only tested this with a system created by create-zfsboot-gpt_livecd.sh, so I'm not sure if other setups will convert without changing code in the script.
Child filesystems with manageBE
For some time now I had changes to manageBE in my working copy that include the support of child-filesystems in boot-environments. Some people would like to have a /var, /usr as a seperate filesystem and managed within their BEs. OpenSolaris? allows this by default for /var, theoretically this should be possible with every other filesystem too.
I did some merging and fine-tuning today and now the stuff is public! I also included the automated updating of a BE from source. Support for freebsd-update is somewhat limited as 8.0-RELEASE currently does not come with a ZFS enabled bootloader by default. So a freebsd-update can render your system unable to boot! Using src-upgrade with LOADER_ZFS_SUPPORT="yes" in /etc/make.conf is recommended.
If anyone needs help with converting their current manageBE setup, leave a comment and I'll try to help.
Happy Christmas everyone!
booting from raidz works, kind of
I finally got around testing ZFS-Root with RaidZ. As long as the root-filesystem is located in the top-level filesystem of the pool, everything works! So booting from RaidZ is possible in FreeBSD and manageBE/create-zfsboot-gpt_livecd.sh supports doing exactly this.
Only problem is, putting the root-filesystem in a sub-level filesystem, as I do it for manageBE, results in a ZFS: out of temporary buffer space when booting. There are some discussions on the freebsd-current mailinglist about booting from raidz configurations but until now, nothing substential has been commited. So I see booting from raidz as experimental for now.
UPDATE: I had some time today to track the ZFS: out of temporary buffer space error when booting from raidz and having the rootfs in a sub-level filesystem. Taking a look at zfs_alloc_temp() in src/sys/boot/zfs/zfsimpl.c, which prints this error message, and going from that to zio_read(), I figured that this will only be triggered if compression for the rootfs is turned on. A quick test confirmed my assumption! So I will turn off the compression for now and file a bug!
ZFS user properties FTW!
Currently I'm working on using freebsd-update in manageBE to upgrade and update newly created boot-environments.
For this I needed to create a freebsd-update working-dir per boot-environment, in my testing version they reside under <poolname>/ROOT/freebsd-update/<BE_name>. Problem was, now "manageBE list" also will list stuff under this filesystem as a boot-environment. But I want to keep everything in this namespace so users will not be baffled.
Cool thing is, ZFS supports user-defined properties! You can use any name for the property, as long as it is 256 characters max and not a name used by ZFS itself. So I created my own property like this: zfs set freebsd:boot-environment=1 rootpool/ROOT/my_bootenvironmet
Now the manageBE list routine just checks if the filesystem has set this property to 1 and if not, it wont list this filesystem.
Of course, now that the filesystems have a property I can check, I really know what filesystem is a boot-environment, so I improved checking for that. See [52] for details.
Hopefully, someday the bootloader can parse this user-property too, so it can list this filesystem as a possible boot-environment to boot!
code stuff by cryx
Here I will talk about tech and the tech I try to solve in my code, maybe some random things too! :-)
rss