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