2009/387 [Pathname Reparse Points]

[Afshin Salek]

Darren J Moffat 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.
> 

We are not really reserving any namespace because the format
that is proposed here cannot be a valid target for a regular symlink.

> 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.
> 

Backup softwares don't need to backup the system attribute because at
the time of restore that bit will be set anyways because fop_symlink
detects the @{REPARSE tag and will set the reparse attribute as
mentioned in the case.

>  > 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

The reparse detection part would be the same but I'm not sure doing
a VOP_READLINK would be as expensive as working with extended
attributes.

Afshin

> 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.
>