[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948248#comment-14948248 ] Hudson commented on HDFS-8164: -- FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #507 (See [https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/507/]) HDFS-8164. cTime is 0 in VERSION file for newly formatted NameNode. (yzhang: rev 1107bd399c790467b22e55291c2611fd1c16e156) * hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSImage.java * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java * hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948249#comment-14948249 ] Hudson commented on HDFS-8164: -- FAILURE: Integrated in Hadoop-Yarn-trunk #1235 (See [https://builds.apache.org/job/Hadoop-Yarn-trunk/1235/]) HDFS-8164. cTime is 0 in VERSION file for newly formatted NameNode. (yzhang: rev 1107bd399c790467b22e55291c2611fd1c16e156) * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java * hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java * hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSImage.java > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948159#comment-14948159 ] Yongjun Zhang commented on HDFS-8164: - Committed to trunk and branch-2. Thanks Xiao for the contribution. Thanks [~cnauroth] for reporting the issue and [~vinayrpet] for the review. > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948156#comment-14948156 ] Hudson commented on HDFS-8164: -- FAILURE: Integrated in Hadoop-trunk-Commit #8593 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/8593/]) HDFS-8164. cTime is 0 in VERSION file for newly formatted NameNode. (yzhang: rev 1107bd399c790467b22e55291c2611fd1c16e156) * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java * hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSImage.java * hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948375#comment-14948375 ] Hudson commented on HDFS-8164: -- FAILURE: Integrated in Hadoop-Mapreduce-trunk-Java8 #498 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/498/]) HDFS-8164. cTime is 0 in VERSION file for newly formatted NameNode. (yzhang: rev 1107bd399c790467b22e55291c2611fd1c16e156) * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java * hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSImage.java * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java * hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948508#comment-14948508 ] Hudson commented on HDFS-8164: -- SUCCESS: Integrated in Hadoop-Hdfs-trunk #2409 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/2409/]) HDFS-8164. cTime is 0 in VERSION file for newly formatted NameNode. (yzhang: rev 1107bd399c790467b22e55291c2611fd1c16e156) * hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSImage.java * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948576#comment-14948576 ] Hudson commented on HDFS-8164: -- FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #471 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/471/]) HDFS-8164. cTime is 0 in VERSION file for newly formatted NameNode. (yzhang: rev 1107bd399c790467b22e55291c2611fd1c16e156) * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java * hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSImage.java > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948405#comment-14948405 ] Hudson commented on HDFS-8164: -- FAILURE: Integrated in Hadoop-Mapreduce-trunk #2442 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2442/]) HDFS-8164. cTime is 0 in VERSION file for newly formatted NameNode. (yzhang: rev 1107bd399c790467b22e55291c2611fd1c16e156) * hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java * hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSImage.java * hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948949#comment-14948949 ] Xiao Chen commented on HDFS-8164: - Thanks Yongjun for the review and commit. Thanks Chris for reporting this issue and Vinayakumar for the review. > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Fix For: 2.8.0 > > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948043#comment-14948043 ] Yongjun Zhang commented on HDFS-8164: - +1 on rev7, will commit momentarily. > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch, HDFS-8164.007.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943097#comment-14943097
]
Vinayakumar B commented on HDFS-8164:
-
Thanks [~xiaochen], patch looks good overall.
Have few comments
1. {{FSN#getCTime()}} is used only in test added. So it would be better to
annotate as @VisibleForTesting.
2. In Test, {{NameNode.format(conf);}}, I think this call is unnecessary.
3. {code}final long millsOneDay = 1000 * 60 * 60 * 24;
assertTrue(ctime < pre + millsOneDay);{code}
This also I feel unnecessary. Is it really required to verify cTime is within a
day. ?
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch, HDFS-8164.004.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14944045#comment-14944045
]
Hadoop QA commented on HDFS-8164:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 18m 4s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 8m 1s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 27s | There were no new javadoc
warning messages. |
| {color:red}-1{color} | release audit | 0m 16s | The applied patch generated
1 release audit warnings. |
| {color:red}-1{color} | checkstyle | 1m 23s | The applied patch generated 1
new checkstyle issues (total was 298, now 298). |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 28s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 34s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 30s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 3m 15s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 202m 46s | Tests failed in hadoop-hdfs. |
| | | 248m 47s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.hdfs.web.TestWebHdfsTimeouts |
| | hadoop.TestGenericRefresh |
| | hadoop.hdfs.security.TestDelegationTokenForProxyUser |
| | hadoop.hdfs.web.TestWebHDFSOAuth2 |
| | hadoop.hdfs.server.namenode.TestFSNamesystem |
| | hadoop.hdfs.web.TestWebHdfsContentLength |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12765022/HDFS-8164.005.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / b925cf1 |
| Release Audit |
https://builds.apache.org/job/PreCommit-HDFS-Build/12793/artifact/patchprocess/patchReleaseAuditProblems.txt
|
| checkstyle |
https://builds.apache.org/job/PreCommit-HDFS-Build/12793/artifact/patchprocess/diffcheckstylehadoop-hdfs.txt
|
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12793/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12793/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf900.gq1.ygridcore.net 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 |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12793/console |
This message was automatically generated.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch,
> HDFS-8164.006.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14944103#comment-14944103 ] Yongjun Zhang commented on HDFS-8164: - Thanks for the new rev [~xiaochen]. Patch rev6 looks good to me. Hi [~vinayrpet], wonder if you have further comments. I will commit tomorrow if not. Thanks. > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch, > HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch, > HDFS-8164.006.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943884#comment-14943884
]
Yongjun Zhang commented on HDFS-8164:
-
Thanks [~vinayrpet] for the review and [~xiaochen] for the new rev.
It looks good, couple of small things:
1. comment for {{getCTime}}, the return value section is not correct, suggest
to change to something like:
{code}
/**
* Get the creation time of the file system.
* Notice that this time is initialized to NameNode format time, and updated
* to upgrade time during upgrades.
* @return time in milli seconds. See {@link
org.apache.hadoop.util.Time#now()}.
*/
{code}
2. Suggest to change the assertion in the test code to (<= instead of <).
{code}
assertTrue(ctime <= post);
{code}
Thanks.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14944186#comment-14944186
]
Hadoop QA commented on HDFS-8164:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 17m 48s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 7m 53s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 20s | There were no new javadoc
warning messages. |
| {color:red}-1{color} | release audit | 0m 15s | The applied patch generated
1 release audit warnings. |
| {color:red}-1{color} | checkstyle | 1m 25s | The applied patch generated 2
new checkstyle issues (total was 298, now 299). |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 29s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 36s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 29s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 3m 8s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 88m 10s | Tests failed in hadoop-hdfs. |
| | | 133m 36s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.hdfs.server.datanode.TestDataNodeFSDataSetSink |
| | hadoop.hdfs.TestFileAppend4 |
| | hadoop.hdfs.TestRead |
| | hadoop.hdfs.server.namenode.TestSecondaryWebUi |
| | hadoop.hdfs.server.namenode.TestNNStorageRetentionFunctional |
| | hadoop.hdfs.server.namenode.TestFavoredNodesEndToEnd |
| | hadoop.hdfs.server.namenode.ha.TestHAStateTransitions |
| | hadoop.hdfs.server.datanode.TestRefreshNamenodes |
| | hadoop.hdfs.TestHdfsAdmin |
| | hadoop.hdfs.server.datanode.TestDataNodeUUID |
| | hadoop.hdfs.server.datanode.TestDataNodeVolumeFailureReporting |
| | hadoop.hdfs.server.datanode.TestBlockHasMultipleReplicasOnSameDN |
| | hadoop.hdfs.server.namenode.ha.TestLossyRetryInvocationHandler |
| | hadoop.hdfs.TestClientReportBadBlock |
| | hadoop.hdfs.server.namenode.TestNamenodeCapacityReport |
| | hadoop.hdfs.server.namenode.TestNamenodeRetryCache |
| | hadoop.hdfs.server.namenode.TestFSEditLogLoader |
| | hadoop.hdfs.server.namenode.TestAuditLogger |
| | hadoop.hdfs.server.blockmanagement.TestUnderReplicatedBlocks |
| | hadoop.hdfs.server.datanode.fsdataset.impl.TestLazyPersistPolicy |
| | hadoop.hdfs.server.blockmanagement.TestDatanodeManager |
| | hadoop.hdfs.server.datanode.TestDataNodeMetrics |
| | hadoop.hdfs.TestDFSPacket |
| | hadoop.hdfs.TestAppendSnapshotTruncate |
| | hadoop.hdfs.server.datanode.fsdataset.impl.TestLazyPersistFiles |
| | hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup |
| |
hadoop.hdfs.server.datanode.fsdataset.impl.TestLazyPersistReplicaPlacement |
| | hadoop.hdfs.server.namenode.TestNameNodeRpcServer |
| | hadoop.hdfs.TestPeerCache |
| | hadoop.hdfs.TestSafeModeWithStripedFile |
| | hadoop.hdfs.TestFileAppendRestart |
| | hadoop.hdfs.server.namenode.TestSecondaryNameNodeUpgrade |
| | hadoop.cli.TestErasureCodingCLI |
| | hadoop.hdfs.server.namenode.TestEditLogFileInputStream |
| | hadoop.hdfs.server.namenode.snapshot.TestSetQuotaWithSnapshot |
| | hadoop.hdfs.server.namenode.TestNameNodeOptionParsing |
| | hadoop.hdfs.server.namenode.ha.TestHAFsck |
| | hadoop.hdfs.server.datanode.TestDataStorage |
| | hadoop.hdfs.protocol.TestBlockListAsLongs |
| | hadoop.hdfs.server.namenode.TestBlockPlacementPolicyRackFaultTolerant |
| | hadoop.hdfs.server.namenode.snapshot.TestOpenFilesWithSnapshot |
| | hadoop.hdfs.server.namenode.TestAuditLogAtDebug |
| | hadoop.hdfs.TestFileStatusWithECPolicy |
| | hadoop.hdfs.server.namenode.TestHDFSConcat |
| | hadoop.hdfs.server.namenode.metrics.TestNameNodeMetrics |
| | hadoop.TestRefreshCallQueue |
| | hadoop.hdfs.TestListFilesInDFS |
| | hadoop.hdfs.server.namenode.TestAddBlock |
| | hadoop.hdfs.server.datanode.TestDnRespectsBlockReportSplitThreshold |
| | hadoop.hdfs.server.namenode.TestStartupOptionUpgrade |
| | hadoop.hdfs.server.namenode.TestNameEditsConfigs |
| | hadoop.hdfs.TestMiniDFSCluster |
| | hadoop.hdfs.server.mover.TestMover |
| | hadoop.hdfs.server.datanode.TestBPOfferService |
| | hadoop.security.TestPermissionSymlinks |
| | hadoop.hdfs.TestDFSRollback |
| | hadoop.hdfs.server.namenode.ha.TestRequestHedgingProxyProvider |
| | hadoop.hdfs.server.namenode.ha.TestHASafeMode |
| | hadoop.hdfs.server.datanode.fsdataset.impl.TestWriteToReplica |
| |
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14944434#comment-14944434
]
Hadoop QA commented on HDFS-8164:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | pre-patch | 16m 9s | Findbugs (version ) appears to
be broken on trunk. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 7m 59s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 25s | There were no new javadoc
warning messages. |
| {color:red}-1{color} | release audit | 0m 15s | The applied patch generated
1 release audit warnings. |
| {color:green}+1{color} | checkstyle | 0m 31s | There were no new checkstyle
issues. |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 39s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 36s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 31s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 3m 16s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 199m 38s | Tests failed in hadoop-hdfs. |
| | | 243m 2s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests |
hadoop.hdfs.server.datanode.fsdataset.impl.TestLazyPersistFiles |
| | hadoop.hdfs.web.TestWebHdfsTimeouts |
| | hadoop.hdfs.web.TestWebHdfsContentLength |
| | hadoop.hdfs.security.TestDelegationTokenForProxyUser |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12765081/HDFS-8164.007.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 30ac69c |
| Release Audit |
https://builds.apache.org/job/PreCommit-HDFS-Build/12800/artifact/patchprocess/patchReleaseAuditProblems.txt
|
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12800/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12800/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf903.gq1.ygridcore.net 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 |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12800/console |
This message was automatically generated.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch,
> HDFS-8164.006.patch, HDFS-8164.007.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943640#comment-14943640
]
Xiao Chen commented on HDFS-8164:
-
Thank you very much for the review [~vinayrpet]! I attached patch 005
addressing your comments.
{quote}
1. FSN#getCTime() is used only in test added. So it would be better to annotate
as @VisibleForTesting.
{quote}
Fixed. I used this in another local branch, but it's definitely clearer to set
@VisibleForTesting here, and remove it when it's used in another JIRA.
{quote}
2. In Test, NameNode.format(conf);, I think this call is unnecessary.
{quote}
Fixed. The builder by default formats the namenode when {{build}}.
{quote}
3.
final long millsOneDay = 1000 * 60 * 60 * 24;
assertTrue(ctime < pre + millsOneDay);
This also I feel unnecessary. Is it really required to verify cTime is within a
day. ?
{quote}
Updated. My intention is to test both the upper bound and the lower bound of
the cTime. I updated the test to get {{now}} dynamically after the minicluster
startup. Does this make sense?
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch, HDFS-8164.004.patch, HDFS-8164.005.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942897#comment-14942897
]
Hadoop QA commented on HDFS-8164:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 17m 59s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 8m 1s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 19s | There were no new javadoc
warning messages. |
| {color:red}-1{color} | release audit | 0m 16s | The applied patch generated
1 release audit warnings. |
| {color:red}-1{color} | checkstyle | 1m 0s | The applied patch generated
298 new checkstyle issues (total was 0, now 298). |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 29s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 34s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 27s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 3m 11s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 200m 11s | Tests failed in hadoop-hdfs. |
| | | 245m 31s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.hdfs.server.datanode.TestDirectoryScanner |
| | hadoop.hdfs.web.TestWebHdfsTimeouts |
| | hadoop.hdfs.TestLeaseRecovery2 |
| | hadoop.hdfs.server.balancer.TestBalancer |
| | hadoop.hdfs.security.TestDelegationTokenForProxyUser |
| | hadoop.hdfs.web.TestWebHDFSOAuth2 |
| | hadoop.hdfs.web.TestWebHdfsContentLength |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12764959/HDFS-8164.004.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 30e2f83 |
| Release Audit |
https://builds.apache.org/job/PreCommit-HDFS-Build/12787/artifact/patchprocess/patchReleaseAuditProblems.txt
|
| checkstyle |
https://builds.apache.org/job/PreCommit-HDFS-Build/12787/artifact/patchprocess/diffcheckstylehadoop-hdfs.txt
|
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12787/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12787/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf900.gq1.ygridcore.net 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 |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12787/console |
This message was automatically generated.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch, HDFS-8164.004.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942864#comment-14942864
]
Xiao Chen commented on HDFS-8164:
-
Thanks Yongjun again for the review and comments.
I have addressed comment #1 to add comments. Please see if it makes sense to
you.
I also added the nullity check on {{FSNamesystem}} to check {{fsImage}}.
However, the {{NNStorage}} variable on {{FSImage}} cannot be null, since it's
created during initialization. Also, I think this is the reason why other
{{getStorage}} calls do not check nullity.
Thanks a lot!
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch, HDFS-8164.004.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942017#comment-14942017
]
Yongjun Zhang commented on HDFS-8164:
-
Hi [~xiaochen],
Thanks for the revision. Some more comments about
{code}
1523 long getCTime() {
1524return fsImage.getStorage().getCTime();
1525 }
{code}
1. As [~cnauroth] described, the time is
* initialized when NN is formated
* updated upon an upgrade
Ideally we can have two time: FormatTime, UpgadeTime to be clear what it means.
Lack of two names, I think we can continue to use getCTime, but we should have
javadoc for {{ long getCTime()}} to state what this time meant.
2. {{fsimage}} can be null, and {{getSotarge()}} can return null. Suggest to
check null before access. If we have one API at each layer, then only need to
check one there.
Thanks.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942033#comment-14942033
]
Hadoop QA commented on HDFS-8164:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 18m 1s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 8m 0s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 17s | There were no new javadoc
warning messages. |
| {color:red}-1{color} | release audit | 0m 15s | The applied patch generated
1 release audit warnings. |
| {color:red}-1{color} | checkstyle | 1m 27s | The applied patch generated 1
new checkstyle issues (total was 298, now 298). |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 28s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 34s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 29s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 3m 13s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 73m 24s | Tests failed in hadoop-hdfs. |
| | | 119m 11s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.hdfs.web.TestWebHDFSOAuth2 |
| Timed out tests |
org.apache.hadoop.hdfs.server.namenode.TestParallelImageWrite |
| | org.apache.hadoop.hdfs.TestDFSStripedOutputStreamWithFailure010 |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12764871/HDFS-8164.003.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / fdf02d1 |
| Release Audit |
https://builds.apache.org/job/PreCommit-HDFS-Build/12779/artifact/patchprocess/patchReleaseAuditProblems.txt
|
| checkstyle |
https://builds.apache.org/job/PreCommit-HDFS-Build/12779/artifact/patchprocess/diffcheckstylehadoop-hdfs.txt
|
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12779/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12779/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf900.gq1.ygridcore.net 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 |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12779/console |
This message was automatically generated.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch,
> HDFS-8164.003.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940480#comment-14940480
]
Hadoop QA commented on HDFS-8164:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 18m 54s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 8m 8s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 34s | There were no new javadoc
warning messages. |
| {color:red}-1{color} | release audit | 0m 16s | The applied patch generated
1 release audit warnings. |
| {color:green}+1{color} | checkstyle | 1m 27s | There were no new checkstyle
issues. |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 33s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 34s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 30s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 3m 17s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 240m 46s | Tests failed in hadoop-hdfs. |
| | | 288m 3s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.hdfs.TestReplaceDatanodeOnFailure |
| | hadoop.hdfs.server.blockmanagement.TestBlockManager |
| | hadoop.hdfs.TestRecoverStripedFile |
| | hadoop.hdfs.TestWriteReadStripedFile |
| | hadoop.hdfs.server.balancer.TestBalancerWithMultipleNameNodes |
| | hadoop.hdfs.server.blockmanagement.TestNodeCount |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12764636/HDFS-8164.002.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / ecbfd68 |
| Release Audit |
https://builds.apache.org/job/PreCommit-HDFS-Build/12762/artifact/patchprocess/patchReleaseAuditProblems.txt
|
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12762/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12762/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf909.gq1.ygridcore.net 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 |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12762/console |
This message was automatically generated.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940496#comment-14940496 ] Xiao Chen commented on HDFS-8164: - The test failures and release audit warning are again unrelated to this fix. > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Assignee: Xiao Chen >Priority: Minor > Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch > > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940536#comment-14940536
]
Yongjun Zhang commented on HDFS-8164:
-
Hi [~xiaochen],
Thanks for working on this issue. The patch looks good, one comment here:
{code}
cluster.getNamesystem().getFSImage().getStorage().getCTime()
{code}
is a quite deep call. I'd suggest that we can create an API at different level,
such as
{{
FSNamesystem.getCTime()
FSImage.getCTime()
}}
Hi [~cnauroth], thanks for creating this jira. Would you cmment whether my
suggestion above makes sense to you?
Thanks a lot.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch, HDFS-8164.002.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14938752#comment-14938752 ] Xiao Chen commented on HDFS-8164: - Hi Chris, Thanks for reporting the issue and explain! I will be working on it. > cTime is 0 in VERSION file for newly formatted NameNode. > > > Key: HDFS-8164 > URL: https://issues.apache.org/jira/browse/HDFS-8164 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.0.3-alpha >Reporter: Chris Nauroth >Priority: Minor > > After formatting a NameNode and inspecting its VERSION file, the cTime > property shows 0. The value does get updated to current time during an > upgrade, but I believe this is intended to be the creation time of the > cluster, and therefore the initial value of 0 before an upgrade can cause > confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[
https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939340#comment-14939340
]
Hadoop QA commented on HDFS-8164:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 17m 52s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:green}+1{color} | tests included | 0m 0s | The patch appears to
include 1 new or modified test files. |
| {color:green}+1{color} | javac | 7m 56s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 23s | There were no new javadoc
warning messages. |
| {color:red}-1{color} | release audit | 0m 16s | The applied patch generated
1 release audit warnings. |
| {color:green}+1{color} | checkstyle | 1m 26s | There were no new checkstyle
issues. |
| {color:red}-1{color} | whitespace | 0m 0s | The patch has 1 line(s) that
end in whitespace. Use git apply --whitespace=fix. |
| {color:green}+1{color} | install | 1m 30s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 36s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 2m 28s | The patch does not introduce
any new Findbugs (version 3.0.0) warnings. |
| {color:green}+1{color} | native | 3m 13s | Pre-build of native portion |
| {color:red}-1{color} | hdfs tests | 198m 36s | Tests failed in hadoop-hdfs. |
| | | 244m 20s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.hdfs.TestRecoverStripedFile |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12764520/HDFS-8164.001.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 5db371f |
| Release Audit |
https://builds.apache.org/job/PreCommit-HDFS-Build/12756/artifact/patchprocess/patchReleaseAuditProblems.txt
|
| whitespace |
https://builds.apache.org/job/PreCommit-HDFS-Build/12756/artifact/patchprocess/whitespace.txt
|
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/12756/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/12756/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf903.gq1.ygridcore.net 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 |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/12756/console |
This message was automatically generated.
> cTime is 0 in VERSION file for newly formatted NameNode.
>
>
> Key: HDFS-8164
> URL: https://issues.apache.org/jira/browse/HDFS-8164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.0.3-alpha
>Reporter: Chris Nauroth
>Assignee: Xiao Chen
>Priority: Minor
> Attachments: HDFS-8164.001.patch
>
>
> After formatting a NameNode and inspecting its VERSION file, the cTime
> property shows 0. The value does get updated to current time during an
> upgrade, but I believe this is intended to be the creation time of the
> cluster, and therefore the initial value of 0 before an upgrade can cause
> confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-8164) cTime is 0 in VERSION file for newly formatted NameNode.
[ https://issues.apache.org/jira/browse/HDFS-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14498544#comment-14498544 ] Chris Nauroth commented on HDFS-8164: - I don't think this bug causes any significant impact, so I set priority to minor. It's just a potential source of confusion when manually inspecting the metadata directories. cTime is 0 in VERSION file for newly formatted NameNode. Key: HDFS-8164 URL: https://issues.apache.org/jira/browse/HDFS-8164 Project: Hadoop HDFS Issue Type: Bug Components: namenode Affects Versions: 2.0.3-alpha Reporter: Chris Nauroth Priority: Minor After formatting a NameNode and inspecting its VERSION file, the cTime property shows 0. The value does get updated to current time during an upgrade, but I believe this is intended to be the creation time of the cluster, and therefore the initial value of 0 before an upgrade can cause confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
