[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517389#comment-15517389 ] Hudson commented on HDFS-10843: --- SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #10480 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/10480/]) HDFS-10843. Update space quota when a UC block is completed rather than (shv: rev a5bb88c8e0fd4bd19b6d377fecbe1d2d441514f6) * (edit) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirAttrOp.java * (edit) hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestDiskspaceQuotaUpdate.java * (edit) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java * (edit) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirectory.java * (edit) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/Namesystem.java * (edit) hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Fix For: 2.7.4 > > Attachments: HDFS-10843-branch-2.005.patch, > HDFS-10843-branch-2.7.005.patch, HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch, > HDFS-10843.005.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15516987#comment-15516987 ] Erik Krogen commented on HDFS-10843: findbugs - all unrelated to this patch whitespace - all unrelated to this patch asflicense - all unrelated to this patch unit test failures: - hadoop-common-project: all are certainly unrelated; only change was to add one new static method to help with capturing logs since the current LogCapturer refused to handle {{NameNode.LOG}} despite being compatible. - hadoop-hdfs-project: Some of the Jenkins failures were due to OOM. All of them pass locally except for TestDataNodeHotSwapVolumes which intermittently fails, but it did so before this patch as well. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843-branch-2.005.patch, > HDFS-10843-branch-2.7.005.patch, HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch, > HDFS-10843.005.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15515531#comment-15515531 ] Hadoop QA commented on HDFS-10843: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 2 new or modified test files. {color} | | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 30s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 42s{color} | {color:green} branch-2.7 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 56s{color} | {color:green} branch-2.7 passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 17s{color} | {color:green} branch-2.7 passed with JDK v1.7.0_111 {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 28s{color} | {color:green} branch-2.7 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 45s{color} | {color:green} branch-2.7 passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 28s{color} | {color:green} branch-2.7 passed {color} | | {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 34s{color} | {color:red} hadoop-common-project/hadoop-common in branch-2.7 has 3 extant Findbugs warnings. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 45s{color} | {color:green} branch-2.7 passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 38s{color} | {color:green} branch-2.7 passed with JDK v1.7.0_111 {color} | | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 32s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 29s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m 29s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 16s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m 16s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 1m 24s{color} | {color:orange} root: The patch generated 3 new + 653 unchanged - 3 fixed = 656 total (was 656) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 46s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 29s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s{color} | {color:red} The patch has 4750 line(s) that end in whitespace. Use git apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply {color} | | {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 2m 27s{color} | {color:red} The patch 166 line(s) with tabs. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 0s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 42s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 35s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 21m 34s{color} | {color:red} hadoop-common in the patch failed with JDK v1.7.0_111. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 63m 22s{color} | {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_111. {color} | | {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 26s{color} | {color:red} The patch generated 4 ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}219m 19s{color} | {color:black} {col
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15514907#comment-15514907 ] Hadoop QA commented on HDFS-10843: -- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m 16s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 53s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 33s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 56s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 15s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 4s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 40s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 49s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 44s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 31s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs: The patch generated 0 new + 397 unchanged - 8 fixed = 397 total (was 405) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 54s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 12s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 15s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 42s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 48m 4s{color} | {color:green} hadoop-hdfs in the patch passed with JDK v1.7.0_111. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 21s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}138m 7s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | JDK v1.8.0_101 Failed junit tests | hadoop.hdfs.server.namenode.TestDecommissioningStatus | | | hadoop.hdfs.TestEncryptionZones | \\ \\ || Subsystem || Report/Notes || | Docker | Image:yetus/hadoop:b59b8b7 | | JIRA Issue | HDFS-10843 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12829938/HDFS-10843-branch-2.005.patch | | Optional Tests | asflicense compile javac javadoc mvninstall mvnsite unit findbugs checkstyle | | uname | Linux 946942dfaae1 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/hadoop/patchprocess/prec
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15514587#comment-15514587 ] Konstantin Shvachko commented on HDFS-10843: [~xkrogen] could you please attach a patch for branch-2.7. I managed to merge this to branch-2 and branch-2.8. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch, > HDFS-10843.005.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513939#comment-15513939 ] Konstantin Shvachko commented on HDFS-10843: +1. Will commit in a bit. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch, > HDFS-10843.005.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504800#comment-15504800 ] Erik Krogen commented on HDFS-10843: Test failure does not appear to be related and runs successfully locally. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch, > HDFS-10843.005.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504783#comment-15504783 ] Hadoop QA commented on HDFS-10843: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m 44s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m 19s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 32s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 54s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 14s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 51s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 27s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs: The patch generated 0 new + 364 unchanged - 7 fixed = 364 total (was 371) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 9s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 51s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 63m 6s{color} | {color:red} hadoop-hdfs in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 18s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 97m 53s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hdfs.server.datanode.TestDataNodeRollingUpgrade | \\ \\ || Subsystem || Report/Notes || | Docker | Image:yetus/hadoop:9560f25 | | JIRA Issue | HDFS-10843 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12829264/HDFS-10843.005.patch | | Optional Tests | asflicense compile javac javadoc mvninstall mvnsite unit findbugs checkstyle | | uname | Linux 38a1a67214c7 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh | | git revision | trunk / c54f6ef | | Default Java | 1.8.0_101 | | findbugs | v3.0.0 | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/16796/artifact/patchprocess/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/16796/testReport/ | | modules | C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs | | Console output | https://builds.apache.org/job/PreCommit-HDFS-Build/16796/console | | Powered by | Apache Yetus 0.4.0-SNAPSHOT http://yetus.apache.org | This message was automatically generated. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Ha
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491623#comment-15491623 ] Erik Krogen commented on HDFS-10843: But you shouldn't be calling {{BlockInfo.convertToCompleteBlock}} anyway, you should be calling {{BlockManager.completeBlock}}. {{completeBlock}} has other operations, e.g. checking for minimum replication and updating the block totals, that must be completed every time a block is completed. A separate {{BlockManager.convertToCompleteBlock}} method may imply that {{convertToCompleteBlock}} is an acceptable way to complete a block (bypassing the other code in {{completeBlock}}) when really the only acceptable way is through {{BlockManager.completeBlock}}. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491607#comment-15491607 ] Konstantin Shvachko commented on HDFS-10843: I am just trying to make the coupling of completing a block and changing space consumed more explicit. With current patch one should _remember_ to {{updateSpaceForCompleteBlock(}} whenever the block is completed {{BlockInfo.convertToCompleteBlock()}}. If we wrap them together you don't need to remember, just call the new method. Minimizing chances to make a mistake for others. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491505#comment-15491505 ] Erik Krogen commented on HDFS-10843: What advantage is there to wrapping those two specific calls in a new method {{BlockManager.convertToCompleteBlock}} rather than just calling both from within {{BlockManager.completeBlock}} as in patch v003?? I think the distinction between the two methods would be a little confusing. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491124#comment-15491124 ] Konstantin Shvachko commented on HDFS-10843: You are right, the control flow looks awkward once you see it done. Let's leave {{BlockInfo.convertToCompleteBlock()}} as is and instead wrap the calls to these 2 methods in a new function {{BlockManager.convertToCompleteBlock(curBlock, iip)}} adding all the comments about updating space while completing there. Would that look better? > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15488923#comment-15488923 ] Hadoop QA commented on HDFS-10843: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 47s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 30s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 51s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 12s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 43s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 28s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs: The patch generated 0 new + 369 unchanged - 7 fixed = 369 total (was 376) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 48s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 9s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 50s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 85m 15s{color} | {color:red} hadoop-hdfs in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 22s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}104m 29s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hdfs.server.datanode.TestDataNodeVolumeFailure | \\ \\ || Subsystem || Report/Notes || | Docker | Image:yetus/hadoop:9560f25 | | JIRA Issue | HDFS-10843 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12828348/HDFS-10843.004.patch | | Optional Tests | asflicense compile javac javadoc mvninstall mvnsite unit findbugs checkstyle | | uname | Linux e1e5eaeedc96 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh | | git revision | trunk / 86c9862 | | Default Java | 1.8.0_101 | | findbugs | v3.0.0 | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/16736/artifact/patchprocess/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/16736/testReport/ | | modules | C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs | | Console output | https://builds.apache.org/job/PreCommit-HDFS-Build/16736/console | | Powered by | Apache Yetus 0.4.0-SNAPSHOT http://yetus.apache.org | This message was automatically generated. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Pro
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15488666#comment-15488666 ] Erik Krogen commented on HDFS-10843: Thanks for the comments. I am a little unsure about point 3. It is definitely advantageous to force the space to be updated whenever a block is completed by placing the method call inside of {{convertToCompleteBlock}}. I am a little wary that it creates an awkward control flow given that most {{BlockInfo}} operations deal only with the block itself. I included this change in the v004 patch but want to call it out for a second look just to be sure that it is the right move. v004 patch also addresses comments 1, 2, 4, 5. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch, HDFS-10843.004.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15488354#comment-15488354 ] Konstantin Shvachko commented on HDFS-10843: Nice, Erik. Minor comments on the latest patch # {{updateSpaceForCompleteBlock()}}. Traditionally we say "complete" block not "completed". As in {{convertToCompleteBlock()}} or {{getCompleteBlocksTotal()}}. # Organize 2 new imports in FSDirectory. # May be it would make sense to move {{updateSpaceForCompleteBlock()}} further inside {{convertToCompleteBlock()}}, so that nobody could complete a block without updating spaces. # great refactoring of TestDiskspaceQuotaUpdate. I would only suggest to rename #* {{getDirectory()}} to {{getParent()}} #* {{getFSDir()}} to {{getFSDirectory()}} # Also according to checkstyle warnings constant {{baseDir}} should be all-capital {{BASE_DIR}}, and some misplaced white spaces. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch, > HDFS-10843.002.patch, HDFS-10843.003.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15485915#comment-15485915 ] Hadoop QA commented on HDFS-10843: -- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 41s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 29s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 51s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 12s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 42s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 27s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs: The patch generated 2 new + 364 unchanged - 7 fixed = 366 total (was 371) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 10s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 58m 32s{color} | {color:green} hadoop-hdfs in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 18s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 77m 17s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Image:yetus/hadoop:9560f25 | | JIRA Issue | HDFS-10843 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12828142/HDFS-10843.003.patch | | Optional Tests | asflicense compile javac javadoc mvninstall mvnsite unit findbugs checkstyle | | uname | Linux c026c367bdf6 3.13.0-93-generic #140-Ubuntu SMP Mon Jul 18 21:21:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh | | git revision | trunk / 72dfb04 | | Default Java | 1.8.0_101 | | findbugs | v3.0.0 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/16722/artifact/patchprocess/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/16722/testReport/ | | modules | C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs | | Console output | https://builds.apache.org/job/PreCommit-HDFS-Build/16722/console | | Powered by | Apache Yetus 0.4.0-SNAPSHOT http://yetus.apache.org | This message was automatically generated. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Aff
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15485687#comment-15485687 ] Hadoop QA commented on HDFS-10843: -- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 37s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 30s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 51s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 12s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 38s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 46s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 27s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs: The patch generated 9 new + 388 unchanged - 6 fixed = 397 total (was 394) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 10s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 57m 49s{color} | {color:green} hadoop-hdfs in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 18s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 76m 25s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Image:yetus/hadoop:9560f25 | | JIRA Issue | HDFS-10843 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12828124/HDFS-10843.002.patch | | Optional Tests | asflicense compile javac javadoc mvninstall mvnsite unit findbugs checkstyle | | uname | Linux 31998cefd804 3.13.0-93-generic #140-Ubuntu SMP Mon Jul 18 21:21:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh | | git revision | trunk / 58ed4fa | | Default Java | 1.8.0_101 | | findbugs | v3.0.0 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/16718/artifact/patchprocess/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/16718/testReport/ | | modules | C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs | | Console output | https://builds.apache.org/job/PreCommit-HDFS-Build/16718/console | | Powered by | Apache Yetus 0.4.0-SNAPSHOT http://yetus.apache.org | This message was automatically generated. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Aff
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15478335#comment-15478335 ] Konstantin Shvachko commented on HDFS-10843: You are right {{completeBlock()}} calls are too deep inside {{BlockManager}}. How about we add a new {{getFSDirectory{}}} method to {{Namesystem}}. This should be sufficient to resolve this case. Historically {{Namesystem}} interface was added in HDFS-2266. Not much motivation is given there, but the idea was a better separation between {{FSNamesystem}} and {{BlockManager}}. Initially {{Namesystem}} was very basic essentially accessing FSNamesystem's locks and SafeMode. But since then people were adding rather random methods into it. Mostly in order to allow access to {{FSDirectory}}, like {{getBlockCollection()}}. So may be we should just add {{Namesystem.getFSDirectory{}}} so that later we could eliminate {{getBlockCollection()}} and {{isInSnapshot()}} from {{Namesystem}}. For the tests you should probably combine new test cases into one or even integrate with the existing cases. Starting mini-cluster is time consuming, increases test running time. So optimally we should start the cluster once in {{@BeforeClass}}. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475609#comment-15475609 ] Erik Krogen commented on HDFS-10843: 1. The problem is that most calls to completeBlock() originate from within {{BlockManager}}, which does not maintain a reference to {{FSDirectory}}. It only has access to {{FSDirectory}} indirectly through {{FSNamesystem}}, and maintains its reference to {{FSNamesystem}} as the {{Namesystem}} interface. This was the only reason I changed the {{Namespace}} interface. Maybe it would be better to make {{BlockManager}} require {{FSNamesystem}} specifically (which exports a {{getFSDirectory}} method) rather than a general {{Namesystem}}? Are there future plans for other classes implementing {{Namesystem}}? 2. The cluster creation happens in an {{@Before}}-annotated method so IIUC the cluster should be fresh before each test. 3. Got it. Thanks for looking! Let me know what you think on #1. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475522#comment-15475522 ] Konstantin Shvachko commented on HDFS-10843: One more thing about {{iip}} parameter. Let's keep it where we can. It is an optimization. Because resolving the path is expensive, we should avoid it if possible. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475512#comment-15475512 ] Konstantin Shvachko commented on HDFS-10843: Hey Erik, looks like you are fixing two issues here. One about updating space cache value after completing the block, and another that {{setReplication()}} incorrectly updates space for UC files. Both good finds, great! # Your idea to place space update logic in a single place, inside {{completeBlock()}}, is good. I would suggest implementing it a bit differently. I would move the part of {{FSN.commitOrCompleteLastBlock()}} related to {{// Adjust disk space consumption if required}} to {{FSDirectory}} as a new method {{adjustSpaceConsumed(fileINode, iip, commitBlock)}}. Then you can call it from {{completeBlock()}}, which should take {{FSDirectory}} as a parameter. Better not to change {{Namespace}} interface. # The tests looks good. I see you shutting down 3 DNs in the new test. Which may affect old tests if they are executed after the new ones. I did not check but worth verifying. # Also {{Answer}} should be used with a generic parameter {{Answer}}. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475227#comment-15475227 ] Hadoop QA commented on HDFS-10843: -- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m 4s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 31s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 52s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 12s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 44s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 46s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 27s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 48s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 10s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 60m 50s{color} | {color:green} hadoop-hdfs in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 18s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 80m 6s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Image:yetus/hadoop:9560f25 | | JIRA Issue | HDFS-10843 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12827654/HDFS-10843.001.patch | | Optional Tests | asflicense compile javac javadoc mvninstall mvnsite unit findbugs checkstyle | | uname | Linux a4df679aeb43 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh | | git revision | trunk / b6d839a | | Default Java | 1.8.0_101 | | findbugs | v3.0.0 | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/16681/testReport/ | | modules | C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs | | Console output | https://builds.apache.org/job/PreCommit-HDFS-Build/16681/console | | Powered by | Apache Yetus 0.4.0-SNAPSHOT http://yetus.apache.org | This message was automatically generated. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch, HDFS-10843.001.patch > > > Currently when a block has been committed but has not yet been completed,
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475013#comment-15475013 ] Erik Krogen commented on HDFS-10843: TestDFSStripedOutputStreamWithFailure appears unrelated and passes locally. Attached updated v1 patch fixing Findbugs and Checkstyle. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > Attachments: HDFS-10843.000.patch > > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474924#comment-15474924 ] Hadoop QA commented on HDFS-10843: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 21s{color} | {color:blue} Docker mode activated. {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 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m 40s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 47s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 33s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 54s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 15s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 48s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 46s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 27s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs: The patch generated 2 new + 361 unchanged - 0 fixed = 363 total (was 361) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 10s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 50s{color} | {color:red} hadoop-hdfs-project/hadoop-hdfs generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0) {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 78m 7s{color} | {color:red} hadoop-hdfs in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 26s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 98m 53s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | FindBugs | module:hadoop-hdfs-project/hadoop-hdfs | | | Dead store to iip in org.apache.hadoop.hdfs.server.namenode.FSNamesystem.closeFileCommitBlocks(String, INodeFile, BlockInfo) At FSNamesystem.java:org.apache.hadoop.hdfs.server.namenode.FSNamesystem.closeFileCommitBlocks(String, INodeFile, BlockInfo) At FSNamesystem.java:[line 3595] | | Failed junit tests | hadoop.hdfs.TestDFSStripedOutputStreamWithFailure | \\ \\ || Subsystem || Report/Notes || | Docker | Image:yetus/hadoop:9560f25 | | JIRA Issue | HDFS-10843 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12827626/HDFS-10843.000.patch | | Optional Tests | asflicense compile javac javadoc mvninstall mvnsite unit findbugs checkstyle | | uname | Linux 8aecd0d50418 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh | | git revision | trunk / 401db4f | | Default Java | 1.8.0_101 | | findbugs | v3.0.0 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/16674/artifact/patchprocess/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt | | findbugs | https://builds.apache.org/job/PreCommit-HDFS-Build/16674/artifact/patchprocess/new-findbugs-hadoop-hdfs-project_hadoop-hdfs.html | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/16674/artifact/patchprocess/patch-unit-ha
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15469284#comment-15469284 ] Konstantin Shvachko commented on HDFS-10843: [~xkrogen] thanks for digging into this. ??When the block is committed, the cached size is updated to the final size of the block. However, the calculation of the computed size uses the full block size until the block is completed?? Looks like {{computeQuotaUsage()}} does not use prefered block size to compute file size. And {{computeFileSize()}} checks for COMPLETED state. So we should correct cached value and update it to final length only when the block is completed. I mean whatever is cached should correspond to how the quotas are checked. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15469153#comment-15469153 ] Erik Krogen commented on HDFS-10843: After further consideration it seems that it is probably most appropriate to continue to use the preferred block size as the cached size until the block is actually completed rather than just committed. This is more consistent with how the rest of the code treats the under construction size (see comments on {{INodeFile.{storagespaceConsumed,computeFileSize}}}, {{FileWithSnapshotFeature.updateQuotaAndCollectBlocks}}, {{FSDirAppendOp.computeQuotaDeltaForUCBlock}}); it seems that generally the under construction / not under construction distinction is used rather than committed vs. uncommitted. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468993#comment-15468993 ] Erik Krogen commented on HDFS-10843: I have realized that this bug is more severe than I previously thought. As described above this will only result in a transient state where the cached and computed values briefly disagree. However, if the replication is changed while in this state, or similarly, while the block is under construction but has not yet been committed, the cached value will be updated incorrectly, causing the cached value to be persistently incorrect. All of these issues should be fixed by the same root cause of ensuring that the storagespace values are always computed in a consistent way - right now different spots in the code handle the different states (under construction, committed, completed) in inconsistent ways. > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-10843) Quota Feature Cached Size != Computed Size When Block Committed But Not Completed
[ https://issues.apache.org/jira/browse/HDFS-10843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468631#comment-15468631 ] Erik Krogen commented on HDFS-10843: I will attach a patch containing a unit test demonstrating the behavior as well as a fix. [~shv], can you comment on the desired behavior? > Quota Feature Cached Size != Computed Size When Block Committed But Not > Completed > - > > Key: HDFS-10843 > URL: https://issues.apache.org/jira/browse/HDFS-10843 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode >Affects Versions: 2.6.0 >Reporter: Erik Krogen >Assignee: Erik Krogen > > Currently when a block has been committed but has not yet been completed, the > cached size (used for the quota feature) of the directory containing that > block differs from the computed size. This results in log messages of the > following form: > bq. ERROR namenode.NameNode > (DirectoryWithQuotaFeature.java:checkStoragespace(141)) - BUG: Inconsistent > storagespace for directory /TestQuotaUpdate. Cached = 512 != Computed = 8192 > When a block is initially started under construction, the used space is > conservatively set to a full block. When the block is committed, the cached > size is updated to the final size of the block. However, the calculation of > the computed size uses the full block size until the block is completed, so > in the period where the block is committed but not completed they disagree. > To fix this we need to decide which is correct and fix the other to match. It > seems to me that the cached size is correct since once the block is committed > its size will not change. > This can be reproduced using the following steps: > - Create a directory with a quota > - Start writing to a file within this directory > - Prevent all datanodes to which the file is written from communicating the > corresponding BlockReceivedAndDeletedRequestProto to the NN temporarily (i.e. > simulate a transient network partition/delay) > - During this time, call DistributedFileSystem.getContentSummary() on the > directory with the quota -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org