On Mon, Jul 13, 2009 at 03:44:42PM -0700, Afshin Salek wrote: > This is supposed to be a generic and expandable mechanism. NFS/DFS > referrals are just primary consumers of this mechanism at this > point so this is not a protocol specific mechanism to have a per > protocol extended attribute that are hard coded before hand. > > If we want to use extended attributes then we either have to reserve > some namespace or use an extended attribute with a reserved name as an > index. It also makes path name reduction very expensive because for each > component we have to do a lot of extra stuff to see whether we are > dealing with a reparse point or not and whether that reparse point > contains the data that we are interested in.
I'd stick with the ESA as the optimization, but EAs for storing the referral if you can manage the namespace, else make the symlink thing not-an-interface and provide a CLI, so you can change the implementation later. Oh, hmmm, I just noticed that the reparse string format is private. But I see no public interfaces for managing reparse points. Are UIs due later? If so never mind my comments to date. Nico --
