juicefs - restic hangs #4257
Comments
|
When it has hung, can you send a |
|
I just mounted juicefs and it looks like that file behaves like a FIFO, but has regular type as far as stat(2) is concerned. That means restic will open it and read it until it hits the end. But that file has no end, so the read never finishes. Rsync has the same problem with a juicefs mount, see juicedata/juicefs#1859. The advice there is to just skip the file. |
|
That makes sense. I was also wondering if that file is really needed, I guess it can have some value in being backed up, but it shouldn't be the main goal so to speak :) @greatroar Would it in any way make sense to read such files in a way that just reads what is available at the time we read it, or can we not make that distinction at all so this isn't even an option? |
|
|
The crash dumps confirms my suspicion: goroutine 63 is blocked reading from the target directory.
I don't think we can make that distinction. What we can do is not even try to read files whose size is advertised as zero. That would even be a general-purpose optimization, as we don't need to initialize the chunker for them and such files are produced by Git, the Go module cache and some other programs. A better fix for juicefs, though, would be that they make this file a FIFO instead of a regular file. |
greatroar
added a commit
to greatroar/restic
that referenced
this issue
Mar 23, 2023
Regular files that are empty according to stat are now not opened for reading their contents. Such files are quite common (in my homedir, at least) and we can save multiple system calls this way. On a network filesystem, that can mean round trips. Also, we can back up empty files that we cannot open for reading. Finally, fixes restic#4257. Existing tests cover this case. fs.Reader now no longer has a meaningful Size. Nothing depended on that.
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Output of
restic versionrestic 0.15.1 compiled with go1.19.5 on linux/amd64
How did you run restic exactly?
Server: Debian 11, x86_64, VPS, 2 VCPU, 2 GB RAM, on Hetzner Cloud
Output:
What backend/server/service did you use to store the repository?
sftp, usb drive on a Raspberry Pi 3 Model B Rev 1.2
Expected behavior
Restic completes the backup with no error or with an error that the file .accesslog could not be backed up.
Actual behavior
Restic processes all but the last file on the filesystem, named .accesslog. Restic does not finish, just sits there for hours with the clock ticking.
Steps to reproduce the behavior
Do you have any idea what may have caused this?
It has to do with accessing the .accesslog file.
A newly created juicefs filesystem contains these files by default:
If I exclude the file
.accesslog, restic finishes with no errors, else it hangs after three files.Juicefs has this to say about .
accesslog:(Troubleshooting Methods | JuiceFS Document Center 2)
Do you have an idea how to solve the issue?
No, but if I add
--exclude '/mnt/*/.accesslog'restic finishes the backup successfully.Did restic help you today? Did it make you happy in any way?
Restic smiled at me and made me feel good.
The text was updated successfully, but these errors were encountered: