[
https://issues.apache.org/jira/browse/HADOOP-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790642#comment-13790642
]
Daryn Sharp commented on HADOOP-10034:
--------------------------------------
I'm of course open to possibilities but I can't see how to do a correct
solution. The suggestion here is akin to a NFS server resolving symlinks for
the client.
The leaking of abstractions into the NN is a bad idea in general. Path
resolution becomes much more complicated. Plus you're also assuming the
semantics of the client fs is a plain/vanilla viewfs. What if I'm using a
merge/union mount (not implemented, but intended per the viewfs code)? What if
I'm using a filter fs that would normally do some action based on the path?
Ie. filter it out path, rewrite it to something else, etc?
For instance, I've considered implementing a filter fs to provide transparent
har support. It would rely on "seeing" the har extension in the path, mask it
to look like a standard directory, and delegating the remainder of the path to
har. Symlinks in the path to the har will break this implementation because
the client won't see the har extension and the NN will throw a FNF.
Server-side resolution becomes very limiting. A better approach may be to
consider providing something like a {{DirectoryWalker}} class that can cache
the intermediate resolutions.
> optimize same-filesystem symlinks by doing resolution server-side
> -----------------------------------------------------------------
>
> Key: HADOOP-10034
> URL: https://issues.apache.org/jira/browse/HADOOP-10034
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs
> Reporter: Colin Patrick McCabe
>
> We should optimize same-filesystem symlinks by doing resolution server-side
> rather than client side, as discussed on HADOOP-9780.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
