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.
But you are already heading down that path by having a new system attribute. You are also reserving namespace in symlink formats with the case as specified so you don't get out of that problem. Given you need a new system attribute and backup software needs to be able to back that up all your arguments based on backup software for using symlinks don't hold up for me. > 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. Aren't you already doing that by looking at the new attribute and then only parsing the symlink data if it is tagged as a reparse point. I agree with Nico I think this case should use a system attribute as the "tag" like it does now but store the data in an extended attribute (ie the runat ones) that shouldn't require you wait on any new functionality in ZFS. I really don't like the overloading of symlinks particularly given that we have an extended attribute and system attribute capability already. Even more so that this case is actually proposing using a new (all be it) 1 bit system attribute anyway. -- Darren J Moffat
