[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649135#action_12649135
]
Konstantin Shvachko commented on HADOOP-4044:
---------------------------------------------
# We should have some *performance testing*. There is a lot of
wrapping/unwrapping going on. So we need to make sure that old operations like
{{getBlockLocations(), create(), list()}} etc. on the {{FileSystem}} level
perform the same as the old code.
# > I suggest we use Dhruba's implementation and do the improvement later.
I don't understand what is the problem here.
Nichlas proposes to have 2 classes {{FsResult<T>}} and {{FsResultWritable<T>}}
which extends {{FsResult<T>}}.
This is exactly what should be done here. {{ClientProtocol}} methods should
return {{FsResultWritable<T>}}, while {{DFSClient}} and all other
{{\*FileSystem}} classes should return {{FsResult<T>}}. This is because
Writable is needed only in the RPC level, after that Writable is not required.
E.g.
{code}
interface ClientProtocol {
FsResultWritable<LocatedBlocks> setReplication(...);
FsResultWritable<NullWritable> create(...);
}
class DFSClient {
FsResult<LocatedBlocks> setReplication(...) {
return namenode.setReplication(...); // can do this because
FsResultWritable is a subclass of FsResult
}
FsResult<OutputStream> create(...) {
return new FsResult<OutputStream>(new DFSOutputStream(...));
}
}
{code}
# I did not review the code. Just looked in few places.
- Looks like FsResult constructors do not need to throw any exceptions.
- {{DFSClient.getHints()}} is deprecated. It is a good time to remove it.
> 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
> Fix For: 0.20.0
>
> Attachments: 4044_20081030spi.java, HADOOP-4044-strawman.patch,
> symLink1.patch, symLink1.patch, symLink11.patch, symLink12.patch,
> symLink13.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.
