Is there any recommendation which go and restic version to use for maximum reliability?
Or should we prefer to use the binaries in general?
I’ve read something about problems storing backups on smb filesystems with certain go versions.
Is this issue solved at latest restic releases?
And can 0.9.6 for example considered more stable than 0.10.0 ?
Thank you.
0.10.0 is mostly a bugfix release which doesn’t touch any of the sensitive areas such as encryption or storage format. I’d recommend using 0.10.0 over 0.9.6.
I’d say there’s more relevant optimizations and feature improvements in bug fixes. What makes you say it’s mostly a bug fix release?
Scratch the “bug” in “bugfix”, my main statement being that there’s a lot of incremental improvements as opposed to enhancements which influence the data format. I’d recommend to check out the release notes for v0.10.0 to come to your own conclusions.
thank you.
The precompiled binary of 0.10.0 is using go1.15.2.
Does that mean we still have to use the “GODEBUG=asyncpreemptoff=1” workaround for backup to smb?
That seems to be the case for now. As this is an incompatibility between Go and the CIFS implementation in the Linux kernel, there’s not much else we can do to work around the smb problems.
I wonder how a program in user-space can break the filesystem in kernel. This must be a serious bug. But i must admit that this is far beyond my knowledge :-).
At least it should be safe to use go 1.14/1.15 with asynchronous preemtion turned off? So no reason to stay at 1.13?
From what I can’t tell it should be enough to disable asynchronous preemption. If that doesn’t work restic will report error so just keep an eye out for these.
Go sends signals to it’s threads to interrupt the current goroutine and give it the possibility to switch to another one. Some syscalls for reading/opening files can take quite a long time to complete and therefore are also interruptible by such signals. However, it’s expected that most of the syscall just continue once a signal was processed. And that’s the point where CIFS behaves differently than everything else and does not follow the specification.
Thank you for your explanation.
Now i have an idea of the background.
However, does that mean without turning off async preemption it may cause a corrupted repository or even data loss if it’s on a mounted cifs filesystem?
My current understanding is that this can only cause backups and other operations to fail. The syscalls return an error instead of working properly. restic will retry the operations to store data files a few times and abort if these still don’t succeed. That said, it might be possible that we have missed a corner case in the error handling, in which case the repository could miss data. (At least for the backup command I’m relatively sure that we haven’t missed such corner cases, but I haven’t stress tested the error handling either).