Possible (or smart) to put freebsd-boot on USB stick for root-on-ZFS?

[Jason Birch]

>
> The bootcode changes rarely, and is usually not a problem.  Having a
> separate, duplicate /boot is sometimes done for geli(8).  It's kind of a
> pain, because changes must be made in two places.  For a mirror with the OS
> on it, I'd put a freebsd-boot partition on each drive, manually install the
> bootcode to each, and call it good.
>

Thank you for all your responses and education! This is pretty much how
I've attacked the problem. For the record, I actually prepared all of this
ahead of time, and then noticed that 10.1's install options actually
include ZFS on root, so installation was super simple, and I was able to
scrap my preparation

... kind of. Though the maths seems to work out to me, it ends up aligning
the freebsd-zfs position 'awkwardly'. In my head I thought it would work
okay - 1064 512B blocks is a round 133 4KB blocks, which these SSDs report
as their stripe size. Nonetheless, fragmentation of the pool is off the
charts...

# gpart show -l ada0 ada1
=>       34  156301421  ada0  GPT  (75G)
         34          6        - free -  (3.0K)
         40       1024     1  gptboot0  (512K)
       1064  156300384     2  zfs0  (75G)
  156301448          7        - free -  (3.5K)

=>       34  156301421  ada1  GPT  (75G)
         34          6        - free -  (3.0K)
         40       1024     1  gptboot1  (512K)
       1064  156300384     2  zfs1  (75G)
  156301448          7        - free -  (3.5K)

# zpool status zroot
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0 in 0h3m with 0 errors on Mon Apr 13 00:27:34 2015
config:

        NAME          STATE     READ WRITE CKSUM
        zroot         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            gpt/zfs0  ONLINE       0     0     0
            gpt/zfs1  ONLINE       0     0     0

errors: No known data errors

# zpool get fragmentation zroot
NAME   PROPERTY       VALUE  SOURCE
zroot  fragmentation  59%    -


It remains to be seen (to me) if this is a problem or shortcoming of
bsdinstall(8), or totally fine and expected behaviour. I'm thought the gap
between blocks 1024 and 1064 that aren't reported as "free" as perhaps
containing the label for adaXp2, and wondered if that was pushing it out a
bit, but they don't seem to contain any bits at all.