Recent pushes to illumos-gate (15137) would seem to enable our ability to replace our UFS ramdisk root with a ZFS ramdisk root. This will be useful most notably for solving UFS’s Y2038 problems (UFS stores 32-bit time on disk).
When we bring this up, we’ll need to take into account:
- What happens when root@global has a zfs filesystem (even legacy-mounted) and pool to play with?
- Will this affect Triton Head Nodes or Compute Nodes (USB booting HN-to-SmartOS, USB booting iPXE CN, or PXE-to-iPXE chaining CN)?
- smartos-live will have to build a ZFS ramdisk root instead of a UFS one. Likewise a build zone will have to have permissions to construct it.
Toomas Soome commented on 2025-02-18T17:06:49.233-0500:
The current implementation does:
add memcmp (asm) and memstr.c build into unix, out from the genunix, because uncompress functions are using them.
build zle, lzjb, lz4 and gzip code with unix, out from the zfs module, so we can use them in unix and share with zfs.
add API to set bop properties to expose pool and boot dataset guids, so the zfs_mountroot() in zfs module can mount the root file system.
create bootrd_zfs.c module to be used from unix as krtld is linking the kernel. The bootrd_zfs is as minimal as possible, we assume the pool is created with 'zpool create -d' to disable all features. We do support zle, lzjb, lz4 and gzip because they are small and gzip is already in unix. Once we have rootfs mounted, the startup can perform zpool upgrade, if needed. usr dataset can be set readonly=on while image is prepared or during the system startup in fs-root when we mount it.
to signal bootrd_zfs that we are going to use pool from ramdisk for rootfs, we expect to have property set zfs-rootdisk-path=/ramdisk:a - zfs-rootdisk-path is also telling zfs_mountroot() where is the device with pool.
Add check to loader to avoid exporting zfs properties when zfs-rootdisk-path is set – it is not strictly needed as bootrd_zfs will replace the value of those properties, but we will reduce confusion about values used there.
In my testing, the zones pool does not create any confusion with zfs on ramdisk, the smartos does behave the same as with ufs on ramdisk.
From bootloaders perspective, we need to be able to pass zfs-rootdisk-path=/ramdisk:a property to the kernel (and no fstype=ufs).
The pool construction in build zone is likely the second big issue, my current guess is to utilize libzpool for this purpose, so we would need to create tool to create and update pool with libzpool interfaces.