rare but severe slowdowns when reading large files linearly about fusecompress HOT 3 CLOSED

What I found out so far:

1. FUSE does indeed sometimes read data it has read before once more. These are 
usually ironed out by caching, but if the cache is full, problems like 
described 
above could occur. (Although I have not yet managed to run into one.)
2. The conditions for complete decompression on read cannot actually be met if 
cache_skipped is enabled. The condition (!cache_this_read || decomp_cache_size 
> 
max_decomp_cache_size) can never be true because we make sure to only cache 
data if 
decomp_cache_size < max_decomp_cache_size, so -- assuming that everything is 
page-
aligned -- the worst we can get is decomp_cache_size == max_decomp_cache_size.

I guess the solution is to fix 2. and fall back in the cache full case. It is 
IMO 
questionable, however, whether it makes sense to wait until the cache is full 
before 
doing so.

Another thing badly wrong with the aforementioned condition is that it may 
allow 
reads to files in direct-write mode without decompression if caching is enabled.

Fixed in r69:
a) The condition in question is now decomp_cache_size >= max_decomp_cache_size.
b) If it is possible to tell that the skip will not fit in the cache, we fall 
back 
instead. If we cannot fall back, we abstain from filling up the cache with data 
we 
most likely won't need for anything.
c) Skipping file->size bytes is enough to trigger a fallback now (3 * 
file->size 
before), but only data that is not cached counts towards it.

The Thing From Comment #2(tm) has also been fixed (see issue #26).