[tahoe-dev] 'Client' caching?
Nathan Eisenberg
nathan at atlasnetworks.us
Thu Nov 26 11:19:02 PST 2009
> From: tahoe-dev-bounces at allmydata.org [mailto:tahoe-dev-
> bounces at allmydata.org] On Behalf Of Brian Warner
> Sent: Thursday, November 26, 2009 11:09 AM
> To: tahoe-dev at allmydata.org
> Subject: Re: [tahoe-dev] 'Client' caching?
>
>
> Welcome! Yes, this is the perfect place for questions like this.
>
> It's useful to note the distinction between mutable and immutable files
> here. Caching immutable files is perfectly safe: it's a simple tradeoff
> between local storage consumption and performance, assuming a given
> locality-of-reference / reader behavior. Caching *mutable* files (or
> directories), on the other hand, is not safe: the tradeoff includes a
> correctness aspect, since someone else might change the contents and
> you might use your (now stale) cached copy. In general, we try to avoid
> putting any sorts of heuristics about correctness into tahoe itself, so
> any caching layer that requires a decision on a correctness-vs-
> performance policy would need to be placed above the tahoe node.
>
> Hm, I'm surprised that didn't work. Do you know what caused Squid to
> believe the file was changing each time? Maybe a quick peek at the
> returned headers would be informative.
>
> Basically, any URL that starts with /uri/URI:CHK: should be immutable
> and an ideal choice for caching. We'd planned (although I can't check
> right now to see whether we got around to implementing it or not) to
> add an ETag: header with the file's UEB header, which is basically a
> hash of the contents, and thus an ideal etag. And I know we aren't
> intentionally adding any Cache-Control or date headers that might make
> the file look uncacheable.
>
> (for mutable files, there is a similar value called the "roothash"
> which covers the file contents, and allows If-ETag-Differs: -type
> queries to do the right thing, but I don't know if we've actually
> implemented that either).
>
> hope that helps,
> -Brian
Hello Brian,
Yep, I'm currently only interested in immutable files. I might be missing out on functionality by doing so, but I've been trying to get up to speed on Tahoe rapidly, which means picking things to hold off on attempting to wrap my brain around. I can see why caching mutable files would be bad, though!
I'm not very familiar with debugging Squid, but here's what I saw in the access logs:
and the store logs:
1259221695.460 RELEASE 00 00002F1D 687E491AEFFD986129E9BC7FFF6EF9D2 200 1259221693 -1 -1 text/plain 620888/620888 GET http://x.x.10.44/uri/(URI)
1259221695.477 RELEASE 00 00002F1E 5593E0D36660EBADEE217CE11710366E 200 1259221693 -1 -1 text/plain 620888/620888 GET http://x.x.10.44/uri/(URI)
1259221695.517 RELEASE 00 00002F1F EABE7B59FF7FCC4197BB11E7135F136C 200 1259221693 -1 -1 text/plain 620888/620888 GET http://x.x.10.44/uri/(URI)
1259221695.532 SWAPOUT 00 00002F20 72B9FDA4BB757341E001D528A8E6DE56 200 1259221693 -1 -1 text/plain 620888/620888 GET http://x.x.10.44/uri/(URI)
More information about the tahoe-dev
mailing list