fyi, there's talk of a bug in the fastpath cache on the aolserver
list. I agree with the reporter, John: it's totally busted. I
committed a fix last night, but if you're not on the commits list you
won't have seen it. Heads up.
The fix was to lookup objects in the cache using the file name, as the
windows code did, and not use the two-stage file name to inode, inode
to object lookups.
The only down side might be that if you have files known by more than
one name, eg symlinks, the cache will hold duplicates and be less
efficient. But that may not be a great idea anyway: with symlinks,
user-agents will use different URLs to request the same file, so HTTP
caching can't be used.
Also, it seems to me that the problem has nothing to do with dynamic
content or temp files or the programmer doing anything wrong. You
could be unlucky with your timing and have random content appear
instead of the file you expected. For example, two programmers could
log in to one machine and edit two html documents live. If they happen
to save at the same time, and there happens to be requests for those
files which cause them to be cached, and the OS chooses to recycle
inodes unfavourably, then the contents of either of the files might
appear to be any other file that has previously been cached by
fastpath. Ouch.
|
