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

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

Doug> Does that address your question?

Yes it does in the way that I see you are changing the subject.
It was about exception usage, now it is about monolithic layers of HDFS.
Since the programming style correctness is not measurable as opposed to 
performance there is no definite answer on what is correct/incorrect, and 
therefore the discussion clearly can go on forever. If one argument is 
exhausted another can be raised or linked to the previous, and so on.

Although the question you raise is interesting by itself.
HDFS is not a single monolithic layer the same way as Hadoop is not a single 
layer. MapReduce as a layer on top of HDFS but we do not impose the knowledge 
of splits upon the file system. Going further up the stack we also do not 
require HDFS to recognize HBase records or files corresponding to columns in a 
table store.

HDFS layers are clearly different abstractions. E.g., NameNode does not know 
about input and output streams. Sure, the layers have common structures, say 
FileStatus is visible to all layers, but ContentSummary is constructed on the 
top FileSystem level.

I don't think this argument works in favor of your approach and justifies 
passing link values through the whole hierarchy of HDFS layers.

> 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: HADOOP-4044-strawman.patch, 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.

Reply via email to