Hello again John, Oops, sorry. I thought RedHat Linux had everything an Enterprise needed ;-) (Take the above line with a lot of salt. I don't want to discuss about linux distros... yet ;-)
Then what about adding a "-nocache" parameter to the function? That way you won't modify the original behaviour... As far as the solution is not perfect, if we keep pushing up patches, it'll end being a hell consisting on a pile of patches. In fact, I feel that checking the filename instead of last modification time is a better way to "patch" the "if" clause. It's safer to be sure that will not be collisions by that way. Anyways, as someone said, I am amazed on the fact of how ext3 reuses the inode numbers... I didn't know it was so aggresive :-) Regards, and hope you finally can serve your customers right (no matter how you solve this problem), Juan José - Juan José del Río | (+34) 616 512 340 | [EMAIL PROTECTED] Simple Option S.L. Tel: (+34) 951 930 122 Fax: (+34) 951 930 122 http://www.simpleoption.com On Wed, 2008-08-20 at 14:24 -0700, John Caruso wrote: > On Wednesday 01:45 PM 8/20/2008, Juan José del Río wrote: > >But, since Linux version 2.6.13, inotify is into the kernel, and > >aolserver can subscribe to a path, so know if that file has been > >deleted, modified, or anything else. That's the way a cache can know if > >the file has been altered in any way, and it should be marked as dirty. > >As easy as that... but I know it is harder than that one-line-patch. > > inotify isn't available as of Redhat Enterprise > Linux 4, and I'm sure there are other major > distributions that are missing it as well--so > while it may be the best approach eventually it > won't solve the problem right now. Also, not all > platforms use inotify, so adding filesystem > monitoring support would require complex > cross-platform code (which in some cases won't > even be available). So while I'd agree with you > that the eventual (ideal) solution is a major > rewrite of the fastpath caching code to use some > sort of filesystem monitoring technique, that won't work now. > > By comparison, the fix I offered will work just > fine on all the platforms that AOLserver runs on, > right now, and it fixes all non-pathological use > cases (i.e., all but ones that are artifically > designed to trip it up). As to whether it's a > hack, possibly, but so is the fastpath > code--that's the whole problem. The patch > corrects a specific flaw in the original code: > that fastpath never should have been caching > files that were modified within the last second, > since the underlying OS mechanism (mtime) doesn't > provide the resolution necessary to distinguish > reliably between two such files. In other words, > the patch is in the same spirit as the original > code--so if you really don't want such ugliness > in your code you should probably just strip out > fastpath caching entirely. :-) > > - 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. > > -- 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.
