pCacheFS – persistently caches other filesystems

Imagine you have a mount to a remote filesystem which houses lots of data which you access regularly. Perhaps it is your music library on a remote NFS server, or via SSHFS. Imagine that this filesystem is slow to access – perhaps it is over a wireless network.

If, like me, you have music playing in the background much of the time when you are using your workstation, having that music on a slow remote filesystem can be irritating. If I change track, there is a delay of a few seconds while my music player opens and reads the metadata for the new file I’ve selected. If I want to perform a search of my music library, it takes a long time unless my music player has some sort of database of all the metadata (which admittedly many modern players do). And if you have ever tried seeking within an MP3 on a remote filesystem, it’s painful.

For my SSHFS-mounted music library you can easily be kept waiting for 5 seconds or longer for some of these operations to complete. (Before you post a comment saying there’s something wrong with my LAN: I access my music over a VPN, over a WAN at ADSL speeds.)

For this reason I wrote pCacheFS (http://code.google.com/p/pcachefs/).

pCacheFS is a FUSE filesystem that presents a mirror of other filesystems, with transparent caching. Not only that but the cache is persistent. It is stored locally, which means that when I reboot, my cache remains intact.

As the cache also resides on any filesystem  I choose (e.g. a local hard disk), it can grow much bigger than caches that only reside in RAM. Given enough time, pCacheFS will probably end up creating a replica copy of my remote filesystem, locally.

How it works

Using pCacheFS is very simple. Go to the website (http://code.google.com/p/pcachefs/), download pCache 0.1 and extract it somewhere. Then run this:

pcachefs.py -c /cache -t /remote /remote-cached

The -c parameter specifies the location of your cache directory – all data that pCacheFS caches will end up stored here. It’ll be created if needed.

The -t parameter specifies your ‘target’ directory – this is your slow filesystem you want to cache data from.

The last parameter is where the cached filesystem will be mounted.

If you look in your new mountpoint you’ll see a mirror of the target filesystem:

$ ls /remote
. .. file1 file2 file3
$ ls /remote-cached
. .. file1 file2 file3

You can read files in the /remote-cached just as in /remote, with the important difference that everything you access in /remote-cached is transparently cached by pCacheFS. When you access that data again, that data will come from the cache (i.e. must faster than your remote filesystem), saving you time and network traffic.

pCacheFS will only cache data you access in /remote-cached, right down to the byte level. If you tail a file on /remote, only the parts of the file that tail reads will be cached, not the entire file. This means that your filesystem performance for uncached files is the same as it would be if you were accessing the remote filesystem directly.

One notable limitation of pCacheFS at this point is that its filesystems are read-only. Any write operations will fail – the only way to change the data is to change it directly in the underlying target filesystem. This may change in the future.

Conclusion

If you think you may have a use for this I thoroughly recommend giving pCacheFS a try. As it can be used to cache any filesystem and the cache itself can reside on any filesystem, you may even find more novel uses for it.