-
Notifications
You must be signed in to change notification settings - Fork 430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose API for stat and type cache #1246
Comments
Hi @lesnitsky, We won't be able to expose an API to modify GCSFuse cache as it is an internal resource, and we don't want to allow external updates to it. In the meantime, I would suggest you to evaluate use of --stat-cache-ttl flag to figure out if setting a lower time-to-live helps your use case. (Detailed documentation here) Thanks, |
lower ttl won't help, our system is pretty much "if the object is there, it's there forever" so caching makes a lot of sense (and I'd rather increase default values), but also new objects should be available right away – so negative caching is a blocker here. |
Having a similar constraint too so I would be interested on being able to separately configure positive/negative results. |
Created internal FR id 333354655 . |
I've tried GCSFuse on Cloud Run both with cache enabled and disabled and I'm seeing a significant difference in performance. I understand where consistency limitations are coming from when cache is enabled, however I still want performance benefits of cached stats. Our system has a full control over storage buckets, so updating a local cache is as simple as subscribing to a pubsub topic. Is there any way to manipulate the cache from outside and if not – would you consider exposing such an API?
As far as I understand reading through the docs, stat cache is both positive and negative, however, new objects becoming available over time (due to other actors creating those objects) is quite a common scenario, so maybe it makes sense to make negative caching opt-in.
The text was updated successfully, but these errors were encountered: