2009/387 [Pathname Reparse Points]

[Alan.M.Wright]

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
>