On Monday 05:13 PM 8/18/2008, Jeff Rogers wrote:
Simply put, fastpath caching is inherently broken because it's not possible to guarantee that the file in question really should be served from cache (again, short of a cache-defeating checksum).

The same can be said about nearly any caching system: it is unable to handle changes in the data that happen outside of the cache's control or knowledge. This is just the bargain you make when you use a cache.

I'd say "nearly any" is going too far, and in fact I'd say that for most caching systems to fail to return the correct data is a serious bug. The NFS example you bring up isn't really analogous since it's only about attributes, which are frequently not a concern; were NFS to return incorrect *data* for a file, that would be a serious bug. And in this case we're talking about a web server that may silently return data that's completely incorrect, which I'd say is very serious misbehavior.

The core problem here is that AOLserver is attempting to use the tuple of (dev, inode, mtime, size) as a unique determiner of a file's identity, and that's an inherently broken assumption--particularly so since the granularity of mtime is one second and inodes are reused on many filesystems (e.g. very common ones like ext3 and ufs).

I think you highlighting it is most of the fix. From there, get the caveat inserted into the documentation and the knowledge into the community so that the next person who runs into this problem will have an easier, or at least less frustrating time solving it.

That'd be an improvement over the current situation, but it's still the case that AOLserver as currently shipped has a file cache mechanism built into it which 1) may return incorrect data and 2) is enabled by default. Given the risk, I'd say fastpath caching should be disabled by default rather than enabled.

- John


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to