[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629584#action_12629584
]
Sanjay Radia commented on HADOOP-4044:
--------------------------------------
Volume relative symbolic links (e.g. dot relative links) can be handled
_within_ the NN. However, whenever a symbolic link with a remote target is
crossed the client side needs to handle it - I am calling this a kickback.
Note that a symbolic link can occur during an open, create, chmod or any other
operation that supplies a path name. Further it can occur _anywhere_ in the
path.
Hence:
open("/foo/bar/zoo")
bar may be a symbolic link to a remote volume.
A getFileStatus("/foo/bar/zoo") cannot return a status of "is symbolic link":
zoo is not a symbolic link; bar is the
Any operation that involves a path name, can issue a kickback which says: "I
crossed a symbolic link whose target is another file system. I processed a part
of the path and the remaining path is xxx; please resolve the remaining path
xxx at the target of the symbolic link."
In the above example the xxx (rest of path to process) is "zoo".
One way to provide this kickback is to use an exception. (I consider an
alternate below)
_The issue raised in the other comments in this Jira is whether or not an
exception is suitable here - i.e. is this normal or abnormal operation of the
NN?_
Following a *remote* symbolic link is not normal for a NN; it is not normal
for a NN to recursively call another *remote* NN hence the exception is a
reasonable way to deal with this situation.
The FileSystem interface should clearly NOT throw such an exception because
following symbolic links are a normal part of that interface; in this case I am
not suggesting that the FileSystem throws an exception, merely the NN throws
that exception.
Many NameServices handle remote mounts as exceptions or kickbacks. For example
the spring name service at Sun has optional trust relationship between name
servers. If a symbolic link was to a name server with which it had trust
relation then then it followed the symbolic link recursively (using DNS
terminology) and otherwise it did a kickback via an exception and the client
side followed the links iteratively (using DNS terminology again).
An alternate way (really owen's suggestion) is to have open return a "FD" style
object that contains the kickback information inside the FD object. The problem
is that we will need a similar object for all operations that involve a
pathname: open, stat, chmod, rename, etc. (Owen please comment this).
Hence I feel the use of the exception is a better way to do this.
BTW I have a document on the above that I started on a few months ago at Yahoo
but it is not completed. Dhruba suggested that I attach it above; will do so
over the next week or so.
> Create symbolic links in HDFS
> -----------------------------
>
> Key: HADOOP-4044
> URL: https://issues.apache.org/jira/browse/HADOOP-4044
> Project: Hadoop Core
> Issue Type: New Feature
> Components: dfs
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Attachments: symLink1.patch
>
>
> HDFS should support symbolic links. A symbolic link is a special type of file
> that contains a reference to another file or directory in the form of an
> absolute or relative path and that affects pathname resolution. Programs
> which read or write to files named by a symbolic link will behave as if
> operating directly on the target file. However, archiving utilities can
> handle symbolic links specially and manipulate them directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
