Keep in mind that this may not be sufficient to fix the Darwin issues, because darwin not only tries to stat() the entries, it also tries to read a special file in the subdir! Someone would have to check under what circumstances the Finder will try to read the subdir-special file so we can work around that, too.
-derek Nickolai Zeldovich <[EMAIL PROTECTED]> writes: > There once existed the NeXT fakestat hack from Transarc which (tried > to?) prevent the usual "things hang stat'ing /afs/*" lossage. It'd > be nice to implement the same functionality in OpenAFS. However I'm > having trouble figuring out how it worked. Could someone familiar > with this hack clarify some things for me? > > My main concern is the vcache entry returned upon a lookup call for a > mountpoint, and what Fid was returned in that vcache entry. If the > mountpoint has not been evaluated, we must avoid performing a VLDB > lookup on the volume name (if it's a dead cell, the VLDB lookup will > block until it times out). Therefore, we don't know what Fid to put > into the new vcache entry, which means that we can potentially create > multiple vcache entries for the root of the same volume. This seems > like it could potentially lead to issues with locking and dcaches: > there are probably assumptions in the code about uniqueness of vcache > entries, and the locking order for multiple vcaches is "in increasing > vnode order". > > Additionally, various vcache hash tables are based on the Fid, so the > entry will have to be rechained once we find the real Fid. Also, all > VNOPs would have to check if the vnode's Fid has been found yet, and > if not, do EvalMountPoint, using vcache->mvid as the parent. While > neither of these are impossible, I think this is far more complex > than the NeXT hack, from what I've heard. > > An alternative implementation I've been considering would work like > this: > > * lookup() returns the mountpoint symlink vcache entry, with v_type > fudged to VDIR. > > * getattr() fakes some reasonable-looking stat values for mvstat=2 > entries whose real volume root hasn't been found yet. > > * all other AFS VNOPs call a common function for mvstat=2 vnodes, > which would (a) fill in vcache->mvid, like EvalMountPoint, and > (b) return the real volume root vcache from afs_GetVCache. > > This imposes a slight overhead for any operations with volume roots > (an additional GetVCache call for each VNOP). I'm also not certain > if making mountpoint symlink vcaches VDIR instead of VLNK would break > anything.. > > Any comments on either the NeXT hack or my alternative scheme would > be appreciated. > > -- kolya > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > https://lists.openafs.org/mailman/listinfo/openafs-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
