[
https://issues.apache.org/jira/browse/HADOOP-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538035#comment-17538035
]
Ayush Saxena commented on HADOOP-18193:
---------------------------------------
Coming too late, Sorry [~virajith] was occupied with some stuff internally and
this slipped every time.
Just had a quick look on the PR(It has too many formatting changes as well,
very tough to follow). Some questions here on the design.
* How do you manage permissions/ownership/ACLs in this setup, /foo has some
owner & permissions & /foo/bar has some other, Are we checking relevant
permissions on the parent of bar before operating on the /foo/bar. The Default
ACLs stuff on /foo are they honoured for the child paths? (Default ACL: An ACL
entry to be applied to a directory's children that do not otherwise have their
own ACL defined), if not can impact some Hive usecases.
* How does ContentSummary operate, It gets the data from all the child mounts
as well?
* What about Quotas, say I have quota set on /foo & I have /foo/bar1 &
/foo/bar2, well do we honour the usage.
* Similarly like the Storage Policies and all, will they get propagated to
child mounts?
* From one of the tests, I see, Even if the target FS is same, but the paths
land up in different mounts, we disallow copy. Why? I think that should be
allowed. RBF allows that as well, There are logics where the Client matches the
target FS and decides whether to rename or Copy. Since the Target FS is same it
would call for rename rather than copy and it is gonna fail. Did I catch this
wrong. Something similar is there in MoveTask for Hive.
I can't remember exactly, but during ViewFsOverloadScheme or ViewDFS also we
made some assumptions regarding Nested Mounts aren't supported so X use case
won't occur and hence we are safe. And now I forgot was that....
> 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
> Fix For: 3.4.0
>
> Attachments: Nested Mount Point in ViewFs.pdf
>
> Time Spent: 7h 40m
> 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]
