I wouldn’t assume that those benchmarks apply to anything beyond the situation tested. There is no “definitive” without testing your test case. With a lot of storage bandwidth lz4 will be faster, if that’s your driving concern.
In general zstd will use more compute to compress compressible data more. It has a very favorable performance profile. If you have a surplus of bandwidth vs CPU and don’t care about file size lz4 is probably faster. If your data is largely incompressible lz4’s abort is slightly more efficient I think, but not that you’d really notice. If you have surplus cpu and disk bandwidth is constrained zstd is likely faster.
But they’re both “fast enough” and close enough that you should probably do your own tests.
All except systemd default to lz4on install from what I seen. And you can always change bootloaders after install if you wish.
Presumably just efi booting an efi boot stub kernel directly would be faster, to the extent that it matters.
Just follow any human-written documentation on zfs send and receive. Migrating Data With ZFS Send and Receive - Stephen Foskett, Pack Rat seems fine, for example, as a starting point.
Using his pool names something like
zfs send -R gang/scooby@migrate | zfs recv -F -o compression=lz4 gang/scrappy
zfs rollback gang/scrappy@migrate
Seems like it would work.
Or if you boot from a livecd and aren’t using the filesystem you can skip the snapshot stuff like in oracle’s docs.
You’ll need to either point your boot manager at your new dataset or send it back to rewrite the old (which you’d need to boot from something other than your system to do - either liveusb or sonething like zfsbootmenu)
Don’t send raw (-w). Probably don’t use -c (compress) on the send. Use -o compression=lz4 on the receive.
I’d also read/reference the docs. It’s quicker and imo far more useful than a video about someone else’s benchmark.