I'm not a developer, I'm only the one that reported this issue (and did may tests about it). In the cases I faced, -edio option always fixed. Without it, very slow speed; with it, normal speed. For not being default, I let Steven Shiau (he's the developer) speak. My opinion about it is: since this issue affects only some drive (or perhaps drives / chipset combination, there is not much data about it), it has been a safe option not to enable it by default. I would require more testing. What about...
fs3000 an zemerdon: have you tried -edio option?
It doesn't cool nvme drives, but write load may be different. And in your case, what is the outcome of 2.8?
A thermal issue is not related to the one we are discussing. Clonezilla 2.8 (or newer with -edio option) does not cool down NVME drives :-) Latest user didn't try -edio, so we cannot tell if it would fail.
A thermal issue is not related to the one we are discussing. Clonezilla 2.8 (or newer with -edio option) does not cool down NVME drives :-)
Is it so slow also with -edio option, or only without it?
This SBAT update does not seem a safe action. The most worrying scenario is not that old Clonezilla get blacklisted, but that a resident OS get blacklisted. A live environment is (usually) believed to alter as little as possible a system. In particular source machine of a clone action. Let's say we have a machine, with a resident Linux of some year ago. Working. Not safe as a newer one? Perhaps, but it's not something we are supposed to change. Perhaps it's in a protected environment, perhaps it...
I got another machine and tested again. Not a B360M-A, an H510M-A one (identical to all ones that showed slow restore and to the latest that didn't show it). This behaves like the latest, restore is fast with every Clonezilla version. NVME firmware is the same, 9256: I still suspect that previous machine had another version, because it seems to me the only thing that can be different, but until I don't see another older machine I cannot confirm it. The message "Timed out for waiting udev queue to...