[ 
https://issues.apache.org/jira/browse/HADOOP-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lei Yang updated HADOOP-18193:
------------------------------
    Description: 
Defining following client mount table config is not supported in  INodeTree and 
will throw FileAlreadyExistsException

fs.viewfs.mounttable.link./foo/bar=hdfs://nn1/foo/bar

fs.viewfs.mounttable.link./foo=hdfs://nn02/foo

 

INodeTree has 2 methods that need change to support nested mount points.

createLink(..): build INodeTree during fs init.

resolve(..): resolve path in INodeTree with viewfs apis.

 

ViewFileSystem and ViewFs referes INodeTree.resolve(..) to resolve path to 
specific mount point. No changes are expected in both classes. However, we need 
to support existing use cases and make sure no regression are caused.

 

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...)

  was:
Defining following client mount table config is not supported in  INodeTree and 
will throw FileAlreadyExistsException

fs.viewfs.mounttable.link./foo/bar=hdfs://nn1/foo/bar

fs.viewfs.mounttable.link./foo=hdfs://nn02/foo

 

INodeTree has 2 methods that need change to support nested mount points.

createLink(..): build INodeTree during fs init.

resolve(..): resolve path in INodeTree with viewfs apis.

 

ViewFileSystem and ViewFs referes INodeTree.resolve(..) to resolve path to 
specific mount point. No changes are expected in both classes. However, we need 
to support existing use cases and make sure no regression.

 

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...)


> 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
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Defining following client mount table config is not supported in  INodeTree 
> and will throw FileAlreadyExistsException
> fs.viewfs.mounttable.link./foo/bar=hdfs://nn1/foo/bar
> fs.viewfs.mounttable.link./foo=hdfs://nn02/foo
>  
> INodeTree has 2 methods that need change to support nested mount points.
> createLink(..): build INodeTree during fs init.
> resolve(..): resolve path in INodeTree with viewfs apis.
>  
> ViewFileSystem and ViewFs referes INodeTree.resolve(..) to resolve path to 
> specific mount point. No changes are expected in both classes. However, we 
> need to support existing use cases and make sure no regression are caused.
>  
> 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...)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

Reply via email to