Add support for caching in trade-off for reduced guarantees

[jacobsa]

Right now, gcsfuse caches nothing and allows the kernel to cache nothing. This is in order to support the consistency guarantees documented in semantics.md. But it makes things slow, particularly when the kernel is doing path resolution (which is very frequent).

There is probably room for a --go_fast flag that users can enable if they are okay with relaxed guarantees. I would start with just allowing the kernel to cache attributes and entries, and see if anything else is truly needed. If so, the following additional things may or may not be helpful (measure first to find out!):

• A "stat cache" mapping object name to most recent gcs.Object record for it, perhaps with TTL. Probably also supports negative entries.
• A "listing cache" that caches listings for a prefix. This is more subtle, so hopefully we don't need it.

[jacobsa]

Plan

• Add a gcs.NewFastStatBucket function
  • Accepts wrapped bucket and TTL
  • Maintains a mapping from name to latest record known for that name.
  • Serves from this for StatObject when possible.
  • Invalidates in DeleteObject.
  • Invalidates then updates in CreateObject and UpdateObject.
  • When updating, don't clobber a newer generation.
  • Unit test with mock wrapped bucket.
  • Integration test that sanity checks each method, plus invalidation.
• Set up gcsfuse to use this when enabled. Document this.
• See how the ls -l case performs (ls takes a long time for medium-sized directories #39).

[jacobsa]

This is mostly implemented at e82b91f, but doesn't yet make things fast because we don't have a negative cache, necessary because for lookups we stat both the file name and the directory name.

So, still to do:

• Add negative caching to the GCS package.
• See how the ls -l case performs (ls takes a long time for medium-sized directories #39).

[jacobsa]

By the way, negative caching will make the second ls -l very fast, but the first will benefit only from positive caching.

The only way I see to make the first very fast is to cache a mapping from name to file/dir/both flags on the directory inode when reading it, then using that to decide what to stat. Yet another kind of caching, with an inconsistent source. Ugh.

[jacobsa]

At 711b5f1a38dbe3ea7387e9b1accd68ee86a99277: ls -l on a 500-file bucket without --stat_caching_ttl set currently takes about 1m. With --stat_caching_ttl 10m, the first takes about 20s and subsequent ones take about 2s. (These numbers are highly variable, seemingly due to either GCS or GCE performance.) Still much slower than I would like, but I think this particular bug is closed. Further work in #39.

(All of this was from asia-east1-a to a standard bucket in Asia.)

[jacobsa]

Oops, need to document the flag.