Hi Kevin, Thanks for the detailed response. The extra context around isDataCacheInhibited and its purpose makes sense. Just to make sure I understand, you normally set "isOpenCloseInhibited", so you're now picking up an extra open/close you wouldn't otherwise have had? My volume doesn't adopt OpenCloseHandler, so it never sets isOpenCloseInhibited. The calls I'm seeing are DataCacheHandler's open(_:modes:cacheMode:context:replyHandler:) and close(_:context:replyHandler:). I tried adopting OpenCloseHandler alongside DataCacheHandler with isOpenCloseInhibited = true (on 26B5086k), but I still saw those DataCacheHandler calls. Among the DataCacheHandler configurations I tried, eliminating those callbacks required isDataCacheInhibited = true. On that last point, would setCacheState() otherwise meet your needs if #1 stopped? Yes. After a sl goto, we know exactly which items changed, and we only need to invalidate those items once, at that point. After that, the kernel can keep caching as usual until the next sl goto. We don't need to change any item's coherency type, only drop what's already cached, so either per-item setCacheState without the open/close calls or a volume-wide invalidation would cover it. Avoiding those callbacks has a measurable performance benefit in workflows I've benchmarked, but we can't use isDataCacheInhibited = true without a way to invalidate the kernel's cache to maintain correctness after a sl goto. Best, Genevieve

Hi Kevin, Thanks for your response. I re-tested and I can no longer reproduce FB24419825 on macOS 27.2 (using negotiated caching and invalidating the parent directory). Form the volume root, setCacheState still returns kIOReturnBadArgument with `.invalidate I've filed FB25077250 continaing a minimial repro for that. Best, Genevieve