[jira] [Updated] (HDFS-16497) EC: Add param comment for liveBusyBlockIndices with HDFS-14768
[ https://issues.apache.org/jira/browse/HDFS-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] caozhiqiang updated HDFS-16497: --- Status: Patch Available (was: Open) > EC: Add param comment for liveBusyBlockIndices with HDFS-14768 > -- > > Key: HDFS-16497 > URL: https://issues.apache.org/jira/browse/HDFS-16497 > Project: Hadoop HDFS > Issue Type: Improvement > Components: erasure-coding, namanode >Affects Versions: 3.4.0 >Reporter: caozhiqiang >Priority: Minor > Attachments: HDFS-16497.001.patch > > > In HDFS-14768, BlockManager::getDatanodeDescriptorFromStorage() function > should add param comment for liveBusyBlockIndices. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-16497) EC: Add param comment for liveBusyBlockIndices with HDFS-14768
[ https://issues.apache.org/jira/browse/HDFS-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] caozhiqiang updated HDFS-16497: --- Attachment: HDFS-16497.001.patch > EC: Add param comment for liveBusyBlockIndices with HDFS-14768 > -- > > Key: HDFS-16497 > URL: https://issues.apache.org/jira/browse/HDFS-16497 > Project: Hadoop HDFS > Issue Type: Improvement > Components: erasure-coding, namanode >Affects Versions: 3.4.0 >Reporter: caozhiqiang >Priority: Minor > Attachments: HDFS-16497.001.patch > > > In HDFS-14768, BlockManager::getDatanodeDescriptorFromStorage() function > should add param comment for liveBusyBlockIndices. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-16497) EC: Add param comment for liveBusyBlockIndices with HDFS-14768
[ https://issues.apache.org/jira/browse/HDFS-16497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] caozhiqiang updated HDFS-16497: --- External issue ID: (was: HDFS-14768) External issue URL: (was: https://issues.apache.org/jira/browse/HDFS-14768) > EC: Add param comment for liveBusyBlockIndices with HDFS-14768 > -- > > Key: HDFS-16497 > URL: https://issues.apache.org/jira/browse/HDFS-16497 > Project: Hadoop HDFS > Issue Type: Improvement > Components: erasure-coding, namanode >Affects Versions: 3.4.0 >Reporter: caozhiqiang >Priority: Minor > > In HDFS-14768, BlockManager::getDatanodeDescriptorFromStorage() function > should add param comment for liveBusyBlockIndices. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Created] (HDFS-16497) EC: Add param comment for liveBusyBlockIndices with HDFS-14768
caozhiqiang created HDFS-16497: -- Summary: EC: Add param comment for liveBusyBlockIndices with HDFS-14768 Key: HDFS-16497 URL: https://issues.apache.org/jira/browse/HDFS-16497 Project: Hadoop HDFS Issue Type: Improvement Components: erasure-coding, namanode Affects Versions: 3.4.0 Reporter: caozhiqiang In HDFS-14768, BlockManager::getDatanodeDescriptorFromStorage() function should add param comment for liveBusyBlockIndices. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-16495) RBF should prepend the client ip rather than append it.
[
https://issues.apache.org/jira/browse/HDFS-16495?focusedWorklogId=738465&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-738465
]
ASF GitHub Bot logged work on HDFS-16495:
-
Author: ASF GitHub Bot
Created on: 09/Mar/22 00:32
Start Date: 09/Mar/22 00:32
Worklog Time Spent: 10m
Work Description: hadoop-yetus commented on pull request #4054:
URL: https://github.com/apache/hadoop/pull/4054#issuecomment-1062430216
:broken_heart: **-1 overall**
| Vote | Subsystem | Runtime | Logfile | Comment |
|::|--:|:|::|:---:|
| +0 :ok: | reexec | 0m 50s | | Docker mode activated. |
_ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | | No case conflicting files
found. |
| +0 :ok: | codespell | 0m 0s | | codespell was not available. |
| +1 :green_heart: | @author | 0m 0s | | The patch does not contain
any @author tags. |
| +1 :green_heart: | test4tests | 0m 0s | | The patch appears to
include 2 new or modified test files. |
_ trunk Compile Tests _ |
| +1 :green_heart: | mvninstall | 36m 18s | | trunk passed |
| +1 :green_heart: | compile | 0m 40s | | trunk passed with JDK
Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04 |
| +1 :green_heart: | compile | 0m 35s | | trunk passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| +1 :green_heart: | checkstyle | 0m 23s | | trunk passed |
| +1 :green_heart: | mvnsite | 0m 41s | | trunk passed |
| +1 :green_heart: | javadoc | 0m 41s | | trunk passed with JDK
Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04 |
| +1 :green_heart: | javadoc | 0m 53s | | trunk passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| +1 :green_heart: | spotbugs | 1m 19s | | trunk passed |
| +1 :green_heart: | shadedclient | 24m 8s | | branch has no errors
when building and testing our client artifacts. |
_ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 0m 32s | | the patch passed |
| +1 :green_heart: | compile | 0m 36s | | the patch passed with JDK
Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04 |
| +1 :green_heart: | javac | 0m 36s | | the patch passed |
| +1 :green_heart: | compile | 0m 30s | | the patch passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| +1 :green_heart: | javac | 0m 30s | | the patch passed |
| +1 :green_heart: | blanks | 0m 0s | | The patch has no blanks
issues. |
| -0 :warning: | checkstyle | 0m 15s |
[/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs-rbf.txt](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4054/1/artifact/out/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs-rbf.txt)
| hadoop-hdfs-project/hadoop-hdfs-rbf: The patch generated 2 new + 0
unchanged - 0 fixed = 2 total (was 0) |
| +1 :green_heart: | mvnsite | 0m 32s | | the patch passed |
| +1 :green_heart: | javadoc | 0m 31s | | the patch passed with JDK
Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04 |
| +1 :green_heart: | javadoc | 0m 50s | | the patch passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| -1 :x: | spotbugs | 1m 26s |
[/new-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf.html](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4054/1/artifact/out/new-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf.html)
| hadoop-hdfs-project/hadoop-hdfs-rbf generated 1 new + 0 unchanged - 0 fixed
= 1 total (was 0) |
| +1 :green_heart: | shadedclient | 23m 27s | | patch has no errors
when building and testing our client artifacts. |
_ Other Tests _ |
| -1 :x: | unit | 50m 4s |
[/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4054/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt)
| hadoop-hdfs-rbf in the patch passed. |
| +1 :green_heart: | asflicense | 0m 43s | | The patch does not
generate ASF License warnings. |
| | | 147m 4s | | |
| Reason | Tests |
|---:|:--|
| SpotBugs | module:hadoop-hdfs-project/hadoop-hdfs-rbf |
| | Possible null pointer dereference of null in
org.apache.hadoop.hdfs.server.federation.router.RouterRpcClient.addClientIpToCallerContext()
Dereferenced at RouterRpcClient.java:null in
org.apache.hadoop.hdfs.server.federation.router.RouterRpcClient.addClientIpToCallerContext()
Dereferenced at RouterRpcClient.java:[line 604] |
| Failed junit tests |
hadoop.fs.contract.router.TestRouterHDFSContractCreate |
| | hadoop.fs.contract.router.web.TestRouterWebHDFSContractSeek |
| | hadoop.hdfs.server.federation.metrics.TestNameserviceRPCMetrics |
| | hadoop.fs.contract.router.Tes
[jira] [Work logged] (HDFS-16495) RBF should prepend the client ip rather than append it.
[ https://issues.apache.org/jira/browse/HDFS-16495?focusedWorklogId=738401&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-738401 ] ASF GitHub Bot logged work on HDFS-16495: - Author: ASF GitHub Bot Created on: 08/Mar/22 22:04 Start Date: 08/Mar/22 22:04 Worklog Time Spent: 10m Work Description: omalley opened a new pull request #4054: URL: https://github.com/apache/hadoop/pull/4054 ### Description of PR Makes RBF prepends the client ip & port to the caller context and removes previous values. This avoids a couple problems: * User can't fake their network address to the NN. * It is less likely to have false positives (accidental conflicts), since the critical information that is under system control comes first. ### How was this patch tested? The relevant unit tests were fixed and run. -- 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. To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 738401) Remaining Estimate: 0h Time Spent: 10m > RBF should prepend the client ip rather than append it. > --- > > Key: HDFS-16495 > URL: https://issues.apache.org/jira/browse/HDFS-16495 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Owen O'Malley >Assignee: Owen O'Malley >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently the Routers append the client ip to the caller context if and only > if it is not already set. This would allow the user to fake their ip by > setting the caller context. Much better is to prepend it unconditionally. > The NN must be able to trust the client ip from the caller context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-16495) RBF should prepend the client ip rather than append it.
[ https://issues.apache.org/jira/browse/HDFS-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HDFS-16495: -- Labels: pull-request-available (was: ) > RBF should prepend the client ip rather than append it. > --- > > Key: HDFS-16495 > URL: https://issues.apache.org/jira/browse/HDFS-16495 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Owen O'Malley >Assignee: Owen O'Malley >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently the Routers append the client ip to the caller context if and only > if it is not already set. This would allow the user to fake their ip by > setting the caller context. Much better is to prepend it unconditionally. > The NN must be able to trust the client ip from the caller context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-16214) Asynchronously collect blocks and update quota when deleting
[
https://issues.apache.org/jira/browse/HDFS-16214?focusedWorklogId=738192&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-738192
]
ASF GitHub Bot logged work on HDFS-16214:
-
Author: ASF GitHub Bot
Created on: 08/Mar/22 15:59
Start Date: 08/Mar/22 15:59
Worklog Time Spent: 10m
Work Description: hadoop-yetus commented on pull request #3885:
URL: https://github.com/apache/hadoop/pull/3885#issuecomment-1061934720
:broken_heart: **-1 overall**
| Vote | Subsystem | Runtime | Logfile | Comment |
|::|--:|:|::|:---:|
| +0 :ok: | reexec | 1m 4s | | Docker mode activated. |
_ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | | No case conflicting files
found. |
| +0 :ok: | codespell | 0m 1s | | codespell was not available. |
| +1 :green_heart: | @author | 0m 0s | | The patch does not contain
any @author tags. |
| +1 :green_heart: | test4tests | 0m 0s | | The patch appears to
include 26 new or modified test files. |
_ trunk Compile Tests _ |
| +1 :green_heart: | mvninstall | 33m 1s | | trunk passed |
| +1 :green_heart: | compile | 1m 27s | | trunk passed with JDK
Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 |
| +1 :green_heart: | compile | 1m 24s | | trunk passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| +1 :green_heart: | checkstyle | 1m 9s | | trunk passed |
| +1 :green_heart: | mvnsite | 1m 30s | | trunk passed |
| +1 :green_heart: | javadoc | 1m 1s | | trunk passed with JDK
Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 |
| +1 :green_heart: | javadoc | 1m 32s | | trunk passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| +1 :green_heart: | spotbugs | 3m 15s | | trunk passed |
| +1 :green_heart: | shadedclient | 22m 33s | | branch has no errors
when building and testing our client artifacts. |
_ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 1m 19s | | the patch passed |
| +1 :green_heart: | compile | 1m 19s | | the patch passed with JDK
Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 |
| +1 :green_heart: | javac | 1m 19s | | the patch passed |
| +1 :green_heart: | compile | 1m 10s | | the patch passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| +1 :green_heart: | javac | 1m 10s | | the patch passed |
| +1 :green_heart: | blanks | 0m 0s | | The patch has no blanks
issues. |
| -0 :warning: | checkstyle | 0m 59s |
[/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3885/3/artifact/out/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt)
| hadoop-hdfs-project/hadoop-hdfs: The patch generated 18 new + 1046
unchanged - 1 fixed = 1064 total (was 1047) |
| +1 :green_heart: | mvnsite | 1m 17s | | the patch passed |
| +1 :green_heart: | javadoc | 0m 52s | | the patch passed with JDK
Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 |
| +1 :green_heart: | javadoc | 1m 22s | | the patch passed with JDK
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| +1 :green_heart: | spotbugs | 3m 19s | | the patch passed |
| +1 :green_heart: | shadedclient | 22m 10s | | patch has no errors
when building and testing our client artifacts. |
_ Other Tests _ |
| -1 :x: | unit | 365m 59s |
[/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3885/3/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt)
| hadoop-hdfs in the patch passed. |
| +1 :green_heart: | asflicense | 0m 47s | | The patch does not
generate ASF License warnings. |
| | | 466m 33s | | |
| Reason | Tests |
|---:|:--|
| Failed junit tests | hadoop.hdfs.TestLease |
| Subsystem | Report/Notes |
|--:|:-|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base:
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3885/3/artifact/out/Dockerfile
|
| GITHUB PR | https://github.com/apache/hadoop/pull/3885 |
| Optional Tests | dupname asflicense compile javac javadoc mvninstall
mvnsite unit shadedclient spotbugs checkstyle codespell |
| uname | Linux 354fe4a9a7c0 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9
23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/bin/hadoop.sh |
| git revision | trunk / 24dd0b4355be75b1642000a84971b468e34d6e1a |
| Default Java | Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 |
| Multi-JDK versions |
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04
/usr/lib/jvm/java-8-openjdk-amd6
[jira] [Resolved] (HDFS-16496) Snapshot diff on snapshotable directory fails with not snapshottable error
[
https://issues.apache.org/jira/browse/HDFS-16496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen O'Donnell resolved HDFS-16496.
--
Fix Version/s: 3.4.0
Resolution: Fixed
> Snapshot diff on snapshotable directory fails with not snapshottable error
> --
>
> Key: HDFS-16496
> URL: https://issues.apache.org/jira/browse/HDFS-16496
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namanode
>Affects Versions: 3.4.0
>Reporter: Stephen O'Donnell
>Assignee: Stephen O'Donnell
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.4.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Running a snapshot diff against some snapshotable folders gives an error:
> {code}
> org.apache.hadoop.hdfs.protocol.SnapshotException: Directory is neither
> snapshottable nor under a snap root!
> at
> org.apache.hadoop.hdfs.server.namenode.snapshot.SnapshotManager.checkAndGetSnapshottableAncestorDir(SnapshotManager.java:395)
> at
> org.apache.hadoop.hdfs.server.namenode.snapshot.SnapshotManager.diff(SnapshotManager.java:744)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirSnapshotOp.getSnapshotDiffReportListing(FSDirSnapshotOp.java:200)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getSnapshotDiffReportListing(FSNamesystem.java:6983)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getSnapshotDiffReportListing(NameNodeRpcServer.java:1977)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.getSnapshotDiffReportListing(ClientNamenodeProtocolServerSideTranslatorPB.java:1387)
> at
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:533)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1070)
> at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:989)
> at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:917)
> 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:1898)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2894)
> {code}
> This is caused by HDFS-15483 (in order snapshot delete), and the issue is in
> the following method in SnapshotManager:
> {code}
> public INodeDirectory getSnapshottableAncestorDir(final INodesInPath iip)
> throws IOException {
> final String path = iip.getPath();
> final INode inode = iip.getLastINode();
> final INodeDirectory dir;
> if (inode instanceof INodeDirectory) { // THIS SHOULD BE TRUE - change to
> inode.isDirectory()
> dir = INodeDirectory.valueOf(inode, path);
> } else {
> dir = INodeDirectory.valueOf(iip.getINode(-2), iip.getParentPath());
> }
> if (dir.isSnapshottable()) {
> return dir;
> }
> for (INodeDirectory snapRoot : this.snapshottables.values()) {
> if (dir.isAncestorDirectory(snapRoot)) {
> return snapRoot;
> }
> }
> return null;
> }
> {code}
> After adding some debug, I found the directory which is the snapshot root is
> not an instance of INodeDirectory, but instead is an
> "INodeReference$DstReference". I think the directory becomes an instance of
> this class, if the directory is renamed and one of its children has been
> moved out of another snapshot.
> The fix is simple - just check `inode.isDirectory()` instead.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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-16496) Snapshot diff on snapshotable directory fails with not snapshottable error
[
https://issues.apache.org/jira/browse/HDFS-16496?focusedWorklogId=738068&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-738068
]
ASF GitHub Bot logged work on HDFS-16496:
-
Author: ASF GitHub Bot
Created on: 08/Mar/22 11:07
Start Date: 08/Mar/22 11:07
Worklog Time Spent: 10m
Work Description: sodonnel merged pull request #4051:
URL: https://github.com/apache/hadoop/pull/4051
--
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.
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 738068)
Time Spent: 50m (was: 40m)
> Snapshot diff on snapshotable directory fails with not snapshottable error
> --
>
> Key: HDFS-16496
> URL: https://issues.apache.org/jira/browse/HDFS-16496
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namanode
>Affects Versions: 3.4.0
>Reporter: Stephen O'Donnell
>Assignee: Stephen O'Donnell
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Running a snapshot diff against some snapshotable folders gives an error:
> {code}
> org.apache.hadoop.hdfs.protocol.SnapshotException: Directory is neither
> snapshottable nor under a snap root!
> at
> org.apache.hadoop.hdfs.server.namenode.snapshot.SnapshotManager.checkAndGetSnapshottableAncestorDir(SnapshotManager.java:395)
> at
> org.apache.hadoop.hdfs.server.namenode.snapshot.SnapshotManager.diff(SnapshotManager.java:744)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirSnapshotOp.getSnapshotDiffReportListing(FSDirSnapshotOp.java:200)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getSnapshotDiffReportListing(FSNamesystem.java:6983)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getSnapshotDiffReportListing(NameNodeRpcServer.java:1977)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.getSnapshotDiffReportListing(ClientNamenodeProtocolServerSideTranslatorPB.java:1387)
> at
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:533)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1070)
> at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:989)
> at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:917)
> 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:1898)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2894)
> {code}
> This is caused by HDFS-15483 (in order snapshot delete), and the issue is in
> the following method in SnapshotManager:
> {code}
> public INodeDirectory getSnapshottableAncestorDir(final INodesInPath iip)
> throws IOException {
> final String path = iip.getPath();
> final INode inode = iip.getLastINode();
> final INodeDirectory dir;
> if (inode instanceof INodeDirectory) { // THIS SHOULD BE TRUE - change to
> inode.isDirectory()
> dir = INodeDirectory.valueOf(inode, path);
> } else {
> dir = INodeDirectory.valueOf(iip.getINode(-2), iip.getParentPath());
> }
> if (dir.isSnapshottable()) {
> return dir;
> }
> for (INodeDirectory snapRoot : this.snapshottables.values()) {
> if (dir.isAncestorDirectory(snapRoot)) {
> return snapRoot;
> }
> }
> return null;
> }
> {code}
> After adding some debug, I found the directory which is the snapshot root is
> not an instance of INodeDirectory, but instead is an
> "INodeReference$DstReference". I think the directory becomes an instance of
> this class, if the directory is renamed and one of its children has been
> moved out of another snapshot.
> The fix is simple - just check `inode.isDirectory()` instead.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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-16477) [SPS]: Add metric PendingSPSPaths for getting the number of paths to be processed by SPS
[ https://issues.apache.org/jira/browse/HDFS-16477?focusedWorklogId=738031&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-738031 ] ASF GitHub Bot logged work on HDFS-16477: - Author: ASF GitHub Bot Created on: 08/Mar/22 08:57 Start Date: 08/Mar/22 08:57 Worklog Time Spent: 10m Work Description: tomscut commented on pull request #4009: URL: https://github.com/apache/hadoop/pull/4009#issuecomment-1061548454 Hi @tasanuma @virajjasani , could you please also take a look. Thanks. -- 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. To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 738031) Time Spent: 2h 20m (was: 2h 10m) > [SPS]: Add metric PendingSPSPaths for getting the number of paths to be > processed by SPS > > > Key: HDFS-16477 > URL: https://issues.apache.org/jira/browse/HDFS-16477 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: tomscut >Assignee: tomscut >Priority: Major > Labels: pull-request-available > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently we have no idea how many paths are waiting to be processed when > using the SPS feature. We should add metric PendingSPSPaths for getting the > number of paths to be processed by SPS in NameNode. -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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-16214) Asynchronously collect blocks and update quota when deleting
[
https://issues.apache.org/jira/browse/HDFS-16214?focusedWorklogId=738022&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-738022
]
ASF GitHub Bot logged work on HDFS-16214:
-
Author: ASF GitHub Bot
Created on: 08/Mar/22 08:40
Start Date: 08/Mar/22 08:40
Worklog Time Spent: 10m
Work Description: zhuxiangyi commented on a change in pull request #3885:
URL: https://github.com/apache/hadoop/pull/3885#discussion_r821437088
##
File path:
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirDeleteOp.java
##
@@ -112,10 +110,76 @@ static BlocksMapUpdateInfo delete(
}
DFSUtil.checkProtectedDescendants(fsd, iip);
}
-
return deleteInternal(fsn, iip, logRetryCache);
}
+ /**
+ * Clean files and update Quota after collecting blcoks.
+ *
+ * When it takes a long time to collect blocks when encountering
+ * a large directory, the collection block here adopts no lock。
+ *
+ *
+ * @param fsn namespace
+ * @param iip inodes of a path to be deleted
+ * @return blocks collected from the deleted path
+ * @throws IOException
+ */
+ static BlocksMapUpdateInfo clearFileAndUpdateQuota(FSNamesystem fsn,
INodesInPath iip)
+ throws QuotaExceededException {
+long filesRemoved = -1;
+if (iip == null) {
+ return null;
+}
+// collect blocks no lock
+INode.ReclaimContext context = FSDirDeleteOp.collectBlocks(fsn, iip);
+filesRemoved = context.quotaDelta().getNsDelta();
+if (filesRemoved < 0) {
+ return context.collectedBlocks;
+}
+// update Quota and clear UCFiles lease
+fsn.writeLock();
+try {
+ FSDirectory fsd = fsn.getFSDirectory();
+ fsd.removeInodeFromDeletingInodes(iip.getLastINode());
+ fsn.removeLeasesAndINodes(context.removedUCFiles,
+ context.removedINodes, true);
+ fsd.updateCount(iip, context.quotaDelta(), false);
+ incrDeletedFileCount(filesRemoved);
+
fsd.updateReplicationFactor(context.collectedBlocks().toUpdateReplicationInfo());
+} finally {
+ fsn.writeUnlock();
+}
+return context.collectedBlocks;
+ }
+
+ /**
+ * Collect blocks from the deleted path.
+ *
+ * @param fsn namespace
+ * @param iip inodes of a path to be deleted
+ * @return blocks collected from the deleted path
+ */
+ static ReclaimContext collectBlocks(FSNamesystem fsn, INodesInPath iip) {
Review comment:
There may be problems in deleting the snapshot file without locking. I
reconstructed the logic of this part, put the deletion of the snapshot file
into the lock, and use asynchronous collection block and update quota.
--
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.
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 738022)
Time Spent: 50m (was: 40m)
> Asynchronously collect blocks and update quota when deleting
>
>
> Key: HDFS-16214
> URL: https://issues.apache.org/jira/browse/HDFS-16214
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
>Affects Versions: 3.4.0
>Reporter: Xiangyi Zhu
>Assignee: Xiangyi Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The time-consuming deletion is mainly reflected in three logics , collecting
> blocks, deleting Inode from InodeMap, and deleting blocks. The current
> deletion is divided into two major steps. Step 1 acquires the lock, collects
> the block and inode, deletes the inode, and releases the lock. Step 2 Acquire
> the lock and delete the block to release the lock.
> Phase 2 is currently deleting blocks in batches, which can control the lock
> holding time. Here we can also delete blocks asynchronously.
> Now step 1 still has the problem of holding the lock for a long time.
> For stage 1, we can make the collection block not hold the lock. The process
> is as follows, step 1 obtains the lock, parent.removeChild, writes to
> editLog, releases the lock. Step 2 no lock, collects the block. Step 3
> acquire lock, update quota, release lease, release lock. Step 4 acquire lock,
> delete Inode from InodeMap, release lock. Step 5 acquire lock, delete block
> to release lock.
> There may be some problems following the above process:
> 1. When the /a/b/c file is writing, then delete the /a/b directory. If the
> deletion is performed to the collecting block stage, the client writes
>
[jira] [Updated] (HDFS-16214) Asynchronously collect blocks and update quota when deleting
[
https://issues.apache.org/jira/browse/HDFS-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiangyi Zhu updated HDFS-16214:
---
Summary: Asynchronously collect blocks and update quota when deleting
(was: Lock optimization for large deleteing, no locks on the collection block)
> Asynchronously collect blocks and update quota when deleting
>
>
> Key: HDFS-16214
> URL: https://issues.apache.org/jira/browse/HDFS-16214
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
>Affects Versions: 3.4.0
>Reporter: Xiangyi Zhu
>Assignee: Xiangyi Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The time-consuming deletion is mainly reflected in three logics , collecting
> blocks, deleting Inode from InodeMap, and deleting blocks. The current
> deletion is divided into two major steps. Step 1 acquires the lock, collects
> the block and inode, deletes the inode, and releases the lock. Step 2 Acquire
> the lock and delete the block to release the lock.
> Phase 2 is currently deleting blocks in batches, which can control the lock
> holding time. Here we can also delete blocks asynchronously.
> Now step 1 still has the problem of holding the lock for a long time.
> For stage 1, we can make the collection block not hold the lock. The process
> is as follows, step 1 obtains the lock, parent.removeChild, writes to
> editLog, releases the lock. Step 2 no lock, collects the block. Step 3
> acquire lock, update quota, release lease, release lock. Step 4 acquire lock,
> delete Inode from InodeMap, release lock. Step 5 acquire lock, delete block
> to release lock.
> There may be some problems following the above process:
> 1. When the /a/b/c file is writing, then delete the /a/b directory. If the
> deletion is performed to the collecting block stage, the client writes
> complete or addBlock to the /a/b/c file at this time. This step is not locked
> and delete /a/b and editLog has been written successfully. In this case, the
> order of editLog is delete /a/c and complete /a/b/c. In this case, the
> standby node playback editLog /a/b/c file has been deleted, and then go to
> complete /a/b/c file will be abnormal.
> *The process is as follows:*
> *write editLog order: delete /a/b/c -> delete /a/b -> complete /a/b/c*
> *replay editLog order:* *delete /a/b/c ->* *delete /a/b ->* *complete /a/b/c
> {color:#ff}(not found){color}*
> 2. If a delete operation is executed to the stage of collecting block, then
> the administrator executes saveNameSpace, and then restarts Namenode. This
> situation may cause the Inode that has been deleted from the parent childList
> to remain in the InodeMap.
> To solve the above problem, in step 1, add the inode being deleted to the
> Set. When there is a file WriteFileOp (logAllocateBlockId/logCloseFile
> EditLog), check whether there is this file and one of its parent Inodes in
> the Set, and throw it if there is. An exception FileNotFoundException
> occurred.
> In addition, the execution of saveNamespace needs to wait for all iNodes in
> Set to be removed before execution.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
