Debug/feedback compFUSEd problems

Last Updated on Thursday, 01 May 2008 12:45 Written by Administrator Thursday, 01 May 2008 10:17

Although every release of compFUSEd improves upon the previous one, compFUSEd still needs work. Any feedback is therefore very valuable. This text describes a few things you can do to get more information out of compFUSEd to help debugging it.

Testing

This is how I test the compFUSEd code. As a Gentoo user I have set my PORTAGE_TMPDIR variable to point to compFUSEd mountpoint. This will cause gentoo to extract and compile any package that I emerge in this directory. This means running automake, configure, gcc, m4, ... on the compFUSEd mount. The ultimate test is to run a emerge system most of the time this means compiling the main packages of any Linux system like glibc, gcc, . So I launch an emerge system and wait wait wait...

I found that ./configure scripts in particular do all kinds of nast things from the point of view of the filesystem. This has exposed quite a lot issues in the compFUSEd code. I found this a usefull way of stressing the code. But it is slow and not always possible to recreate some problems. If you know a better approach, especially a faster one, please let me know.

Debug compiles

First of all you can compile the compFUSEd binary with more debugging options set using 2 special make targets: debug and debugmax

Note: If you make symlinks to the original binary for each of your compFUSEd mounts this will update all your mounts.

make clean debug

or

make clean debugmax

This will produce more output in the log file. Beware of debugmax it creates output for every read and write operation. Do not forget to disable debugmax asap when you don't need it anymore.

Multi-threading problem

To highlight a possible multi-threading problem disable it with the -s option on the command line. For example:

./cf_linux /usr/src -s

This start the mount in single threaded mode. If the problem disappears this would indicate a problem in the multi-threading code. Not my favourite...

Others

To collect all the possible output you can log to the screen instead of using a log file. Remove the log entry in the configuration file. Do not forget to compile with make debug, then start the mount using the -d parameter. The compFUSEd mount will not fork into the background then.


./cf_linux /usr/src -s -d > log.txt


Now try whatever cause the problem in the first place. Instead of using CTRL-C to stop the mount better umount /usr/src in second terminal.

Feedback

Feedback is extremely welcome. If you find a bug it is even more usefull especially if it comes with some information that would allow to investigate, or even better recreate, the problem. Things that can help are:

• log files (created as mentioned above)
• config file of the mount
• FUSE version you use
• kernel version
• maybe a list of the running processes (created with ps -axf would be nice)
• whatever practical information you think may matter

Please mention the problem clearly: mem leak, crash, hanging,... If possible described when the problem occur:

• at mount time
• during normal use
• when unmounting

If you do not feel comfortable sending log files containing personal information maybe try recreating the problem using files take from the net (a tar archive for example).