john_doe said:
Have you tried to bisect[1] the changes in /usr/src/sys/boot?
I would if I had a version that I knew didn't have the trouble. This is the first and only root/boot on zfs that I've done.
john_doe said:
I'm pretty sure it was introduced in HEAD fairly recently, about a half year ago or less but ZFSBoot was available for more than a year.
By "it", do you mean the capability to boot from zfs in general or were you referring to a specific piece of code?
I may be just a confused newbie, but aren't gptzfsboot and zfsboot two different things? I got the impression from the sparse documentation I was able to find that gptzfsboot was a revamped zfsboot designed to find your zfs volumes on a gpt partition whereas zfsboot was for dedicated disks. Is that not correct?
john_doe said:
Not sure about -STABLE, but you can try to revert
r198420 on -CURRENT.
I'm not running on -CURRENT and, unfortunately, this isn't a machine I can just tear down and reinstall.
I read through that and the only thing that stands out is "If multiple partitions exist on a disk, probe them all." So maybe what we have happening is gptzfsboot (or zfsboot??) is scanning the full contents of all partitions on all disks to find the zfs volume.
If that's what's happening, you'd think it would be pretty quick in my case if it were working correctly. There are only two partitions per disk as shown by
# gpart show
:
Code:
=> 34 976773101 ad4 GPT (466G)
34 128 1 freebsd-boot (64K)
162 976772973 2 freebsd-zfs (466G)
=> 34 976773101 ad6 GPT (466G)
34 128 1 freebsd-boot (64K)
162 976772973 2 freebsd-zfs (466G)
=> 34 976773101 ad8 GPT (466G)
34 128 1 freebsd-boot (64K)
162 976772973 2 freebsd-zfs (466G)
=> 34 976773101 ad10 GPT (466G)
34 128 1 freebsd-boot (64K)
162 976772973 2 freebsd-zfs (466G)
john_doe said:
[1] you can speed up testing by using qemu with real devices, e.g.# echo -D >/boot.config
# qemu -nographic -drive file=/dev/ada0 -drive file=/dev/ada1
I just tried qemu as you suggested (good tip!) and I'm seeing less than 15 seconds time at the problem spot with 4GB of RAM like so:
# qemu -nographic -m 4G -drive file=/dev/ad4 -drive file=/dev/ad6 -drive file=/dev/ad8 -drive file=/dev/ad10
It's even faster with the default 128MB of RAM.
Would I be correct in my assessment that the difference lies in BIOS? We're using the same physical devices and the same boot code, so the only real difference is the BIOS. I suppose the type of disk device emulated by qemu might be different (old IDE vs. AHCI SATA), though.
There are a couple of things I can try in BIOS that might have an impact. I'll try those various things and report back.