I do not think the dnlc is the right place for this. There are two independent issues here:
1. using DNS SRV/AFSDB records to perform cell alias lookups. If the DNS SRV/AFSDB search was restricted to absolute name queries and didn't permit domain searchlist queries the problem of searching for "git." would go away because it would fail outright. 2. the problem of searching for a random application's configuration file of the day in every directory cannot be solved by the dnlc. The penalty is the cost of loading the directory contents over the network. Once that is done the hash table lookup from the directory is quite efficient on UNIX because all lookups must be exact matches (unlike on Windows where case insensitive matches are permitted.) The dnlc is also really small and is intended only to permit rapid access for objects that are repeatedly accessed in a short period of time. Jeffrey Altman On 8/11/2014 7:07 AM, chas williams - CONTRACTOR wrote: > On Sun, 10 Aug 2014 00:31:14 -0500 > Troy Benjegerdes <[email protected]> wrote: > >> Part of the problem is also applications that look for random files all >> over the place >> >> I think negative caching and maybe some sort of 'cell-configured' negative >> cache file is going to be necessary. > > Before I go ahead and actually write something again how about a > consensus on where this negative cache should be? I don't think the > dnlc currently supports caching negative information (the comments say > that anyway) but that shouldn't be too hard to fix. Caching negative > entries in afsd would be easier of course. > > I would probably like to be able to examine and purge this cache as > well. This would be sort of vile since it would likely be part of fs > and have to go down to kernel and back up to afsd if negative caching > in afsd (unless we want to do something else like a unix domain socket). > > Anything else? > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel >
smime.p7s
Description: S/MIME Cryptographic Signature
