From common-issues-return-206235-archive-asf-public=cust-asf.ponee.io@hadoop.apache.org Wed Sep 16 17:18:05 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mxout1-he-de.apache.org (mxout1-he-de.apache.org [95.216.194.37]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id 6AA201804BB for ; Wed, 16 Sep 2020 19:18:05 +0200 (CEST) Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-he-de.apache.org (ASF Mail Server at mxout1-he-de.apache.org) with SMTP id 75ABD64388 for ; Wed, 16 Sep 2020 17:18:04 +0000 (UTC) Received: (qmail 80954 invoked by uid 500); 16 Sep 2020 17:18:03 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 80941 invoked by uid 99); 16 Sep 2020 17:18:03 -0000 Received: from ec2-52-202-80-70.compute-1.amazonaws.com (HELO gitbox.apache.org) (52.202.80.70) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Sep 2020 17:18:03 +0000 From: =?utf-8?q?GitBox?= To: common-issues@hadoop.apache.org Subject: =?utf-8?q?=5BGitHub=5D_=5Bhadoop=5D_ayushtkn_commented_on_a_change_in_pull_r?= =?utf-8?q?equest_=232305=3A_HDFS-15578=3A_Fix_the_rename_issues_with_fallba?= =?utf-8?q?ck_fs_enabled?= Message-ID: <160027668314.32230.3827435246842868135.asfpy@gitbox.apache.org> Date: Wed, 16 Sep 2020 17:18:03 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit In-Reply-To: References: ayushtkn commented on a change in pull request #2305: URL: https://github.com/apache/hadoop/pull/2305#discussion_r489589949 ########## File path: hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestViewDistributedFileSystemWithMountLinks.java ########## @@ -61,4 +64,55 @@ public void testCreateOnRoot() throws Exception { public void testMountLinkWithNonExistentLink() throws Exception { testMountLinkWithNonExistentLink(false); } + + @Test + public void testRenameOnInternalDirWithFallback() throws Exception { + Configuration conf = getConf(); + URI defaultFSURI = + URI.create(conf.get(CommonConfigurationKeys.FS_DEFAULT_NAME_KEY)); + final Path hdfsTargetPath1 = new Path(defaultFSURI + "/HDFSUser"); + final Path hdfsTargetPath2 = new Path(defaultFSURI + "/NewHDFSUser/next"); + ViewFsTestSetup.addMountLinksToConf(defaultFSURI.getAuthority(), + new String[] {"/HDFSUser", "/NewHDFSUser/next"}, + new String[] {hdfsTargetPath1.toUri().toString(), + hdfsTargetPath2.toUri().toString()}, conf); + //Making sure parent dir structure as mount points available in fallback. + try (DistributedFileSystem dfs = new DistributedFileSystem()) { + dfs.initialize(defaultFSURI, conf); + dfs.mkdirs(hdfsTargetPath1); + dfs.mkdirs(hdfsTargetPath2); + } + + try (FileSystem fs = FileSystem.get(conf)) { + Path src = new Path("/newFileOnRoot"); + Path dst = new Path("/newFileOnRoot1"); + fs.create(src).close(); + verifyRename(fs, src, dst); + + src = new Path("/newFileOnRoot1"); + dst = new Path("/NewHDFSUser/newFileOnRoot"); + fs.mkdirs(dst.getParent()); + verifyRename(fs, src, dst); + + src = new Path("/NewHDFSUser/newFileOnRoot"); + dst = new Path("/NewHDFSUser/newFileOnRoot1"); + verifyRename(fs, src, dst); + + src = new Path("/NewHDFSUser/newFileOnRoot1"); + dst = new Path("/newFileOnRoot"); + verifyRename(fs, src, dst); + + src = new Path("/HDFSUser/newFileOnRoot1"); + dst = new Path("/HDFSUser/newFileOnRoot"); + fs.create(src).close(); + verifyRename(fs, src, dst); + } + } + + private void verifyRename(FileSystem fs, Path src, Path dst) + throws IOException { + fs.rename(src, dst); + Assert.assertFalse(fs.exists(src)); + Assert.assertTrue(fs.exists(dst)); + } Review comment: Thanx @umamaheswararao for the update. Regarding the Case 2: When the same directory structure isn't available in the fallback. In `ViewFs` I think this was handled and `createParent` was explicitly made `true` always. It would be just for rename this compulsion would be there. Considering a mount entry like -- `/mount/sub1/sub2` --> `/nsPath` if someone calls rename with `dst` as `/mount/sub1/renameFile` will fail, but if he calls create `/mount/sub1/createFile` without `createParent` it would pass and this `create` call will create the internal directory structure as well. So, now again the user calls the same rename command, it would succeed. Same for `mkdir` with `createParent` as `false` This would be little intermittent behavior for the end user, one API behaving differently. Secondly creating the same directory structure at `fallback` just for `rename` to work doesn't seems feasible, It would be too many empty directories, increasing the number of inodes at NN. IIRC something like this, to create empty directories for mount entries in case of RBF was discussed for some issue recently, and UBER folks had concerns with inode numbers going high due to empty directories. I think we should explicitly take care of this in `rename` as well, May be in non-atomic way only? Later we might find a better way, Maybe adding one more flag to `rename2` and argument to `rename` for `createParent` in a follow up. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: users@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: common-issues-help@hadoop.apache.org