[ https://issues.apache.org/jira/browse/HDFS-15578?focusedWorklogId=484555&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484555 ]
ASF GitHub Bot logged work on HDFS-15578: ----------------------------------------- Author: ASF GitHub Bot Created on: 15/Sep/20 15:17 Start Date: 15/Sep/20 15:17 Worklog Time Spent: 10m Work Description: umamaheswararao edited a comment on pull request #2305: URL: https://github.com/apache/hadoop/pull/2305#issuecomment-692781129 @ayushtkn Thanks a lot for the review! >Just want to confirm, In rename, do we need to avoid any scenario like HDFS-15444? Or that is guarded already. I actually considered that case, the first time is without last component. If that resolve result indicates it as InternalDir, then we are again resolving with including lastComponent ( means with children ). In this case if it again indicates internalDir or lastDirAsLink, then we are throwing exception as we can not rename to any internal dir/link path. ``` InodeTree.ResolveResult<FileSystem> resDst = fsState.resolve(getUriPath(dst), false); if (resDst.isInternalDir() && fsState.getRootFallbackLink() != null) { InodeTree.ResolveResult<FileSystem> resDstWithLastComp = fsState.resolve(getUriPath(dst), true); // resolveLastComponent with true is to check if the target already // exist in internalDir/InternalDirLink itself. if (resDstWithLastComp.isInternalDir() || resDstWithLastComp .isLastInternalDirLink()) { throw readOnlyMountTable("rename", dst); ``` There is one condition without fallback, we may attempt to rename. Probably we need else, as we are combining if check with fsState.getRootFallbackLink() != null as well. I will update patch. Thanks >Secondly, In resolve result, can we change the constructor directly?, or do we need to have an overloaded constructor to avoid compatibility issues, that might have saved couple of changes as well. Currently the InodeTree interface audience is Private. I don't believe any application holds class in separate jar. or serialize this class result to remote service where they will use different jar. Let me know in case if it's popping any potential compatibility breakage. @InterfaceAudience.Private @InterfaceStability.Unstable abstract class InodeTree<T> { ---------------------------------------------------------------- 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: us...@infra.apache.org Issue Time Tracking ------------------- Worklog Id: (was: 484555) Time Spent: 20m (was: 10m) > Fix the rename issues with fallback fs enabled > ---------------------------------------------- > > Key: HDFS-15578 > URL: https://issues.apache.org/jira/browse/HDFS-15578 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: viewfs, viewfsOverloadScheme > Affects Versions: 3.4.0 > Reporter: Uma Maheswara Rao G > Assignee: Uma Maheswara Rao G > Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When we enable fallback, rename should success if the src.parent or > dst.parent on inernalDir. > {noformat} > org.apache.hadoop.security.AccessControlException: InternalDir of > ViewFileSystem is readonly, operation rename not permitted on path > /newFileOnRoot.org.apache.hadoop.security.AccessControlException: InternalDir > of ViewFileSystem is readonly, operation rename not permitted on path > /newFileOnRoot. > at > org.apache.hadoop.fs.viewfs.ViewFileSystem.readOnlyMountTable(ViewFileSystem.java:95) > at > org.apache.hadoop.fs.viewfs.ViewFileSystem.readOnlyMountTable(ViewFileSystem.java:101) > at > org.apache.hadoop.fs.viewfs.ViewFileSystem.rename(ViewFileSystem.java:683) at > org.apache.hadoop.hdfs.ViewDistributedFileSystem.rename(ViewDistributedFileSystem.java:533) > at > org.apache.hadoop.hdfs.TestViewDistributedFileSystemWithMountLinks.verifyRename(TestViewDistributedFileSystemWithMountLinks.java:114) > at > org.apache.hadoop.hdfs.TestViewDistributedFileSystemWithMountLinks.testRenameOnInternalDirWithFallback(TestViewDistributedFileSystemWithMountLinks.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at > org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at > org.junit.runner.JUnitCore.run(JUnitCore.java:137) at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33) > at > com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230) > at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58){noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org