hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4044) Create symbolic links in HDFS
Date Mon, 06 Oct 2008 21:25:44 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637240#action_12637240
] 

Konstantin Shvachko commented on HADOOP-4044:
---------------------------------------------

The code looks bizarre (or unclean) with all the FSLink*** return types.
I do not like when exceptions are used for normal control flow.
But looking at what it takes to avoid it I lean to the idea that may be this 
is the exceptional case when we should divert from the general principles.

I see two compromise solutions.

# Introduce a new method {{Path getSymLink(Path src)}}, which returns first symbolic link
in the {{src}} path.
Then all methods {(create(), getBlockLocations(), rename()}}, etc. can throw the {{UnresolvedPathException}}
all the way to the application via FileSystem API. The application can then call {{getSymLink()}}
to resolve the mount point. 
{{UnresolvedPathException}} should be a regular subclass of IOException without any hints
on how the sym link should be resolved. 
I understand that local links are resolved on the name-node. 
So {{UnresolvedPathException}} is thrown only when a mount point is crossed. This is uncommon
and should not be optimized. 
The application itself should call {{getSymLink()}} after either receiving the {{UnresolvedPathException}}
or if it knows about the mount point from its previous activity.
# Another "clean" way to handle this would be to introduce output parameters in RPC framework.
In current RPC all arguments are input only and the only way to return a value is by explicitly
specifying the return value of the protocol method. 
And if you need to return several values you have to wrap them into an object.
This is exactly what makes FSLink*** so ugly.
If we had a way to specify that some arguments are output values then the api would more reasonable.
E.g.
{code}
public FSLink getFileInfo(String inSrc, FileStatus outStatus) throws IOException;
{code}
vs 
{code}
public FSLinkFileStatus getFileInfo(String src) throws IOException;
{code}


> 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, symLink1.patch, symLink4.patch, symLink5.patch,
symLink6.patch, symLink8.patch, symLink9.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.


Mime
View raw message