[ https://issues.apache.org/jira/browse/HADOOP-18193?focusedWorklogId=769191&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-769191 ]
ASF GitHub Bot logged work on HADOOP-18193: ------------------------------------------- Author: ASF GitHub Bot Created on: 11/May/22 16:51 Start Date: 11/May/22 16:51 Worklog Time Spent: 10m Work Description: omalley commented on code in PR #4181: URL: https://github.com/apache/hadoop/pull/4181#discussion_r870542414 ########## hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/InodeTree.java: ########## @@ -682,6 +748,32 @@ protected InodeTree(final Configuration config, final String viewName, } } + /** Review Comment: I would argue that the simplicity of always sorting is better than the O(mount*log(mount)) cost that happens once when the file system is created. In fact, you at that point could move the flag into the constructor. Issue Time Tracking ------------------- Worklog Id: (was: 769191) Time Spent: 6h (was: 5h 50m) > 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: 6h > 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org