I've been looking at the new kernel caching APIs in FSKit (FSVolume.DataCacheHandler), and they look like they'll be quite useful for network file systems. But are they recommended to be implemented for block device file systems? I see an "Important" note in the documentation that says
If a file system doesn’t conform to this protocol, the kernel may still cache it. However, such a file system has no control over caching behavior; the kernel caches data as it sees fit.
So I'm wondering in the case of a block device system, where I'm (mostly) using kernel offloaded IO, whether this has any relevance, or if I should instead skip this implementation and just let the kernel "do its thing."
The key consideration here isn't block vs other resources, it is if any other system is simultaneously modifying the file system. Network file systems fit the case of simultaneous access so well, it's hard to think of a counter case.
For block device file systems, almost all of them are built with the kernel having exclusive access. As such, they do not need FSVolume.DataCacheHandler. They also probably don't want the extra overhead.
Cluster file systems, such as GFS2, VMFS, SNFS/Xsan, and so on, would be interested in this protocol.
