CPU hangs at 100% and process is stuck other programs such as plex wait for a response from the mountpoint and then also stop working

[StorM99x]

I have the problem that almost every day rar2fs is stuck and causes 100% CPU load. Other programs that access this mountpoint then also stop responding (e.g. plex) and only work again when I kill rar2fs and remount it.

I upgraded from an older rls (unknown) to rar2fs v1.29.7 (DLL version 9) and the problem persists.
Can someone help me how to figure out what is causing the error? It is a local mount on a ZFS.

--
rar2fs --version
rar2fs v1.29.7 (DLL version 9)
FUSE library version: 2.9.9
fusermount3 version: 3.10.5
using FUSE kernel interface version 7.19

+UNRAR 7.01 freeware

rar2fs /src /rar2fs --seek-length=1 -o ro,allow_other,noatime,umask=222 -s
Removing -s to enable multithreading makes the occours much more load after stuck

Thanks for your help!

[hasse69]

Try using the -d mount flag, which will run rar2fs in the foreground logging all accesses. That way we might be able to tell if it is a specific RAR archive that is the trigger of the problem or not.

Otherwise try to reduce your use-case to a minimum and see if you can still reproduce the issue.

[StorM99x]

Thank you for your feedback.

The problem seems to happen during the lookup of data which is not available / does not exsist.
Plex checks when scanning/updating e.g. if .plexignore, .grab or .plexmatch are present in the directorys.

Actually rar2fs throws an error here like:
LOOKUP /.../...1/.plexmatch
getattr /.../...1/.plexmatch
unique: 1243510, error: -2 (No such file or directory), outsize: 16

Before rar2fs stops responding for me it searches for such a file which is not present and is showing no error:
LOOKUP /.../...2/.plexmatch
getattr /.../...2/.plexmatch

But here rar2fs no longer throws an error " file not found "

/end of output

[StorM99x]

I checked it again and rar2fs crashed again at scanning this source dir from above:

Of course I could just delete this directory now and hope that it is the only directory causing the error. but the question is, can we find out what the problem is so that there will be a fix?

[hasse69]

It is not abnormal that access is attempted for files that does not exist, that is why there is a FUSE lookup in the first place (logs are coming from FUSE, not rar2fs).

But that it in some way should be the root cause is very unlikely.

If you can conclude it is always the same source directory that cause the problem it should obviously be skipped to see if the others work as expected. If it does then we need to check what in that source directory could cause the problem you observe. Note that there are several layers involved here and that makes these type of problems a bit harder to analyze.

You could also try running rar2fs through gdb and break execution when things get stuck to see what might be going on. This requires the -d or -f flag and also that rar2fs is manually built with debug symbols, not stripped binary. Not sure if that is plausible in your setup?