Afshin Salek wrote:
>
>
> 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.
Yes you are, by adopting the BSD magic link syntax that is reserving
namespace. It is reserving symlink content starting with @ and
specifically the part of the @ namespace that begins @{REPARSE.
How is that not reserving namespace ?
Today this works:
braveheart:pts/1# ls -l
total 4
-rw-r--r-- 1 root root 12 Jul 14 11:10 @{REPARSE}
lrwxrwxrwx 1 root root 10 Jul 14 11:07 foo -> @{REPARSE}
braveheart:pts/1# cat foo
hello world
braveheart:pts/1# cat @\{REPARSE\}
hello world
After your change what happens ?
Are those slightly crazy and contrived filenames ? Yes but they are
valid today.
>> 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.
Okay that is helpful. So there is now code in the normal fop_symlink
path to look at the content for the @{REPARSE namespace and set a system
attribute. What happens if I already had symlinks that looked like that ?
>> > 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.
So you haven't actually tried it yet you are saying it is too expensive.
How expensive is too expensive ? What is the performance criteria and
how do you know that VOP_READLINK meets it yet using an extended
attribute wouldn't ?
--
Darren J Moffat
