Darren J Moffat wrote:
> 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 ?
>
I didn't mean to imply that we rejected the extended attribute idea
just because of perceived performance issues. Actually, there are a
number of issues regarding extended attributes including:
- currently, symlinks can't have EAs
- need to make sure a directory is empty before marking it as reparse
point
- once a directory is marked as reparse point, FS and/or VFS needs to
make sure nothing can be created in the directory
- defining semantics of different operations performed by applications
against a normal file/dir vs a file/dir that has been marked as RP
overall considering different aspects of other methods that we've
considered including using EAs, it seemed that using symlinks is the
less complicated approach.
Afshin
