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 ac9a07b51a
)
This commit is contained in:
parent
ae8261c671
commit
4fe491d10e
|
@ -294,7 +294,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)
|
||||
|
|
|
@ -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));
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue