This is an automated email from the ASF dual-hosted git repository.

umamahesh pushed a commit to branch branch-3.1
in repository https://gitbox.apache.org/repos/asf/hadoop.git


The following commit(s) were added to refs/heads/branch-3.1 by this push:
     new 1768618  HDFS-15478: When Empty mount points, we are assigning 
fallback link to self. But it should not use full URI for target fs. (#2160). 
Contributed by Uma Maheswara Rao G.
1768618 is described below

commit 1768618ab948fbd0cfdfa481a2ece124e10e33ec
Author: Uma Maheswara Rao G <umamah...@apache.org>
AuthorDate: Tue Jul 21 23:29:10 2020 -0700

    HDFS-15478: When Empty mount points, we are assigning fallback link to 
self. But it should not use full URI for target fs. (#2160). Contributed by Uma 
Maheswara Rao G.
    
    (cherry picked from commit ac9a07b51aefd0fd3b4602adc844ab0f172835e3)
---
 .../apache/hadoop/fs/viewfs/ViewFileSystem.java    |  2 +-
 .../viewfs/TestViewFsOverloadSchemeListStatus.java | 27 +++++++++++++++-------
 .../src/site/markdown/ViewFsOverloadScheme.md      |  2 ++
 3 files changed, 22 insertions(+), 9 deletions(-)

diff --git 
a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java
 
b/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java
index 484581c..b441483 100644
--- 
a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java
+++ 
b/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java
@@ -292,7 +292,7 @@ public class ViewFileSystem extends FileSystem {
       myUri = new URI(getScheme(), authority, "/", null, null);
       boolean initingUriAsFallbackOnNoMounts =
           !FsConstants.VIEWFS_TYPE.equals(getType());
-      fsState = new InodeTree<FileSystem>(conf, tableName, theUri,
+      fsState = new InodeTree<FileSystem>(conf, tableName, myUri,
           initingUriAsFallbackOnNoMounts) {
         @Override
         protected FileSystem getTargetFileSystem(final URI uri)
diff --git 
a/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/viewfs/TestViewFsOverloadSchemeListStatus.java
 
b/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/viewfs/TestViewFsOverloadSchemeListStatus.java
index 300fdd8..7afc789 100644
--- 
a/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/viewfs/TestViewFsOverloadSchemeListStatus.java
+++ 
b/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/viewfs/TestViewFsOverloadSchemeListStatus.java
@@ -127,19 +127,30 @@ public class TestViewFsOverloadSchemeListStatus {
 
   /**
    * Tests that ViewFSOverloadScheme should consider initialized fs as fallback
-   * if there are no mount links configured.
+   * if there are no mount links configured. It should add fallback with the
+   * chrootedFS at it's uri's root.
    */
   @Test(timeout = 30000)
   public void testViewFSOverloadSchemeWithoutAnyMountLinks() throws Exception {
-    try (FileSystem fs = FileSystem.get(TEST_DIR.toPath().toUri(), conf)) {
+    Path initUri = new Path(TEST_DIR.toURI().toString(), "init");
+    try (FileSystem fs = FileSystem.get(initUri.toUri(), conf)) {
       ViewFileSystemOverloadScheme vfs = (ViewFileSystemOverloadScheme) fs;
       assertEquals(0, vfs.getMountPoints().length);
-      Path testFallBack = new Path("test", FILE_NAME);
-      assertTrue(vfs.mkdirs(testFallBack));
-      FileStatus[] status = vfs.listStatus(testFallBack.getParent());
-      assertEquals(FILE_NAME, status[0].getPath().getName());
-      assertEquals(testFallBack.getName(),
-          vfs.getFileLinkStatus(testFallBack).getPath().getName());
+      Path testOnFallbackPath = new Path(TEST_DIR.toURI().toString(), "test");
+      assertTrue(vfs.mkdirs(testOnFallbackPath));
+      FileStatus[] status = vfs.listStatus(testOnFallbackPath.getParent());
+      assertEquals(Path.getPathWithoutSchemeAndAuthority(testOnFallbackPath),
+          Path.getPathWithoutSchemeAndAuthority(status[0].getPath()));
+      //Check directly on localFS. The fallBackFs(localFS) should be chrooted
+      //at it's root. So, after
+      FileSystem lfs = vfs.getRawFileSystem(testOnFallbackPath, conf);
+      FileStatus[] statusOnLocalFS =
+          lfs.listStatus(testOnFallbackPath.getParent());
+      assertEquals(testOnFallbackPath.getName(),
+          statusOnLocalFS[0].getPath().getName());
+      //initUri should not have exist in lfs, as it would have chrooted on it's
+      // root only.
+      assertFalse(lfs.exists(initUri));
     }
   }
 
diff --git 
a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/ViewFsOverloadScheme.md 
b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/ViewFsOverloadScheme.md
index 564bc03..f3eb336 100644
--- a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/ViewFsOverloadScheme.md
+++ b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/ViewFsOverloadScheme.md
@@ -34,6 +34,8 @@ If a user wants to continue use the same fs.defaultFS and 
wants to have more mou
 Example if fs.defaultFS is `hdfs://mycluster`, then the mount link 
configuration key name should be like in the following format 
`fs.viewfs.mounttable.*mycluster*.link.<mountLinkPath>`.
 Even if the initialized fs uri has hostname:port, it will simply ignore the 
port number and only consider the hostname as the mount table name.  We will 
discuss more example configurations in following sections.
 If there are no mount links configured with the initializing uri's hostname as 
the mount table name, then it will automatically consider the current uri as 
fallback(`fs.viewfs.mounttable.*mycluster*.linkFallback`) target fs uri.
+If the initialized uri contains path part, it will consider only scheme and 
authority part, but not the path part. Example, if the initialized uri contains 
`hdfs://mycluster/data`, it will consider only `hdfs://mycluster` as fallback 
target fs uri.
+The path part `data` will be ignored.
 
 Another important improvement with the ViewFileSystemOverloadScheme is, 
administrators need not copy the `mount-table.xml` configuration file to 1000s 
of client nodes. Instead, they can keep the mount-table configuration file in a 
Hadoop compatible file system. So, keeping the configuration file in a central 
place makes administrators life easier as they can update mount-table in single 
place.
 


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

Reply via email to