Reasons to write this FUSE fs:
a. handle multiple reads in a right way preventing unnec. seeking.
b. use a cache to improve performance
The reason for me to write this fs is to create a fs which handles the serialization of read calls. I've been argueing on the FUSE devel maillist about how to implement the serialization of reads on a decoder fs. These fs's use a decoder in it's won context per file. The problem with these fs's is that read calls can become out of "order". Reading from a to be decoded file can take some time (decoding is a CPU extensive task) and other read calls started by the client/another client have to wait.
This waiting is done in the fs using the locking methods of threads (:pthread_mutex_lock and others). When the decoder is ready with his current job, and available for the next job, and the fs just picks one of the waiting read calls. The way the fs does that is pure random, and it does not honours the order the read calls has been send to the fs.
For example:
job1: read the first 4096 bytes (0, 4095), while the decoder is busy to get the result, job2 (4096, 8191) and job3 (8192, 12287) are send to the fs. This fs detect the decoder is busy, and the threads are in a wait state. When the decoder is ready with job1, the next job which is processed can be job2 but can also be job3. When job3 is handled first, this causes unnecessary seeking, which causes delay.
The way the locking library (pthread) handles unlocking and the thread which get's the lock and the others still have to wait is the cause for the behaviour.
The idea on the FUSE maillist is that the FUSE library has to be patched to prevent this behaviour. I have another solution, which is I think better. I think the best solution to prevent this unnecessary seeking is to handle this in the fs self. This means advanced programming with the use of pthread_mutex_lock/unlock and pthread_cond_wait/signal/broadcast, and queues.
Now to get this done for a decoder fs (like ogg -> mp3) is pretty complicated, so I decided to first write a fs with a simpler backend, audio cdrom, but with the same characteristics: multiple reads possible, one reader where a lot of seeking causes bad performance.
Another reason for me do this is that I wanted to use a cache. Since this fs has a read only backend, and reading the cd is not fast, the use of a cache might be very usefull.