[
https://issues.apache.org/jira/browse/HADOOP-18193?focusedWorklogId=768795&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768795
]
ASF GitHub Bot logged work on HADOOP-18193:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 11/May/22 01:02
Start Date: 11/May/22 01:02
Worklog Time Spent: 10m
Work Description: li-leyang commented on code in PR #4181:
URL: https://github.com/apache/hadoop/pull/4181#discussion_r869785802
##########
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/InodeTree.java:
##########
@@ -133,6 +138,11 @@ public INode(String pathToNode, UserGroupInformation aUgi)
{
// and is read only.
abstract boolean isInternalDir();
+ /**
+ * INode representing a INodeDir which also contains a INodeLink(nested
mount point)
+ */
+ abstract boolean isDirAndLink();
+
// INode linking to another filesystem. Represented
// via mount table link config entries.
boolean isLink() {
Review Comment:
> In particular, I'd say that isLink should return true on all links
(internal & leaf)
Yeah, I've considered this but this involves refactoring in
traversal/resolve logic and also change the semantics of isLink() which returns
true for an internal node. (I am more concerned of this from traversal
perspective but it might be contradictory from definition perspective) So I
decided to create a new prop to identify internal node with mount point. But
the downside is I have to add additional check whenever x.isLink() is invoked.
##########
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/InodeTree.java:
##########
@@ -133,6 +138,11 @@ public INode(String pathToNode, UserGroupInformation aUgi)
{
// and is read only.
abstract boolean isInternalDir();
+ /**
+ * INode representing a INodeDir which also contains a INodeLink(nested
mount point)
+ */
+ abstract boolean isDirAndLink();
+
// INode linking to another filesystem. Represented
// via mount table link config entries.
boolean isLink() {
Review Comment:
> In particular, I'd say that isLink should return true on all links
(internal & leaf)
Yeah, I've considered this but this involves refactoring in
traversal/resolve logic and also change the semantics of isLink() which returns
true for an internal node. (I am more concerned of this from traversal
perspective but it might be contradictory from definition perspective) So I
decided to create a new prop to identify internal node with mount point. But
the downside is I have to add additional check whenever x.isLink() is invoked.
Issue Time Tracking
-------------------
Worklog Id: (was: 768795)
Time Spent: 5h 20m (was: 5h 10m)
> Support nested mount points in INodeTree
> ----------------------------------------
>
> Key: HADOOP-18193
> URL: https://issues.apache.org/jira/browse/HADOOP-18193
> Project: Hadoop Common
> Issue Type: Improvement
> Components: viewfs
> Affects Versions: 2.10.0
> Reporter: Lei Yang
> Assignee: Lei Yang
> Priority: Major
> Labels: pull-request-available
> Attachments: Nested Mount Point in ViewFs.pdf
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> Defining following client mount table config is not supported in INodeTree
> and will throw FileAlreadyExistsException
>
> {code:java}
> fs.viewfs.mounttable.link./foo/bar=hdfs://nn1/foo/bar
> fs.viewfs.mounttable.link./foo=hdfs://nn02/foo
> {code}
> INodeTree has 2 methods that need change to support nested mount points.
> {code:java}
> createLink(): build INodeTree during fs init.
> resolve(): resolve path in INodeTree with viewfs apis.
> {code}
> ViewFileSystem and ViewFs maintains an INodeTree instance(fsState) in both
> classes and call fsState.resolve(..) to resolve path to specific mount point.
> INodeTree.resolve encapsulates the logic of nested mount point resolving. So
> no changes are expected in both classes.
> AC:
> # INodeTree.createlink should support creating nested mount
> points.(INodeTree is constructed during fs init)
> # INodeTree.resolve should support resolve path based on nested mount
> points. (INodeTree.resolve is used in viewfs apis)
> # No regression in existing ViewFileSystem and ViewFs apis.
> # Ensure some important apis are not broken with nested mount points.
> (Rename, getContentSummary, listStatus...)
>
> Spec:
> Please review attached pdf for spec about this feature.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
