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