Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
> Alan.M.Wright wrote:
>> Darren J Moffat <Darren.Moffat at Sun.COM> wrote:
>>> Alan.M.Wright wrote:
>>>>> 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.
>>>
>>> The point is NOT to use symlinks at all but to use a file with an extended
>>> attribute.
>>
>> We've looked at that and similar options in detail within the project team
>> over the past few months. We looked at using files, directories, mount
>> points and introducing a new object type. Each one resulted in issues
>> that seemed insurmountable: using a file to represent a disjoint name space
>> confusing applications that expect to perform normal file operations on it,
>> applications expecting to read or descend into directories, mount points
>> being involved in client-server exchanges and the ramifications of ensuring
>> that a new object type wouldn't result in erroneous behavior. Ultimately,
>> the team came to the conclusion that it wasn't feasible to pursue any of
>> those options and proposed the symlink option.
>
> That is better info than Afshin gave, his reply led me to believe that no
> testing of other means had be fully investigated (at least performance
> wise).
>
> I think given that it seems symlinks are the least worst choice - better
> than a new object type anyway.
>
> This case is reserving namespace and I believe it is also setting precedent
> that we can do so with symlinks.
>
> The prefix characters ('@{' or is it really just '@" ?) you are reserving
> aren't reserved by default in BSD but are only enabled when a filesystem
> option is enabled. We don't have generic options for the VFS layer like BSD
> but there could be a ZFS dataset level option to enable/disable this. I'm
> not sure if it is really worth it though.
We are reserving '@{...}', i.e. the name must start with @{ and end with }.
We considered both a global option and per file system options but, on
the basis that no-one could identify a scenario in which something would
misinterpret these objects and behave badly, we decided not to propose
an enable/disable switch.
Alan
