Darren J Moffat <Darren.Moffat at Sun.COM> wrote: > 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.
We can't do that with this proposal because symlink can't have extended attributes. Alan > 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 >
