[jira] [Commented] (HDFS-15627) Audit log deletes after edit is written
[ https://issues.apache.org/jira/browse/HDFS-15627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214387#comment-17214387 ] Ahmed Hussein commented on HDFS-15627: -- [~jianghuazhu], this patch does not delete "Audit-log". The patch changes the order in which the delete event is into the audit-log, moving it up to be done before incremental deletes. The tweak is suggested by [~daryn] to make debugging easier. [~daryn] noticed that the audit-log has a lag in recording the delete-event. As a result, when you check the audit-log, you might not see anything there. However, audit-log for delete event was pending because there are so many incremental deletes. > Audit log deletes after edit is written > --- > > Key: HDFS-15627 > URL: https://issues.apache.org/jira/browse/HDFS-15627 > Project: Hadoop HDFS > Issue Type: Bug > Components: logging, namenode >Reporter: Ahmed Hussein >Assignee: Ahmed Hussein >Priority: Major > Attachments: HDFS-15627.001.patch > > > Deletes currently collect blocks in the write lock, write the edit, > incrementally block delete, finally +audit log+. It should be collect blocks, > edit log, +audit log+, incremental delete. Once the edit is durable it's > consistent to audit log the delete. There is no sense in deferring the audit > into the indeterminate future. > The problem occurs when thereto server hung due to large deletes but it won't > be easy to identify the problem. That should have been easily identified as > the first delete logged after the hang. -- 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
[jira] [Commented] (HDFS-15627) Audit log deletes after edit is written
[ https://issues.apache.org/jira/browse/HDFS-15627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214377#comment-17214377 ] JiangHua Zhu commented on HDFS-15627: - Hello, [~ahussein] . Why delete the audit log here. It should be useful here. > Audit log deletes after edit is written > --- > > Key: HDFS-15627 > URL: https://issues.apache.org/jira/browse/HDFS-15627 > Project: Hadoop HDFS > Issue Type: Bug > Components: logging, namenode >Reporter: Ahmed Hussein >Assignee: Ahmed Hussein >Priority: Major > Attachments: HDFS-15627.001.patch > > > Deletes currently collect blocks in the write lock, write the edit, > incrementally block delete, finally +audit log+. It should be collect blocks, > edit log, +audit log+, incremental delete. Once the edit is durable it's > consistent to audit log the delete. There is no sense in deferring the audit > into the indeterminate future. > The problem occurs when thereto server hung due to large deletes but it won't > be easy to identify the problem. That should have been easily identified as > the first delete logged after the hang. -- 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
[jira] [Commented] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations.
[ https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214376#comment-17214376 ] Chengwei Wang commented on HDFS-15630: -- [~ferhui] thanks for review. Submit patch v002 [^HDFS-15630.002.patch] to fix the related failed UT. And I will try to create a github PR later. > RBF: Fix wrong client IP info in CallerContext when requests mount points > with multi-destinations. > -- > > Key: HDFS-15630 > URL: https://issues.apache.org/jira/browse/HDFS-15630 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: rbf >Reporter: Chengwei Wang >Assignee: Chengwei Wang >Priority: Major > Attachments: HDFS-15630.001.patch, HDFS-15630.002.patch > > > There are two issues about client IP info in CallerContext when we try to > request mount points with multi-destinations. > # the clientIp would duplicate in CallerContext when > RouterRpcClient#invokeSequential. > # the clientIp would miss in CallerContext when > RouterRpcClient#invokeConcurrent. -- 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
[jira] [Updated] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations.
[ https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengwei Wang updated HDFS-15630: - Attachment: HDFS-15630.002.patch > RBF: Fix wrong client IP info in CallerContext when requests mount points > with multi-destinations. > -- > > Key: HDFS-15630 > URL: https://issues.apache.org/jira/browse/HDFS-15630 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: rbf >Reporter: Chengwei Wang >Assignee: Chengwei Wang >Priority: Major > Attachments: HDFS-15630.001.patch, HDFS-15630.002.patch > > > There are two issues about client IP info in CallerContext when we try to > request mount points with multi-destinations. > # the clientIp would duplicate in CallerContext when > RouterRpcClient#invokeSequential. > # the clientIp would miss in CallerContext when > RouterRpcClient#invokeConcurrent. -- 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
[jira] [Commented] (HDFS-15631) dfsadmin -report with RBF returns multiple capacity and used info
[ https://issues.apache.org/jira/browse/HDFS-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214364#comment-17214364 ] Shen Yinjie commented on HDFS-15631: Yes，all the datanodes are shared. As I know, mixed cluster with federation and independent cluster is also allowed in RBF. I take a simple fix: when calling getStats() API , remove duplicate FederationNamespaceInfo by clusterId, then invoke and merge in the same way as before. > dfsadmin -report with RBF returns multiple capacity and used info > - > > Key: HDFS-15631 > URL: https://issues.apache.org/jira/browse/HDFS-15631 > Project: Hadoop HDFS > Issue Type: Bug > Components: rbf >Affects Versions: 3.0.1 >Reporter: Shen Yinjie >Assignee: Shen Yinjie >Priority: Major > > When RBF enabled,we execute `hdfs dfsadmin -report` with RBF ns, the return > capacity is a multiple of the number of nss -- 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
[jira] [Updated] (HDFS-15628) HttpFS server throws NPE if a file is a symlink
[
https://issues.apache.org/jira/browse/HDFS-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kihwal Lee updated HDFS-15628:
--
Fix Version/s: 3.2.3
> HttpFS server throws NPE if a file is a symlink
> ---
>
> Key: HDFS-15628
> URL: https://issues.apache.org/jira/browse/HDFS-15628
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: fs, httpfs
>Reporter: Ahmed Hussein
>Assignee: Ahmed Hussein
>Priority: Major
> Fix For: 3.3.1, 3.4.0, 3.2.3
>
> Attachments: HDFS-15628.001.patch, HDFS-15628.002.patch
>
>
> If a directory containing a symlink is listed, the client (WebHfdsFileSystem)
> blows up with a NPE. If {{type}} is {{SYMLINK}}, there must be {{symlink}}
> field whose value is the link target string. HttpFS returns a response
> without {{symlink}} filed. {{WebHfdsFileSystem}} assumes it is there for a
> symlink and blindly tries to parse it, causing NPE.
> This is not an issue if the destination cluster does not have symlinks
> enabled.
>
> {code:bash}
> java.io.IOException: localhost:55901: Response decoding failure:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$FsPathResponseRunner.getResponse(WebHdfsFileSystem.java:967)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.runWithRetry(WebHdfsFileSystem.java:816)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.access$100(WebHdfsFileSystem.java:638)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner$1.run(WebHdfsFileSystem.java:676)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.run(WebHdfsFileSystem.java:672)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.listStatus(WebHdfsFileSystem.java:1731)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testListSymLinkStatus(BaseTestHttpFSWith.java:388)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.operation(BaseTestHttpFSWith.java:1230)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testOperation(BaseTestHttpFSWith.java:1363)
> 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.apache.hadoop.test.TestHdfsHelper$HdfsStatement.evaluate(TestHdfsHelper.java:95)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> at
> org.apache.hadoop.test.TestExceptionHelper$1.evaluate(TestExceptionHelper.java:42)
> at
> org.apache.hadoop.test.TestJettyHelper$1.evaluate(TestJettyHelper.java:74)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at
[jira] [Updated] (HDFS-15628) HttpFS server throws NPE if a file is a symlink
[
https://issues.apache.org/jira/browse/HDFS-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kihwal Lee updated HDFS-15628:
--
Fix Version/s: 3.4.0
3.3.1
Hadoop Flags: Reviewed
Resolution: Fixed
Status: Resolved (was: Patch Available)
> HttpFS server throws NPE if a file is a symlink
> ---
>
> Key: HDFS-15628
> URL: https://issues.apache.org/jira/browse/HDFS-15628
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: fs, httpfs
>Reporter: Ahmed Hussein
>Assignee: Ahmed Hussein
>Priority: Major
> Fix For: 3.3.1, 3.4.0
>
> Attachments: HDFS-15628.001.patch, HDFS-15628.002.patch
>
>
> If a directory containing a symlink is listed, the client (WebHfdsFileSystem)
> blows up with a NPE. If {{type}} is {{SYMLINK}}, there must be {{symlink}}
> field whose value is the link target string. HttpFS returns a response
> without {{symlink}} filed. {{WebHfdsFileSystem}} assumes it is there for a
> symlink and blindly tries to parse it, causing NPE.
> This is not an issue if the destination cluster does not have symlinks
> enabled.
>
> {code:bash}
> java.io.IOException: localhost:55901: Response decoding failure:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$FsPathResponseRunner.getResponse(WebHdfsFileSystem.java:967)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.runWithRetry(WebHdfsFileSystem.java:816)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.access$100(WebHdfsFileSystem.java:638)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner$1.run(WebHdfsFileSystem.java:676)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.run(WebHdfsFileSystem.java:672)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.listStatus(WebHdfsFileSystem.java:1731)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testListSymLinkStatus(BaseTestHttpFSWith.java:388)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.operation(BaseTestHttpFSWith.java:1230)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testOperation(BaseTestHttpFSWith.java:1363)
> 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.apache.hadoop.test.TestHdfsHelper$HdfsStatement.evaluate(TestHdfsHelper.java:95)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> at
> org.apache.hadoop.test.TestExceptionHelper$1.evaluate(TestExceptionHelper.java:42)
> at
> org.apache.hadoop.test.TestJettyHelper$1.evaluate(TestJettyHelper.java:74)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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
[jira] [Updated] (HDFS-15628) HttpFS server throws NPE if a file is a symlink
[
https://issues.apache.org/jira/browse/HDFS-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kihwal Lee updated HDFS-15628:
--
Summary: HttpFS server throws NPE if a file is a symlink (was: https
throws NPE if a file is a symlink)
> HttpFS server throws NPE if a file is a symlink
> ---
>
> Key: HDFS-15628
> URL: https://issues.apache.org/jira/browse/HDFS-15628
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: fs, httpfs
>Reporter: Ahmed Hussein
>Assignee: Ahmed Hussein
>Priority: Major
> Attachments: HDFS-15628.001.patch, HDFS-15628.002.patch
>
>
> If a directory containing a symlink is listed, the client (WebHfdsFileSystem)
> blows up with a NPE. If {{type}} is {{SYMLINK}}, there must be {{symlink}}
> field whose value is the link target string. HttpFS returns a response
> without {{symlink}} filed. {{WebHfdsFileSystem}} assumes it is there for a
> symlink and blindly tries to parse it, causing NPE.
> This is not an issue if the destination cluster does not have symlinks
> enabled.
>
> {code:bash}
> java.io.IOException: localhost:55901: Response decoding failure:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$FsPathResponseRunner.getResponse(WebHdfsFileSystem.java:967)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.runWithRetry(WebHdfsFileSystem.java:816)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.access$100(WebHdfsFileSystem.java:638)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner$1.run(WebHdfsFileSystem.java:676)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.run(WebHdfsFileSystem.java:672)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.listStatus(WebHdfsFileSystem.java:1731)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testListSymLinkStatus(BaseTestHttpFSWith.java:388)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.operation(BaseTestHttpFSWith.java:1230)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testOperation(BaseTestHttpFSWith.java:1363)
> 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.apache.hadoop.test.TestHdfsHelper$HdfsStatement.evaluate(TestHdfsHelper.java:95)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> at
> org.apache.hadoop.test.TestExceptionHelper$1.evaluate(TestExceptionHelper.java:42)
> at
> org.apache.hadoop.test.TestJettyHelper$1.evaluate(TestJettyHelper.java:74)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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
[jira] [Commented] (HDFS-15628) https throws NPE if a file is a symlink
[
https://issues.apache.org/jira/browse/HDFS-15628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214306#comment-17214306
]
Kihwal Lee commented on HDFS-15628:
---
+1 LGTM. We've been running the same server-side change for over 2 years now.
> https throws NPE if a file is a symlink
> ---
>
> Key: HDFS-15628
> URL: https://issues.apache.org/jira/browse/HDFS-15628
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: fs, httpfs
>Reporter: Ahmed Hussein
>Assignee: Ahmed Hussein
>Priority: Major
> Attachments: HDFS-15628.001.patch, HDFS-15628.002.patch
>
>
> If a directory containing a symlink is listed, the client (WebHfdsFileSystem)
> blows up with a NPE. If {{type}} is {{SYMLINK}}, there must be {{symlink}}
> field whose value is the link target string. HttpFS returns a response
> without {{symlink}} filed. {{WebHfdsFileSystem}} assumes it is there for a
> symlink and blindly tries to parse it, causing NPE.
> This is not an issue if the destination cluster does not have symlinks
> enabled.
>
> {code:bash}
> java.io.IOException: localhost:55901: Response decoding failure:
> java.lang.NullPointerException
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$FsPathResponseRunner.getResponse(WebHdfsFileSystem.java:967)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.runWithRetry(WebHdfsFileSystem.java:816)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.access$100(WebHdfsFileSystem.java:638)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner$1.run(WebHdfsFileSystem.java:676)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$AbstractRunner.run(WebHdfsFileSystem.java:672)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.listStatus(WebHdfsFileSystem.java:1731)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testListSymLinkStatus(BaseTestHttpFSWith.java:388)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.operation(BaseTestHttpFSWith.java:1230)
> at
> org.apache.hadoop.fs.http.client.BaseTestHttpFSWith.testOperation(BaseTestHttpFSWith.java:1363)
> 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.apache.hadoop.test.TestHdfsHelper$HdfsStatement.evaluate(TestHdfsHelper.java:95)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> at
> org.apache.hadoop.test.TestExceptionHelper$1.evaluate(TestExceptionHelper.java:42)
> at
> org.apache.hadoop.test.TestJettyHelper$1.evaluate(TestJettyHelper.java:74)
> at
> org.apache.hadoop.test.TestDirHelper$1.evaluate(TestDirHelper.java:106)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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
[jira] [Commented] (HDFS-15548) Allow configuring DISK/ARCHIVE storage types on same device mount
[ https://issues.apache.org/jira/browse/HDFS-15548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214300#comment-17214300 ] Leon Gao commented on HDFS-15548: - [~vinayakumarb] [~ayushtkn] [~weichiu] Could you please take a second look at the PR? > Allow configuring DISK/ARCHIVE storage types on same device mount > - > > Key: HDFS-15548 > URL: https://issues.apache.org/jira/browse/HDFS-15548 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: datanode >Reporter: Leon Gao >Assignee: Leon Gao >Priority: Major > Labels: pull-request-available > Time Spent: 5h 50m > Remaining Estimate: 0h > > We can allow configuring DISK/ARCHIVE storage types on the same device mount > on two separate directories. > Users should be able to configure the capacity for each. Also, the datanode > usage report should report stats correctly. -- 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
[jira] [Commented] (HDFS-15618) Improve datanode shutdown latency
[ https://issues.apache.org/jira/browse/HDFS-15618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214271#comment-17214271 ] Kihwal Lee commented on HDFS-15618: --- The patch looks okay. Although it is better than the previous value of 5 minutes, the default timeout of 60 seconds seems still excessive. How about making it 5 seconds? > Improve datanode shutdown latency > - > > Key: HDFS-15618 > URL: https://issues.apache.org/jira/browse/HDFS-15618 > Project: Hadoop HDFS > Issue Type: Bug > Components: datanode >Reporter: Ahmed Hussein >Assignee: Ahmed Hussein >Priority: Major > Attachments: HDFS-15618.001.patch, HDFS-15618.002.patch > > > The shutdown of Datanode is a very long latency. A block scanner waits for 5 > minutes to join on each VolumeScanner thread. > Since the scanners are daemon threads and do not alter the block content, it > is safe to ignore such conditions on shutdown of Datanode. -- 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
[jira] [Updated] (HDFS-15633) Avoid redundant RPC calls for getDiskStatus
[
https://issues.apache.org/jira/browse/HDFS-15633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated HDFS-15633:
--
Labels: pull-request-available (was: )
> Avoid redundant RPC calls for getDiskStatus
> ---
>
> Key: HDFS-15633
> URL: https://issues.apache.org/jira/browse/HDFS-15633
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: dfsclient
>Reporter: Ayush Saxena
>Assignee: Ayush Saxena
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are 3 RPC calls to fetch the same values :
> {code:java}
> public FsStatus getDiskStatus() throws IOException {
> return new FsStatus(getStateByIndex(0),
> getStateByIndex(1), getStateByIndex(2));
> }
> {code}
> {{getStateByIndex()}} is called thrice, which is actually a {{getStats}} RPC
> to namenode, The same could have been achieved by just one call
--
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
[jira] [Work logged] (HDFS-15633) Avoid redundant RPC calls for getDiskStatus
[
https://issues.apache.org/jira/browse/HDFS-15633?focusedWorklogId=500831=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-500831
]
ASF GitHub Bot logged work on HDFS-15633:
-
Author: ASF GitHub Bot
Created on: 14/Oct/20 20:07
Start Date: 14/Oct/20 20:07
Worklog Time Spent: 10m
Work Description: ayushtkn opened a new pull request #2386:
URL: https://github.com/apache/hadoop/pull/2386
https://issues.apache.org/jira/browse/HDFS-15633
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: 500831)
Remaining Estimate: 0h
Time Spent: 10m
> Avoid redundant RPC calls for getDiskStatus
> ---
>
> Key: HDFS-15633
> URL: https://issues.apache.org/jira/browse/HDFS-15633
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: dfsclient
>Reporter: Ayush Saxena
>Assignee: Ayush Saxena
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are 3 RPC calls to fetch the same values :
> {code:java}
> public FsStatus getDiskStatus() throws IOException {
> return new FsStatus(getStateByIndex(0),
> getStateByIndex(1), getStateByIndex(2));
> }
> {code}
> {{getStateByIndex()}} is called thrice, which is actually a {{getStats}} RPC
> to namenode, The same could have been achieved by just one call
--
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
[jira] [Created] (HDFS-15633) Avoid redundant RPC calls for getDiskStatus
Ayush Saxena created HDFS-15633:
---
Summary: Avoid redundant RPC calls for getDiskStatus
Key: HDFS-15633
URL: https://issues.apache.org/jira/browse/HDFS-15633
Project: Hadoop HDFS
Issue Type: Improvement
Components: dfsclient
Reporter: Ayush Saxena
Assignee: Ayush Saxena
There are 3 RPC calls to fetch the same values :
{code:java}
public FsStatus getDiskStatus() throws IOException {
return new FsStatus(getStateByIndex(0),
getStateByIndex(1), getStateByIndex(2));
}
{code}
{{getStateByIndex()}} is called thrice, which is actually a {{getStats}} RPC to
namenode, The same could have been achieved by just one call
--
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
[jira] [Created] (HDFS-15632) AbstractContractDeleteTest should set recursive peremeter to true for recursive test cases.
Konstantin Shvachko created HDFS-15632:
--
Summary: AbstractContractDeleteTest should set recursive peremeter
to true for recursive test cases.
Key: HDFS-15632
URL: https://issues.apache.org/jira/browse/HDFS-15632
Project: Hadoop HDFS
Issue Type: Bug
Affects Versions: 2.10.0
Reporter: Konstantin Shvachko
{{AbstractContractDeleteTest.testDeleteNonexistentPathRecursive()}} should call
{{delete(path, true)}} rather than {{false}}
Also {{AbstractContractDeleteTest.testDeleteNonexistentPathNonRecursive()}} has
a wrong assert message. Should be {{"... attempting to non-recursively delete
..."}}
--
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
[jira] [Commented] (HDFS-15631) dfsadmin -report with RBF returns multiple capacity and used info
[ https://issues.apache.org/jira/browse/HDFS-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214197#comment-17214197 ] Ayush Saxena commented on HDFS-15631: - Are the datanodes shared amongst the cluster. I guess the API assumption is like, It doesn't expect the Datanodes to be shared. What is the proposed fix, you can't just explicitly divide by number of namespaces. calling getDatanodeReport and figuring out the stuff, is costly and if some Datanodes are shared and some aren't then that would be a mess. > dfsadmin -report with RBF returns multiple capacity and used info > - > > Key: HDFS-15631 > URL: https://issues.apache.org/jira/browse/HDFS-15631 > Project: Hadoop HDFS > Issue Type: Bug > Components: rbf >Affects Versions: 3.0.1 >Reporter: Shen Yinjie >Assignee: Shen Yinjie >Priority: Major > > When RBF enabled,we execute `hdfs dfsadmin -report` with RBF ns, the return > capacity is a multiple of the number of nss -- 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
[jira] [Commented] (HDFS-15572) RBF: Quota updating every 1 min once, if I setquota 50 on mount path, in a minute i am able to write the files morethan quota in mount path.
[
https://issues.apache.org/jira/browse/HDFS-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214037#comment-17214037
]
Takanobu Asanuma commented on HDFS-15572:
-
If reducing {{dfs.federation.router.cache.ttl}} or
{{dfs.federation.router.quota-cache.update.interval}}, router would update the
cache near real-time with the current implementation. But it will cause
frequency read operations to state store if it is too short.
> RBF: Quota updating every 1 min once, if I setquota 50 on mount path, in a
> minute i am able to write the files morethan quota in mount path.
> -
>
> Key: HDFS-15572
> URL: https://issues.apache.org/jira/browse/HDFS-15572
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: rbf
>Affects Versions: 3.1.1
>Reporter: Harshakiran Reddy
>Assignee: Hemanth Boyina
>Priority: Major
>
> IN Router State store quota updating every 1 min once only, if i set quota 50
> on mount path am able to write more that quota in the mount path here quota
> will not work out.
> {noformat}
> 1. Create a destinations dir in Namespaces
> 2. Create a mount path with multiple destinations
> 3. Setquota 50 on mount path
> 4. write a files morethan 50 + in the mount path in a minute
> {noformat}
> *Excepted Result:-*
> Here after setquota mount path should not allow morethan that at any cost.
--
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
[jira] [Commented] (HDFS-14383) Compute datanode load based on StoragePolicy
[
https://issues.apache.org/jira/browse/HDFS-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214001#comment-17214001
]
Ayush Saxena commented on HDFS-14383:
-
[~elgoiri] [~vinayakumarb] can you help give a check
> Compute datanode load based on StoragePolicy
>
>
> Key: HDFS-14383
> URL: https://issues.apache.org/jira/browse/HDFS-14383
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs, namenode
>Affects Versions: 2.7.3, 3.1.2
>Reporter: Karthik Palanisamy
>Priority: Major
> Attachments: HDFS-14383-01.patch
>
>
> Datanode load check logic needs to be changed because existing computation
> will not consider StoragePolicy.
> DatanodeManager#getInServiceXceiverAverage
> {code}
> public double getInServiceXceiverAverage() {
> double avgLoad = 0;
> final int nodes = getNumDatanodesInService();
> if (nodes != 0) {
> final int xceivers = heartbeatManager
> .getInServiceXceiverCount();
> avgLoad = (double)xceivers/nodes;
> }
> return avgLoad;
> }
> {code}
>
> For example: with 10 nodes (HOT), average 50 xceivers and 90 nodes (COLD)
> with average 10 xceivers the calculated threshold by the NN is 28 (((500 +
> 900)/100)*2), which means those 10 nodes (the whole HOT tier) becomes
> unavailable when the COLD tier nodes are barely in use. Turning this check
> off helps to mitigate this issue, however the
> dfs.namenode.replication.considerLoad helps to "balance" the load of the DNs,
> upon turning it off can lead to situations where specific DNs are
> "overloaded".
--
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
[jira] [Commented] (HDFS-14737) Writing data through the HDFS nfs3 service is very slow, and timeout occurs while mount directories on the nfs client
[ https://issues.apache.org/jira/browse/HDFS-14737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213995#comment-17213995 ] Danilo Saft commented on HDFS-14737: Same behavior (obviously) with rsync here. Interestingly, shortly after starting the cluster, the speed seemed ok. I'm getting about 2 MB/sec transfer speeds with a 3 datanode x 3 hdd and 10GBit/s setup. Disk space on the namenode continues to be filled up by logs. > Writing data through the HDFS nfs3 service is very slow, and timeout occurs > while mount directories on the nfs client > - > > Key: HDFS-14737 > URL: https://issues.apache.org/jira/browse/HDFS-14737 > Project: Hadoop HDFS > Issue Type: Improvement >Affects Versions: 2.7.2 >Reporter: liying >Assignee: liying >Priority: Major > > We know the NFS Gateway supports NFSv3 and allows HDFS to be mounted as part > of the client’s local file system. I start the portmap and nfs3server in the > hadoop node，and use the command （mount -t nfs -o vers=3,proto=tcp,nolock > nfs3serverIP:/ /hdfs） to mount. It works well。Then i ues this command to > mount on many client. And i used linux cp to copy files to the mounted > dir(/hdfs),found the speed was very slow . There is a lot of information in > the log as the follow: > 2019-08-14 15:36:28,347 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:37:03,093 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:37:03,850 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:37:14,780 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:37:14,928 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:37:28,410 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:38:09,310 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:38:10,069 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:38:14,856 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:38:14,957 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:38:28,475 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:39:14,923 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:39:14,987 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:39:15,541 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:39:16,287 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:39:28,530 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:40:15,015 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:40:15,024 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:40:15,028 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:40:21,757 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:40:22,508 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:40:28,583 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:41:15,063 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group supergroup. Use its string hashcode:-1710818332 > 2019-08-14 15:41:15,086 INFO org.apache.hadoop.security.ShellBasedIdMapping: > Can't map group
[jira] [Commented] (HDFS-14703) NameNode Fine-Grained Locking via Metadata Partitioning
[
https://issues.apache.org/jira/browse/HDFS-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213932#comment-17213932
]
Hemanth Boyina commented on HDFS-14703:
---
thanks [~shv] for your work
gone through the design doc , it was great , i have some questions
1) It is clear that on startup we decide the number of partitions based on
number of inodes in the image , but how do we decide range of RangeGsets on a
first time installation of cluster ?
2)
{quote}locking schema would be to allow Latch Lock for some operations combined
with the Global Lock for the other ones
{quote}
for operations like mkdir some times it is required to acquire locks of
different RangeGSets ,In the case of Recursive Mkdir we might need to acquire
locks of different RangeGSets , if some of the RangeGsets are locked for other
operations then the Range Map lock might have to wait for long time
3)
{quote}I attached two remaining patches 003 and 004 that should apply to
current trunk.
{quote}
are these patches should be applied on top of 003 and 004 in
[^001-partitioned-inodeMap-POC.tar.gz] ? looks some files were missing in
patches of [^002-partitioned-inodeMap-POC.tar.gz]
> NameNode Fine-Grained Locking via Metadata Partitioning
> ---
>
> Key: HDFS-14703
> URL: https://issues.apache.org/jira/browse/HDFS-14703
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: hdfs, namenode
>Reporter: Konstantin Shvachko
>Priority: Major
> Attachments: 001-partitioned-inodeMap-POC.tar.gz,
> 002-partitioned-inodeMap-POC.tar.gz, NameNode Fine-Grained Locking.pdf,
> NameNode Fine-Grained Locking.pdf
>
>
> We target to enable fine-grained locking by splitting the in-memory namespace
> into multiple partitions each having a separate lock. Intended to improve
> performance of NameNode write operations.
--
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
[jira] [Commented] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations.
[ https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213860#comment-17213860 ] Hui Fei commented on HDFS-15630: [~smarthan] Good catch ! Could you please give a github PR? That will be good. And UT failed, it's related. > RBF: Fix wrong client IP info in CallerContext when requests mount points > with multi-destinations. > -- > > Key: HDFS-15630 > URL: https://issues.apache.org/jira/browse/HDFS-15630 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: rbf >Reporter: Chengwei Wang >Assignee: Chengwei Wang >Priority: Major > Attachments: HDFS-15630.001.patch > > > There are two issues about client IP info in CallerContext when we try to > request mount points with multi-destinations. > # the clientIp would duplicate in CallerContext when > RouterRpcClient#invokeSequential. > # the clientIp would miss in CallerContext when > RouterRpcClient#invokeConcurrent. -- 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
[jira] [Commented] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations.
[
https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213805#comment-17213805
]
Hadoop QA commented on HDFS-15630:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Logfile || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
29s{color} | | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} || ||
| {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m
0s{color} | | {color:green} No case conflicting files found. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | | {color:green} The patch does not contain any @author tags.
{color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
1s{color} | | {color:green} The patch appears to include 1 new or modified
test files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 21m
48s{color} | | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | | {color:green} trunk passed with JDK
Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
31s{color} | | {color:green} trunk passed with JDK Private
Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{color} | | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
34s{color} | | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
16m 16s{color} | | {color:green} branch has no errors when building and
testing our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | | {color:green} trunk passed with JDK
Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | | {color:green} trunk passed with JDK Private
Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01 {color} |
| {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 1m
11s{color} | | {color:blue} Used deprecated FindBugs config; considering
switching to SpotBugs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
9s{color} | | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} || ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
30s{color} | | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | | {color:green} the patch passed with JDK
Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
26s{color} | | {color:green} the patch passed with JDK Private
Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
26s{color} | | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} blanks {color} | {color:green} 0m
0s{color} | | {color:green} The patch has no blanks issues. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m
29s{color} | | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
16m 27s{color} | | {color:green} patch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | | {color:green} the patch passed with JDK
Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{color} | | {color:green} the patch passed with JDK Private
Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01 {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
16s{color} | | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} || ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 8m 42s{color}
|
[jira] [Assigned] (HDFS-15631) dfsadmin -report with RBF returns multiple capacity and used info
[ https://issues.apache.org/jira/browse/HDFS-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shen Yinjie reassigned HDFS-15631: -- Assignee: Shen Yinjie > dfsadmin -report with RBF returns multiple capacity and used info > - > > Key: HDFS-15631 > URL: https://issues.apache.org/jira/browse/HDFS-15631 > Project: Hadoop HDFS > Issue Type: Bug > Components: rbf >Affects Versions: 3.0.1 >Reporter: Shen Yinjie >Assignee: Shen Yinjie >Priority: Major > > When RBF enabled,we execute `hdfs dfsadmin -report` with RBF ns, the return > capacity is a multiple of the number of nss -- 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
[jira] [Updated] (HDFS-15631) dfsadmin -report with RBF returns multiple capacity and used info
[ https://issues.apache.org/jira/browse/HDFS-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shen Yinjie updated HDFS-15631: --- Affects Version/s: 3.0.1 > dfsadmin -report with RBF returns multiple capacity and used info > - > > Key: HDFS-15631 > URL: https://issues.apache.org/jira/browse/HDFS-15631 > Project: Hadoop HDFS > Issue Type: Bug > Components: rbf >Affects Versions: 3.0.1 >Reporter: Shen Yinjie >Priority: Major > > When RBF enabled,we execute `hdfs dfsadmin -report` with RBF ns, the return > capacity is a multiple of the number of nss -- 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
[jira] [Updated] (HDFS-15631) dfsadmin -report with RBF returns multiple capacity and used info
[ https://issues.apache.org/jira/browse/HDFS-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shen Yinjie updated HDFS-15631: --- Component/s: rbf > dfsadmin -report with RBF returns multiple capacity and used info > - > > Key: HDFS-15631 > URL: https://issues.apache.org/jira/browse/HDFS-15631 > Project: Hadoop HDFS > Issue Type: Bug > Components: rbf >Reporter: Shen Yinjie >Priority: Major > > When RBF enabled,we execute `hdfs dfsadmin -report` with RBF ns, the return > capacity is a multiple of the number of nss -- 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
[jira] [Created] (HDFS-15631) dfsadmin -report with RBF returns multiple capacity and used info
Shen Yinjie created HDFS-15631: -- Summary: dfsadmin -report with RBF returns multiple capacity and used info Key: HDFS-15631 URL: https://issues.apache.org/jira/browse/HDFS-15631 Project: Hadoop HDFS Issue Type: Bug Reporter: Shen Yinjie When RBF enabled,we execute `hdfs dfsadmin -report` with RBF ns, the return capacity is a multiple of the number of nss -- 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
[jira] [Commented] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations.
[ https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213758#comment-17213758 ] Chengwei Wang commented on HDFS-15630: -- Submit patch v001. Hi [~ferhui], could you please help to review? > RBF: Fix wrong client IP info in CallerContext when requests mount points > with multi-destinations. > -- > > Key: HDFS-15630 > URL: https://issues.apache.org/jira/browse/HDFS-15630 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: rbf >Reporter: Chengwei Wang >Assignee: Chengwei Wang >Priority: Major > Attachments: HDFS-15630.001.patch > > > There are two issues about client IP info in CallerContext when we try to > request mount points with multi-destinations. > # the clientIp would duplicate in CallerContext when > RouterRpcClient#invokeSequential. > # the clientIp would miss in CallerContext when > RouterRpcClient#invokeConcurrent. -- 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
[jira] [Updated] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations.
[ https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengwei Wang updated HDFS-15630: - Attachment: HDFS-15630.001.patch Status: Patch Available (was: Open) > RBF: Fix wrong client IP info in CallerContext when requests mount points > with multi-destinations. > -- > > Key: HDFS-15630 > URL: https://issues.apache.org/jira/browse/HDFS-15630 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: rbf >Reporter: Chengwei Wang >Assignee: Chengwei Wang >Priority: Major > Attachments: HDFS-15630.001.patch > > > There are two issues about client IP info in CallerContext when we try to > request mount points with multi-destinations. > # the clientIp would duplicate in CallerContext when > RouterRpcClient#invokeSequential. > # the clientIp would miss in CallerContext when > RouterRpcClient#invokeConcurrent. -- 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
[jira] [Updated] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with
[ https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengwei Wang updated HDFS-15630: - Summary: RBF: Fix wrong client IP info in CallerContext when requests mount points with (was: RBF: fix wrong client IP info in CallerContext) > RBF: Fix wrong client IP info in CallerContext when requests mount points > with > --- > > Key: HDFS-15630 > URL: https://issues.apache.org/jira/browse/HDFS-15630 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: rbf >Reporter: Chengwei Wang >Assignee: Chengwei Wang >Priority: Major > > There are two issues about client IP info in CallerContext when we try to > request mount points with multi-destinations. > # the clientIp would duplicate in CallerContext when > RouterRpcClient#invokeSequential. > # the clientIp would miss in CallerContext when > RouterRpcClient#invokeConcurrent. -- 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
[jira] [Updated] (HDFS-15630) RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations.
[ https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengwei Wang updated HDFS-15630: - Summary: RBF: Fix wrong client IP info in CallerContext when requests mount points with multi-destinations. (was: RBF: Fix wrong client IP info in CallerContext when requests mount points with ) > RBF: Fix wrong client IP info in CallerContext when requests mount points > with multi-destinations. > -- > > Key: HDFS-15630 > URL: https://issues.apache.org/jira/browse/HDFS-15630 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: rbf >Reporter: Chengwei Wang >Assignee: Chengwei Wang >Priority: Major > > There are two issues about client IP info in CallerContext when we try to > request mount points with multi-destinations. > # the clientIp would duplicate in CallerContext when > RouterRpcClient#invokeSequential. > # the clientIp would miss in CallerContext when > RouterRpcClient#invokeConcurrent. -- 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
