DocCCD
This document describes the architecture of a cache-coherent distributed read-only I/O daemon for use by clients in a SLASH2 deployment. This effectively provides the cooperative caching model suggested by deployments that would benefit from such a capability.
slccd
(the SLASH2 cache coherent daemon, or cooperative caching) is
configured to use some amount of disk store to capture read-only data.
Old data is deleted as space is needed for new data entering the cache
as determined by a "last use" field either in memory or a metadata file
stored locally.
When mount_slash
handles open(2), if it is configured to use a local
slccd
and the file st_mode
is read-only, all read I/O requests are
sent to slccd
instead of the preferred I/O system.
Otherwise, it performs the read I/O as normal.
slccd
uses the following pieces of information to determine data
residency for content in his cache:
- file ID (FID)
- file offset (bmap/sliver offset and length)
- CRCs for the sliver(s)
If the data is not present, it is fetched and populated into the cache.
If the file is no longer marked read-only, all data is eradicated from the cache and this failure condition is returned to the client, who must perform the read I/O directly.
Otherwise, the "last use" field is updated for the data region in question so that it stays in the cache and the data is returned to the client.
There is no need to build "local cache" support directly into
mount_slash
taking this route.
Local cache is provided by running an instance of slccd
on the local
machine.
Perhaps a better approach would be to merge mount_slash
and sliod
and
add the functionality of slccd
.