httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <>
Subject Re: ETags & NFS caches (Apache 1.3)
Date Fri, 27 Oct 2000 00:05:53 GMT
On Fri, 27 Oct 2000, Thomas Wouters wrote:

> On Thu, Oct 26, 2000 at 02:02:45PM -0700, Koen Holtman wrote:
> > I recall having an exchange about strong etags based on the unix ctime vs.
> > NFS on the http-wg mailing list.  Jeff Mogul, who is some kind of NFS guru
> > in another life, told me that NFS makes no hard guarantees about file
> > ctimes always changing as soon as the contents change.  So this seems to
> > be an NFS 'feature' not accounted for by Apache.
> Yeah, I have some vague recollections regarding that as well. Something like
> data being cached, but not meta-data/file-properties. 

Hrm... I'll have a word with the Unix systems people here. We do some
pretty brutal things to poor unsuspecting little NetApp filers - and the
load levels in some of our Sun problem reports make Sun's guys eyes water.
The one about "Solaris breaks after 256 loopback mounts" (or similar)
provoked an interesting response, apparently...

(In fact, ATM the front-end boxes have to be rebooted every two weeks to
clear some nasty leakage in Solaris' NFS code...)

> > This does not explain your observation that it is apache-specific though.
> Exactly. The only thing we could think of was an OS level cache bug that
> only gets triggered on extreme use. By the way, I forgot to mention, but we
> aren't using anything like mod_mmap or some such. The only non-default
> module is mod_php4, and that isn't used by those pages.

Ahh... There goes my #1 suspect :-(

Another possibility: is the OS skipping the open() call from Apache (since
the file was just opened), but handling it properly when another process
makes it? Remember access control checks etc. are made on open(); if BSDI
were wrongly caching this for repeated open() calls from a single process,
that could explain the problem.

> > The HTTP-level fix of course is for Apache to make etags weak if the ctime
> > is less than N seconds ago, for some value of N.  Don't ask me what N is.
> Well, a couple of minutes would work, probably. I hadn't thought of that. I
> think I'll do a quick hack to see if that works -- the actual change is
> quite small, since make_etag already creates a weak etag if the difference
> between request-time and last-modified is less than a second. I guess I'll
> just do it and see if this works. I'm not sure howmany browsers actually use
> ETags and respect weak ones, but I'm hoping both Netscape and IE choose to
> be on the safe side, so it might very well solve 99% of the problem for us.

While it would be nice (for you) to avoid the problem like that, getting
Apache (or BSDI??) fixed properly would be preferable IMO :-)


View raw message