I've said this before, but while a lot of the bugs are most easily triggered with `zfs send`, you can also trigger them other ways depending on which bug on which platform - illumos, for example, used to be able to reliably trigger a crash with the same trace as one of the "send/recv" bugs on ZoL/OpenZFS with just "zfs clone" (it might still, I haven't tried in a while).
Another one of them got what looks like a duplicate posted that triggered on pool creation in the test suite sometimes.
So I don't think it's accurate to say "it's safe if you don't use zfs send" - while some of the bugs might actually be exclusive to send/recv, it seems like a number of them are just most easily triggered that way.
It clearly works "fine" for some people - e.g. I believe the original authors of the feature still use it in production, last I knew, because their workflow doesn't hit any of these issues. But "using this feature adds a 1% chance of a lion eating your face" seems like something worth warning people about, if there was not a face-eating risk prior.
(Especially because a number of them seem to be races, so how much the problem comes up is really going to be hard to predict a priori...)
Another one of them got what looks like a duplicate posted that triggered on pool creation in the test suite sometimes.
So I don't think it's accurate to say "it's safe if you don't use zfs send" - while some of the bugs might actually be exclusive to send/recv, it seems like a number of them are just most easily triggered that way.
It clearly works "fine" for some people - e.g. I believe the original authors of the feature still use it in production, last I knew, because their workflow doesn't hit any of these issues. But "using this feature adds a 1% chance of a lion eating your face" seems like something worth warning people about, if there was not a face-eating risk prior.
(Especially because a number of them seem to be races, so how much the problem comes up is really going to be hard to predict a priori...)