On Wed, 13 Aug 2014 22:26:36 -0500 Andrew Deason <[email protected]> wrote:
> This generally sounds reasonable to me. But I think you want to just > require a dot if the name doesn't exist in the csdb at all, so you can > just put it in the local csdb if you want to use it, without needing to > alias it to a full cell name. (This may have been mentioned earlier, but > I don't see it here.) I'd call such an option -afsdb-ndots, which would > set the minimum number of dots (like resolv.conf's "option ndots"). I would probably prefer to have a whitelist of some sort that would support regular expressions. You could then do something stupid like require entries to have atleast a single . and end in one of the more common domain suffixes. > However, this doesn't solve the issue when files like libX11.so or > beamer.cls like in your captured list. You really need a blacklist for > these, or we can just try to improve the negative caching. iirc, we After looking at the code, I think negative caching would be a big win. When a lookup fails, it has to fail about 5 times: once to reset the resolver and then 4 times for the each possible search. > already have some hard-coded 'blacklist' entries to appease things like > OS X's Finder, so a configurable blacklist doesn't seem like such a big > change. Doing any actual pattern matching could be done in userspace and > can be very slow if we just cache results in the kernel (keep a > 'negative' cell struct around). Keeping the negative cache in the kernel possibly isn't a good idea. At a minimum you would need to bound the size. I don't think the call up to afsd is that slow but if it is it could be fixed. > A blacklist might help for a vast majority of cases, though. Or of > course we could just improve the caching, so only the first lookup is > slow... would that be good enough, if done "well"? Very possibly given the way lookups have to happen to support all the possible DNS records that might be out there. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
