Appendix B: Troubleshooting
This section describes and explains how to solve some of the problems that may arise with The Almond Doubler as well as answering some of the most frequently asked support questions.
Problem: I've installed The Almond Doubler, and I started Doubler with no problems or error messages, but none of my files are getting compressed. Why?
Answer: There are two primary reasons why files don't get compressed:
1. The compression parameters are set such that all of the files on your disk are out-of-bounds, and therefore are not compressed. The best way to trouble-shoot this problem is to write down the actual settings of the parameters, and then re-read the documentation to verify that the settings are appropriate for your compression goals.
2. Your disk space is too low. If the available disk space on the file system on which Doubler was installed gets too low (relative to the size of a file being compressed), the file will not be compressed. This is a safety feature designed to ensure that once a file is compressed, there will be sufficient disk space available for automatic file expansion.
The solution to this problem is to free up disk space on Doubler's installation file system. Doubler allows you to back up files without automatically expanding the data (i.e., back up the compressed versions of the data). See the previous chapter in this manual for details.
It is also possible that the file system has plenty of disk space and your parameters are set properly, and a file still does not get compressed.
This is because The Almond Doubler does not bother to compress a file whenever the resulting disk space savings are less than 1024 bytes. If the compression algorithm indicates that the compression savings are below that threshold, or below the percentage threshold specified in the user-selectable parameters, then the file is left in its original state.
One other point: The Almond Doubler has a cycle in which all of the files specified for possible compression are reviewed. After each review, the compression daemon sleeps for a little bit, based on the value of one of the configuration parameters. If a certain file is not getting compressed, it could be simply a question of waiting a few minutes for The Almond Doubler to "make its rounds".
Problem: When I hit the "start doubler"/"stop doubler" button, I wait 30 seconds and then I get an error dialog pop-up window which informs me that doubler did not start/stop. Why is this happening, and what do I do now?
Answer: This is happening because of resource contention within your system, and is temporary.
For example, you may wish to stop The Almond Doubler at the same time that some other process has a compressed file opened (e.g. for editing with Text Edit). You should try pushing the Start or Stop button again in a few minutes. Another method is to make sure that all users have logged off the system, so that compressed files are not being accessed.
Problem: I notice that the database file in the Doubler installation directory keeps getting bigger and bigger. It's currently at 1/2 megabyte, and I don't want it to grow to more than 1 Mb in size. What do I do?
Answer: The Almond Doubler performs garbage collection and database slot reassignment whenever it is restarted.
Simply stop and then start The Almond Doubler, whenever it is a convenient time on your system to temporarily halt expansion of your compressed files. The database file will reassign any slots from files that have already been expanded.
Here is a technical tip on how to estimate the number of bytes by which the database file will shrink after doing this procedure. Each file that gets compressed requires an overhead of at least 55 bytes, with extra bytes being required to store the file's name in the database. A good working estimate is to assume that each file takes up 64 bytes in the database file.
Look at the number of "Files Compressed" on the Doubler window. By multiplying the number of files times 64 bytes, you'll get a fairly decent estimate as to the compacted size of the database file (i.e. the size after garbage collection).
Problem: My system crashed and when I restarted The Almond Doubler, it looks as if there are fewer compressed files being reported than there were before the crash. Is it possible that I've lost some important data?
Answer: If the reboot of the system indicated inode errors and superblock reconciliations (from "fsck"), then it is possible that those files that were actively opened by processes at the time of the crash might be affected.
The odds are extremely good that none of the data was lost; however, the links pointing to those compressed files may have been corrupted. That would explain why some files are no longer getting counted as compressed files.
A log of all errors recognized by The Almond Doubler at startup time is kept in a file called "errlog". This is a text file stored in the installation directory's ".doubler" subdirectory. Carefully read this file, checking for messages like:
"Dblrd Rebuild: No symlink to doubler mountpoint for XXX".
The best way to manually recover these files from the crash is to go into the hidden ".doubler" directory for the file system on which the compressed file resides. (For example, if a file resides in the "/" file system, then go to the directory "/.doubler".) Carefully scan the names of the files in this directory. You will most likely be able to find the file you're searching for, with an additional suffix composed of a blank (space) followed by a number.
For example, the file "foobar" might have the unique name "foobar 123" in this directory. Then run the manual expander program, "alunwrap", on this file to recover your data.
Problem: I can't believe my bad luck. When my system crashed, the database file was corrupted. Is there anything that I can do?
Answer: There are a couple of things you can do to restore things back to normal.
The easiest solution is to use the special database backup file. It is found in the installation directory's ".backup" subdirectory, and is called "database.bak". Simply copy that into the ".doubler" subdirectory, renaming the copy "database". Do this BEFORE you start The Almond Doubler. (WARNING: If you restart the Almond Doubler, the garbage collection procedure makes the previous backup database file obsolete and no longer useable.)
The backup is made roughly every fifteen minutes, so it might not be completely up to date. To reclaim those files that were compressed during the fifteen minutes prior to your system crash, you need to follow the steps outlined in Question 4 above. Expand each "missing" file individually. The Almond Doubler's compressor will then re-compress the data and make sure that it is logged properly into the database file, after you restart The Almond Doubler.
Problem: I'd like to stop The Almond Doubler from the system console, where I am not running X Windows. Is there any way to control the program from the command line?
Answer: This is not the recommended course of action. However, it is possible to stop The Almond Doubler by manually signalling the two active processes (daemons) which perform the automatic compression and expansion.
The signal to use is "SIGKILL" for dblrc and "SIGUSR1" for dblrd. The name of the compressor daemon is "dblrc", and the name of the decompression, or expansion, daemon is "dblrd".
For example, if the PID for dblrc is 12073, then the command
kill -KILL 12073
will trigger a shutdown for the dblrc process.
WARNING: WE STRONGLY RECOMMEND THAT THE COMPRESSOR DAEMON, dblrc, BE SHUT DOWN PRIOR TO SHUTTING DOWN THE DECOMPRESSOR DAEMON (dblrd). FAILURE TO DO SO COULD RESULT IN SYSTEM CONFIGURATION PROBLEMS WHICH REQUIRE A REBOOT OF YOUR SYSTEM.