[jira] [Commented] (HDFS-2747) HA: entering safe mode after starting SBN can NPE
[
https://issues.apache.org/jira/browse/HDFS-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185446#comment-13185446
]
Uma Maheswara Rao G commented on HDFS-2747:
---
Yes, Todd. Before that, I am thinking, can we skip logSyncAll invocation from
enterSafeMode call when numTransactions is zero in FSEditlog?
do you think any other impacts with this? Presetly i couldnot think of any
scenario where it can impact.
> HA: entering safe mode after starting SBN can NPE
> -
>
> Key: HDFS-2747
> URL: https://issues.apache.org/jira/browse/HDFS-2747
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha
>Affects Versions: HA branch (HDFS-1623)
>Reporter: Eli Collins
>Assignee: Uma Maheswara Rao G
>
> Entering Safemode on the primary after while it's already in safemode after
> the SBN is started results in an NPE:
> {noformat}
> hadoop-0.24.0-SNAPSHOT $ ./bin/hdfs dfsadmin -safemode get
> Safe mode is ON
> hadoop-0.24.0-SNAPSHOT $ ./bin/hdfs dfsadmin -safemode enter
> safemode: java.lang.NullPointerException
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2700) TestDataNodeMultipleRegistrations is failing in trunk
[ https://issues.apache.org/jira/browse/HDFS-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185435#comment-13185435 ] Uma Maheswara Rao G commented on HDFS-2700: --- Sure, i will do that from next time. :-) > TestDataNodeMultipleRegistrations is failing in trunk > - > > Key: HDFS-2700 > URL: https://issues.apache.org/jira/browse/HDFS-2700 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Uma Maheswara Rao G >Assignee: Uma Maheswara Rao G > Fix For: 0.24.0 > > Attachments: HDFS-2700.patch > > > TestDataNodeMultipleRegistrations is failing from last couple of builds > https://builds.apache.org/job/PreCommit-HDFS-Build/lastCompletedBuild/testReport/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-2335) DataNodeCluster and NNStorage always pull fresh entropy
[ https://issues.apache.org/jira/browse/HDFS-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HDFS-2335: - Fix Version/s: 0.23.1 0.24.0 Added "Fix Version/s". > DataNodeCluster and NNStorage always pull fresh entropy > --- > > Key: HDFS-2335 > URL: https://issues.apache.org/jira/browse/HDFS-2335 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node, name-node >Affects Versions: 0.23.0, 0.24.0, 1.0.0 >Reporter: Eli Collins >Assignee: Uma Maheswara Rao G > Fix For: 0.24.0, 0.23.1 > > Attachments: HDFS-2335.patch, HDFS-2335.patch > > > Jira for giving DataNodeCluster and NNStorage the same treatment as > HDFS-1835. They're not truly cryptographic uses as well. We should also > factor this out to a utility method, seems like the three uses are slightly > different, eg one uses DFSUtil.getRandom and the other creates a new Random > object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2700) TestDataNodeMultipleRegistrations is failing in trunk
[
https://issues.apache.org/jira/browse/HDFS-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185431#comment-13185431
]
Tsz Wo (Nicholas), SZE commented on HDFS-2700:
--
{quote}
TestDataNodeMultipleRegistrations is failing from last couple of builds
https://builds.apache.org/job/PreCommit-HDFS-Build/lastCompletedBuild/testReport/
{quote}
It may be better to use the build number(s) instead of using the link with
lastCompletedBuild next time since the "last" build keeps changing from time to
time. :)
> TestDataNodeMultipleRegistrations is failing in trunk
> -
>
> Key: HDFS-2700
> URL: https://issues.apache.org/jira/browse/HDFS-2700
> Project: Hadoop HDFS
> Issue Type: Bug
>Reporter: Uma Maheswara Rao G
>Assignee: Uma Maheswara Rao G
> Fix For: 0.24.0
>
> Attachments: HDFS-2700.patch
>
>
> TestDataNodeMultipleRegistrations is failing from last couple of builds
> https://builds.apache.org/job/PreCommit-HDFS-Build/lastCompletedBuild/testReport/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2731) Autopopulate standby name dirs if they're empty
[ https://issues.apache.org/jira/browse/HDFS-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185417#comment-13185417 ] Sanjay Radia commented on HDFS-2731: Can we generalize this: on startup, a NN (PNN or SBN) should make all dirs consistent - i.e. copy any missing images and logs. > Autopopulate standby name dirs if they're empty > --- > > Key: HDFS-2731 > URL: https://issues.apache.org/jira/browse/HDFS-2731 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha >Affects Versions: HA branch (HDFS-1623) >Reporter: Eli Collins >Assignee: Eli Collins > > To setup a SBN we currently format the primary then manually copy the name > dirs to the SBN. The SBN should do this automatically. Specifically, on NN > startup, if HA with a shared edits dir is configured and populated, if the > SBN has empty name dirs it should downloads the image and log from the > primary (as an optimization it could copy the logs from the shared dir). If > the other NN is still in standby then it should fail to start as it does > currently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2731) Autopopulate standby name dirs if they're empty
[ https://issues.apache.org/jira/browse/HDFS-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185416#comment-13185416 ] Sanjay Radia commented on HDFS-2731: >if the SBN has empty name dirs it should downloads the image and log from the >primary (as an optimization it could copy the logs from the shared dir). I am missing this: both Image and Edits should be on shared dirs (ie no need to copy image from primary - it should be available in shared dir). > Autopopulate standby name dirs if they're empty > --- > > Key: HDFS-2731 > URL: https://issues.apache.org/jira/browse/HDFS-2731 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha >Affects Versions: HA branch (HDFS-1623) >Reporter: Eli Collins >Assignee: Eli Collins > > To setup a SBN we currently format the primary then manually copy the name > dirs to the SBN. The SBN should do this automatically. Specifically, on NN > startup, if HA with a shared edits dir is configured and populated, if the > SBN has empty name dirs it should downloads the image and log from the > primary (as an optimization it could copy the logs from the shared dir). If > the other NN is still in standby then it should fail to start as it does > currently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2768) BackupNode stop can not close proxy connections because it is not a proxy instance.
[ https://issues.apache.org/jira/browse/HDFS-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185408#comment-13185408 ] Uma Maheswara Rao G commented on HDFS-2768: --- Eli, I think in BPOfferSevice also we used DatanodeProtocolClientSideTranslatorPB directly instead of DatanodeProtocol. In that class many places already specialized to DatanodeProtocolClientSideTranslatorPB. Do you think we can change that as well to DatanodeProtocol along with it ? (or) is it ok, as **TranslatorPBs are mainly delegating calls to actual proxies? > BackupNode stop can not close proxy connections because it is not a proxy > instance. > --- > > Key: HDFS-2768 > URL: https://issues.apache.org/jira/browse/HDFS-2768 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.24.0 >Reporter: Uma Maheswara Rao G >Assignee: Uma Maheswara Rao G > Attachments: HDFS-2768.patch > > > Observe this from BackupNode tests: > java.lang.IllegalArgumentException: not a proxy instance > at java.lang.reflect.Proxy.getInvocationHandler(Unknown Source) > at org.apache.hadoop.ipc.RPC.stopProxy(RPC.java:557) > at > org.apache.hadoop.hdfs.server.namenode.BackupNode.stop(BackupNode.java:194) > at > org.apache.hadoop.hdfs.server.namenode.TestBackupNode.testCheckpoint(TestBackupNode.java:355) > at > org.apache.hadoop.hdfs.server.namenode.TestBackupNode.testBackupNode(TestBackupNode.java:241) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2768) BackupNode stop can not close proxy connections because it is not a proxy instance.
[ https://issues.apache.org/jira/browse/HDFS-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185400#comment-13185400 ] Uma Maheswara Rao G commented on HDFS-2768: --- Thanks a lot Eli, for the review. Here NamenodeProtocolTranslatorPB are delegating the calls to it and actual proxy maintained in NamenodeProtocolTranslatorPB class. And also NamenodeProtocol is not a closeable. infact, the otherway could be to add the instanceOf closeable checks in close and keep the NamenodeProtocol as it is. > BackupNode stop can not close proxy connections because it is not a proxy > instance. > --- > > Key: HDFS-2768 > URL: https://issues.apache.org/jira/browse/HDFS-2768 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.24.0 >Reporter: Uma Maheswara Rao G >Assignee: Uma Maheswara Rao G > Attachments: HDFS-2768.patch > > > Observe this from BackupNode tests: > java.lang.IllegalArgumentException: not a proxy instance > at java.lang.reflect.Proxy.getInvocationHandler(Unknown Source) > at org.apache.hadoop.ipc.RPC.stopProxy(RPC.java:557) > at > org.apache.hadoop.hdfs.server.namenode.BackupNode.stop(BackupNode.java:194) > at > org.apache.hadoop.hdfs.server.namenode.TestBackupNode.testCheckpoint(TestBackupNode.java:355) > at > org.apache.hadoop.hdfs.server.namenode.TestBackupNode.testBackupNode(TestBackupNode.java:241) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-2787) HDFS build failing in 0.22
[ https://issues.apache.org/jira/browse/HDFS-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HDFS-2787: - Summary: HDFS build failing in 0.22 (was: HDFS build failing) Revised the summary. > HDFS build failing in 0.22 > -- > > Key: HDFS-2787 > URL: https://issues.apache.org/jira/browse/HDFS-2787 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.22.0 > Environment: Ubuntu 11.04 / Ant 1.8.1 >Reporter: Plamen Jeliazkov > > On a fresh install of Hadoop 0.22.0, I can get common to build fine, but when > I try to run "ant eclipse" or "ant jar" on hdfs I get this: > [ivy:resolve] > http://repo1.maven.org/maven2/org/apache/hadoop/hadoop-common/0.22.0-SNAPSHOT/hadoop-common-0.22.0-SNAPSHOT.jar > [ivy:resolve] :: > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > [ivy:resolve] :: > [ivy:resolve] :: > org.apache.hadoop#hadoop-common;0.22.0-SNAPSHOT: not found > [ivy:resolve] :: > [ivy:resolve] > [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS > BUILD FAILED > /home/hadoop/Desktop/hadoop-0.22.0/hdfs/build.xml:1814: impossible to resolve > dependencies: > resolve failed - see output for details > From my own investigation of the repo, I can see there is no > "0.22.0-SNAPSHOT" folder, > there is instead a "0.22.0" folder, and inside of it there is > hadoop-common-0.22.0.jar (without the -SNAPSHOT). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2782) HA: Support multiple shared edits dirs
[ https://issues.apache.org/jira/browse/HDFS-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185359#comment-13185359 ] Sanjay Radia commented on HDFS-2782: 2 questions: - If you have multiple dirs within the same NFS server, are you expecting them to fail independently? - For multiple NFS servers, will the standby be expected to read from any/all of them? > HA: Support multiple shared edits dirs > -- > > Key: HDFS-2782 > URL: https://issues.apache.org/jira/browse/HDFS-2782 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha >Affects Versions: HA branch (HDFS-1623) >Reporter: Eli Collins >Assignee: Eli Collins > > Supporting multiple shared dirs will improve availability (eg see HDFS-2769). > You may want to use multiple shared dirs on a single filer (eg for better > fault isolation) or because you want to use multiple filers/mounts. Per > HDFS-2752 (and HDFS-2735) we need to do things like use the JournalSet in > EditLogTailer and add tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2681) Add ZK client for leader election
[ https://issues.apache.org/jira/browse/HDFS-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185358#comment-13185358 ] Suresh Srinivas commented on HDFS-2681: --- Some comments for the first version of the patch: # General - How is multithreaded use for this library handled? # ActiveStandbyElector #* Add javadoc to the class on how to use the class. Also callback interface can be described in more detail on when the call back is made and perhaps some description of what is expected of the app. notifyError() particularly needs better documentation on when to expect this callback. #* Please document the enumerations. #* Constructor should check for null - at least for call back passed. Otherwise you will get null pointer exception. #* joinElection() you may want to copy the byte[] data passed or at least document that the data[] must not be changed by the caller. #* #getNewZooKeeper() seems unnecessary and can be removed. Creation of ZooKeeper() can be moved to createConnection() it self. #* Make member variable that are initialized only once in the constructor final. #* activeData could be better name for appData. #* Please check if all the params are documented in methods. For example constructor is missing one of the params in the doc. Same is true with exceptions thrown. #* quitElection() should not check zkClient non null, as terminateConnection already checks it. #* getActiveData() - how about not throwing KeeperException? Also ActiveNotFoundException should wrap the exception caught from ZK. I have not complete the review. These are some prelimiary comments > Add ZK client for leader election > - > > Key: HDFS-2681 > URL: https://issues.apache.org/jira/browse/HDFS-2681 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha >Affects Versions: HA branch (HDFS-1623) >Reporter: Suresh Srinivas >Assignee: Bikas Saha > Fix For: HA branch (HDFS-1623) > > Attachments: HDFS-2681.HDFS-1623.patch, HDFS-2681.HDFS-1623.patch, > Zookeeper based Leader Election and Monitoring Library.pdf > > > ZKClient needs to support the following capabilities: > # Ability to create a znode for co-ordinating leader election. > # Ability to monitor and receive call backs when active znode status changes. > # Ability to get information about the active node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-2681) Add ZK client for leader election
[ https://issues.apache.org/jira/browse/HDFS-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bikas Saha updated HDFS-2681: - Attachment: HDFS-2681.HDFS-1623.patch New patch with inconsistent names fixed across comments and code. > Add ZK client for leader election > - > > Key: HDFS-2681 > URL: https://issues.apache.org/jira/browse/HDFS-2681 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha >Affects Versions: HA branch (HDFS-1623) >Reporter: Suresh Srinivas >Assignee: Bikas Saha > Fix For: HA branch (HDFS-1623) > > Attachments: HDFS-2681.HDFS-1623.patch, HDFS-2681.HDFS-1623.patch, > Zookeeper based Leader Election and Monitoring Library.pdf > > > ZKClient needs to support the following capabilities: > # Ability to create a znode for co-ordinating leader election. > # Ability to monitor and receive call backs when active znode status changes. > # Ability to get information about the active node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2681) Add ZK client for leader election
[ https://issues.apache.org/jira/browse/HDFS-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185312#comment-13185312 ] Bikas Saha commented on HDFS-2681: -- please ignore inconsistencies in comments while I fix them. > Add ZK client for leader election > - > > Key: HDFS-2681 > URL: https://issues.apache.org/jira/browse/HDFS-2681 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha >Affects Versions: HA branch (HDFS-1623) >Reporter: Suresh Srinivas >Assignee: Bikas Saha > Fix For: HA branch (HDFS-1623) > > Attachments: HDFS-2681.HDFS-1623.patch, Zookeeper based Leader > Election and Monitoring Library.pdf > > > ZKClient needs to support the following capabilities: > # Ability to create a znode for co-ordinating leader election. > # Ability to monitor and receive call backs when active znode status changes. > # Ability to get information about the active node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HDFS-2787) HDFS build failing
[ https://issues.apache.org/jira/browse/HDFS-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Plamen Jeliazkov resolved HDFS-2787. Resolution: Not A Problem Don't trust the release mirrors for 0.22.0. Download it straight from Jenkins or the branch. > HDFS build failing > -- > > Key: HDFS-2787 > URL: https://issues.apache.org/jira/browse/HDFS-2787 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 0.22.0 > Environment: Ubuntu 11.04 / Ant 1.8.1 >Reporter: Plamen Jeliazkov > > On a fresh install of Hadoop 0.22.0, I can get common to build fine, but when > I try to run "ant eclipse" or "ant jar" on hdfs I get this: > [ivy:resolve] > http://repo1.maven.org/maven2/org/apache/hadoop/hadoop-common/0.22.0-SNAPSHOT/hadoop-common-0.22.0-SNAPSHOT.jar > [ivy:resolve] :: > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > [ivy:resolve] :: > [ivy:resolve] :: > org.apache.hadoop#hadoop-common;0.22.0-SNAPSHOT: not found > [ivy:resolve] :: > [ivy:resolve] > [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS > BUILD FAILED > /home/hadoop/Desktop/hadoop-0.22.0/hdfs/build.xml:1814: impossible to resolve > dependencies: > resolve failed - see output for details > From my own investigation of the repo, I can see there is no > "0.22.0-SNAPSHOT" folder, > there is instead a "0.22.0" folder, and inside of it there is > hadoop-common-0.22.0.jar (without the -SNAPSHOT). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-2787) HDFS build failing
HDFS build failing -- Key: HDFS-2787 URL: https://issues.apache.org/jira/browse/HDFS-2787 Project: Hadoop HDFS Issue Type: Bug Affects Versions: 0.22.0 Environment: Ubuntu 11.04 / Ant 1.8.1 Reporter: Plamen Jeliazkov On a fresh install of Hadoop 0.22.0, I can get common to build fine, but when I try to run "ant eclipse" or "ant jar" on hdfs I get this: [ivy:resolve] http://repo1.maven.org/maven2/org/apache/hadoop/hadoop-common/0.22.0-SNAPSHOT/hadoop-common-0.22.0-SNAPSHOT.jar [ivy:resolve] :: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :: [ivy:resolve] :: org.apache.hadoop#hadoop-common;0.22.0-SNAPSHOT: not found [ivy:resolve] :: [ivy:resolve] [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS BUILD FAILED /home/hadoop/Desktop/hadoop-0.22.0/hdfs/build.xml:1814: impossible to resolve dependencies: resolve failed - see output for details >From my own investigation of the repo, I can see there is no "0.22.0-SNAPSHOT" >folder, there is instead a "0.22.0" folder, and inside of it there is hadoop-common-0.22.0.jar (without the -SNAPSHOT). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2777) When copying a file out of HDFS, modifying it, and uploading it back into HDFS, the put fails due to a CRC mismatch
[ https://issues.apache.org/jira/browse/HDFS-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185163#comment-13185163 ] Kihwal Lee commented on HDFS-2777: -- Actually ignoreCRC is for disabling checksum verification. CRC copying needs to be disabled by default when -crc is not specified. > When copying a file out of HDFS, modifying it, and uploading it back into > HDFS, the put fails due to a CRC mismatch > --- > > Key: HDFS-2777 > URL: https://issues.apache.org/jira/browse/HDFS-2777 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs client >Affects Versions: 0.23.1 > Environment: KR at Yahoo >Reporter: Kevin J. Price > > Performing an hdfs -get on a file, modifying the file, and using hdfs -put to > place the file back into HDFS results in a checksum error. It seems that the > problem is a .crc file being generated locally from the -get command even > though the -crc option was NOT specified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2777) When copying a file out of HDFS, modifying it, and uploading it back into HDFS, the put fails due to a CRC mismatch
[ https://issues.apache.org/jira/browse/HDFS-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185154#comment-13185154 ] Kihwal Lee commented on HDFS-2777: -- It is due to the change in the default behavior. FsShell for some reason now creates CRC files (..crc) in the local file system by default. Unaware of existence of the .filename.crc, users can modify files stored in the local file system and make the CRC invalid. The default behavior needs to be reverted back to ingnoreCrc. > When copying a file out of HDFS, modifying it, and uploading it back into > HDFS, the put fails due to a CRC mismatch > --- > > Key: HDFS-2777 > URL: https://issues.apache.org/jira/browse/HDFS-2777 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs client >Affects Versions: 0.23.1 > Environment: KR at Yahoo >Reporter: Kevin J. Price > > Performing an hdfs -get on a file, modifying the file, and using hdfs -put to > place the file back into HDFS results in a checksum error. It seems that the > problem is a .crc file being generated locally from the -get command even > though the -crc option was NOT specified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-2681) Add ZK client for leader election
[ https://issues.apache.org/jira/browse/HDFS-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bikas Saha updated HDFS-2681: - Attachment: HDFS-2681.HDFS-1623.patch Zookeeper based Leader Election and Monitoring Library.pdf Hi, I have submitted a short design document for this library and a patch that implements the functionality. Both are up for review and comments. Thanks > Add ZK client for leader election > - > > Key: HDFS-2681 > URL: https://issues.apache.org/jira/browse/HDFS-2681 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha >Affects Versions: HA branch (HDFS-1623) >Reporter: Suresh Srinivas >Assignee: Bikas Saha > Fix For: HA branch (HDFS-1623) > > Attachments: HDFS-2681.HDFS-1623.patch, Zookeeper based Leader > Election and Monitoring Library.pdf > > > ZKClient needs to support the following capabilities: > # Ability to create a znode for co-ordinating leader election. > # Ability to monitor and receive call backs when active znode status changes. > # Ability to get information about the active node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2742) HA: observed dataloss in replication stress test
[ https://issues.apache.org/jira/browse/HDFS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185133#comment-13185133 ] Hari Mankude commented on HDFS-2742: This is a good idea. It keeps the log stream separate from the datanode based block msgs. We would need to handle "lost" msgs. For example, primary might have received a block finalized msg and the same msg was not delivered to standby. So, the block rbw msg on the standby queue will have to be purged after a timeout. > HA: observed dataloss in replication stress test > > > Key: HDFS-2742 > URL: https://issues.apache.org/jira/browse/HDFS-2742 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node, ha, name-node >Affects Versions: HA branch (HDFS-1623) >Reporter: Todd Lipcon >Assignee: Todd Lipcon >Priority: Blocker > Attachments: hdfs-2742.txt, log-colorized.txt > > > The replication stress test case failed over the weekend since one of the > replicas went missing. Still diagnosing the issue, but it seems like the > chain of events was something like: > - a block report was generated on one of the nodes while the block was being > written - thus the block report listed the block as RBW > - when the standby replayed this queued message, it was replayed after the > file was marked complete. Thus it marked this replica as corrupt > - it asked the DN holding the corrupt replica to delete it. And, I think, > removed it from the block map at this time. > - That DN then did another block report before receiving the deletion. This > caused it to be re-added to the block map, since it was "FINALIZED" now. > - Replication was lowered on the file, and it counted the above replica as > non-corrupt, and asked for the other replicas to be deleted. > - All replicas were lost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2768) BackupNode stop can not close proxy connections because it is not a proxy instance.
[ https://issues.apache.org/jira/browse/HDFS-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185129#comment-13185129 ] Eli Collins commented on HDFS-2768: --- The type of backupNode and namenode should be NamenodeProtocol not NamenodeProtocolTranslatorPB right? Otherwise looks great. > BackupNode stop can not close proxy connections because it is not a proxy > instance. > --- > > Key: HDFS-2768 > URL: https://issues.apache.org/jira/browse/HDFS-2768 > Project: Hadoop HDFS > Issue Type: Bug > Components: name-node >Affects Versions: 0.24.0 >Reporter: Uma Maheswara Rao G >Assignee: Uma Maheswara Rao G > Attachments: HDFS-2768.patch > > > Observe this from BackupNode tests: > java.lang.IllegalArgumentException: not a proxy instance > at java.lang.reflect.Proxy.getInvocationHandler(Unknown Source) > at org.apache.hadoop.ipc.RPC.stopProxy(RPC.java:557) > at > org.apache.hadoop.hdfs.server.namenode.BackupNode.stop(BackupNode.java:194) > at > org.apache.hadoop.hdfs.server.namenode.TestBackupNode.testCheckpoint(TestBackupNode.java:355) > at > org.apache.hadoop.hdfs.server.namenode.TestBackupNode.testBackupNode(TestBackupNode.java:241) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2601) Proposal to store edits and checkpoints inside HDFS itself for namenode HA
[ https://issues.apache.org/jira/browse/HDFS-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185122#comment-13185122 ] Hari Mankude commented on HDFS-2601: Karthik, One of things that is not explicitly mentioned is whether edit log writes/checkpoints are written synchronously or asynchronously to HDFS. A synchronous write of edit log entries might have write latency issues as mentioned by Sanjay. Asynchronous writes are also acceptable and HDFS write latency issues are not very critical with async writes. The disadvantage of asynchronously writing edit log is that the edit log in HDFS will lag the actual log and could result in loss of data if HDFS based image has to be used. However, having more than one copy of fsimage/edit logs in HDFS improves the recoverability of HDFS immensely (without total loss of data) in case of catastrophic NN failures. In fact, storing multiple checkpoints with the associated edit logs also will help in rollback situations if there is metadata corruption at NN. > Proposal to store edits and checkpoints inside HDFS itself for namenode HA > -- > > Key: HDFS-2601 > URL: https://issues.apache.org/jira/browse/HDFS-2601 > Project: Hadoop HDFS > Issue Type: New Feature > Components: name-node >Reporter: Karthik Ranganathan > > Would have liked to make this a "brainstorming" JIRA but couldn't find the > option for some reason. > I have talked to a quite a few people about this proposal at Facebook > internally (HDFS folks like Hairong and Dhruba, as well as HBase folks > interested in this feature), and wanted to broaden the audience. > At the core of the HA feature, we need 2 things: > A. the secondary NN (or avatar stand-by or whatever we call it) needs to read > all the fsedits and fsimage data written by the primary NN > B. Once the stand-by has taken over, the old NN should not be allowed to make > any edits > The basic idea is as follows (there are some variants, we can hone in on the > details if we like the general approach): > 1. The write path for fsedits and fsimage: > 1.1 The NN uses a dfs client to write fsedits and fsimage. These will be > regular hdfs files written using the write pipeline. > 1.2 Let us say the fsimage and fsedits files are written to a well-known > location in the local HDFS itself (say /.META or some such location) > 1.3 The create files and add blocks to files in this path are not written to > fsimage or fsedits. The location of the blocks for the files in this location > are known to all namenodes - primary and standby - somehow (some > possibilities here - write these block ids to zk or use reserved block ids or > write some meta-data into the blocks itself and store the blocks in a well > known location on all the datanodes) > 1.4 If the replication factor on the write pipeline decreases, we close the > block immediately and allow NN to re-replicate to bring up the replication > factor. We continue writing to a new block > 2. The read path on a NN failure > 2.1 Since the new NN "knows" the location of the blocks for the fsedits and > fsimage (again the same possibilities as mentioned above), there is nothing > to do to determine this > 2.2 It can read the files it needs using the HDFS client itself > 3. Fencing - if a NN is unresponsive, a new NN takes over, old NN should not > be allowed to perform any action > 3.1 Use HDFS lease recovery for the fsedits and fsimage files - the new NN > will close all these files baing written to by the old NN (and hence all the > blocks) > 3.2 The new NN (avatar NN) will write its address into ZK to let everyone > know its the master > 3.3 The new NN now gets the lease for these files and starts writing into the > fsedits and fsimage > 3.4 The old NN cannot write into the file as the block it was writing to was > closed and it does not have the lease. If it needs to re-open these files, it > needs to check zk to see it is indeed the current master, if not it should > exit. > 4. Misc considerations: > 4.1 If needed, we can specify favored nodes to place the blocks for this data > in specific set of nodes (say we want to use a different set of RAIDed nodes, > etc). > 4.2 Since we wont record the entries for /.META in fsedits and fsimage, a > "hadoop dfs -ls /" command wont show the files. This is probably ok, and can > be fixed if not. > 4.3 If we have 256MB block sizes, then 20GB fsimage file would need 80 block > ids - the NN would need only these 80 block ids to read all the fsedits data. > The fsimage data is even lesser. This is very tractable using a variety of > the techniques (the possibilities mentioned above). > The advantage is that we are re-using the existing HDFS client (with some > enhancements of
[jira] [Commented] (HDFS-2742) HA: observed dataloss in replication stress test
[ https://issues.apache.org/jira/browse/HDFS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185118#comment-13185118 ] Suresh Srinivas commented on HDFS-2742: --- Here is an idea to handle this problem: On standby for rbw replicas, we do nothing and just put then in a queue when received in block report. At this point two things can happen: # Block received comes from datanode indicating finalization of block. We use this to just remove entry from rbw queue. # Block received never comes, then lease recovery has to handle it. We can use rbw to populate the block if it does not exist, before lease recovery. > HA: observed dataloss in replication stress test > > > Key: HDFS-2742 > URL: https://issues.apache.org/jira/browse/HDFS-2742 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node, ha, name-node >Affects Versions: HA branch (HDFS-1623) >Reporter: Todd Lipcon >Assignee: Todd Lipcon >Priority: Blocker > Attachments: hdfs-2742.txt, log-colorized.txt > > > The replication stress test case failed over the weekend since one of the > replicas went missing. Still diagnosing the issue, but it seems like the > chain of events was something like: > - a block report was generated on one of the nodes while the block was being > written - thus the block report listed the block as RBW > - when the standby replayed this queued message, it was replayed after the > file was marked complete. Thus it marked this replica as corrupt > - it asked the DN holding the corrupt replica to delete it. And, I think, > removed it from the block map at this time. > - That DN then did another block report before receiving the deletion. This > caused it to be re-added to the block map, since it was "FINALIZED" now. > - Replication was lowered on the file, and it counted the above replica as > non-corrupt, and asked for the other replicas to be deleted. > - All replicas were lost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2747) HA: entering safe mode after starting SBN can NPE
[
https://issues.apache.org/jira/browse/HDFS-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185076#comment-13185076
]
Todd Lipcon commented on HDFS-2747:
---
Ah, that makes sense. Good sleuthing. Planning to provide a patch?
> HA: entering safe mode after starting SBN can NPE
> -
>
> Key: HDFS-2747
> URL: https://issues.apache.org/jira/browse/HDFS-2747
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha
>Affects Versions: HA branch (HDFS-1623)
>Reporter: Eli Collins
>Assignee: Uma Maheswara Rao G
>
> Entering Safemode on the primary after while it's already in safemode after
> the SBN is started results in an NPE:
> {noformat}
> hadoop-0.24.0-SNAPSHOT $ ./bin/hdfs dfsadmin -safemode get
> Safe mode is ON
> hadoop-0.24.0-SNAPSHOT $ ./bin/hdfs dfsadmin -safemode enter
> safemode: java.lang.NullPointerException
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-2652) Port token service changes from 205
[ https://issues.apache.org/jira/browse/HDFS-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daryn Sharp updated HDFS-2652: -- Target Version/s: 0.24.0, 0.23.1 (was: 0.23.1, 0.24.0) Issue Type: Improvement (was: New Feature) > Port token service changes from 205 > --- > > Key: HDFS-2652 > URL: https://issues.apache.org/jira/browse/HDFS-2652 > Project: Hadoop HDFS > Issue Type: Improvement >Affects Versions: 0.24.0, 0.23.1 >Reporter: Daryn Sharp >Assignee: Daryn Sharp > > Need to merge the 205 token bug fixes and the feature to enable > hostname-based tokens. See jiras linked to HADOOP-7808 for more details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-2786) Fix host-based token incompatibilities in DFSUtil
Fix host-based token incompatibilities in DFSUtil - Key: HDFS-2786 URL: https://issues.apache.org/jira/browse/HDFS-2786 Project: Hadoop HDFS Issue Type: Sub-task Components: name-node, security Affects Versions: 0.24.0, 0.23.1 Reporter: Daryn Sharp DFSUtil introduces new static methods that duplicate functionality in NetUtils. These new methods lack the logic necessary for host-based tokens to work. After speaking with Suresh, the approach being taken is: * DFSUtil.getSocketAddress will be removed. Callers will be reverted to using the NetUtils version. * DFSUtil.getDFSClient will changed to take accept a uri/host:port string instead of an InetSocketAddress. The method will internal call NetUtils.createSocketAddr. This alleviates the callers from being required to call NetUtils.createSocketAddr and reduce the opportunity for error that will break host-based tokens. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-2785) Update webhdfs and httpfs for host-based token support
Update webhdfs and httpfs for host-based token support -- Key: HDFS-2785 URL: https://issues.apache.org/jira/browse/HDFS-2785 Project: Hadoop HDFS Issue Type: Sub-task Components: name-node, security Affects Versions: 0.24.0, 0.23.1 Reporter: Daryn Sharp Assignee: Robert Joseph Evans Need to port 205 tokens into these filesystems. Will mainly involve ensuring code duplicated from hftp is updated accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HDFS-2784) Update hftp and hdfs for host-based token support
Update hftp and hdfs for host-based token support - Key: HDFS-2784 URL: https://issues.apache.org/jira/browse/HDFS-2784 Project: Hadoop HDFS Issue Type: Sub-task Components: hdfs client, name-node, security Affects Versions: 0.24.0, 0.23.1 Reporter: Daryn Sharp Assignee: Kihwal Lee Need to port 205 token changes and update any new related code dealing with tokens in these filesystems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HDFS-2754) HA: enable dfs.namenode.name.dir.restore if HA is enabled
[ https://issues.apache.org/jira/browse/HDFS-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswara Rao G reassigned HDFS-2754: - Assignee: Uma Maheswara Rao G > HA: enable dfs.namenode.name.dir.restore if HA is enabled > - > > Key: HDFS-2754 > URL: https://issues.apache.org/jira/browse/HDFS-2754 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ha, name-node >Affects Versions: HA branch (HDFS-1623) >Reporter: Eli Collins >Assignee: Uma Maheswara Rao G > > If HA is enabled it seems like we should always try to restore failed name > dirs. Let's auto-enable name dir restoration if HA is enabled, at least for > shared edits dirs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2747) HA: entering safe mode after starting SBN can NPE
[
https://issues.apache.org/jira/browse/HDFS-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185016#comment-13185016
]
Uma Maheswara Rao G commented on HDFS-2747:
---
Here the reason for NullPoniterException is, initially when we are entering
into safemode, editLogStream will be null in FSEditlog because there is no log
segment started yet.
The reason for success of second time safemode entering is, The same synctxtid
already visited once with previous safemode trail. So it will assume that this
transaction was already flushed and will return. There won't be any exception
in logSyncAll call and will enter into safemode successfully again.
java.lang.NullPointerException
at
org.apache.hadoop.hdfs.server.namenode.FSEditLog.logSync(FSEditLog.java:524)
at
org.apache.hadoop.hdfs.server.namenode.FSEditLog.logSyncAll(FSEditLog.java:450)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.enterSafeMode(FSNamesystem.java:3780)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.setSafeMode(FSNamesystem.java:3648)
at
org.apache.hadoop.hdfs.server.namenode.FSImageTestUtil.enterSafemode(FSImageTestUtil.java:510)
> HA: entering safe mode after starting SBN can NPE
> -
>
> Key: HDFS-2747
> URL: https://issues.apache.org/jira/browse/HDFS-2747
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha
>Affects Versions: HA branch (HDFS-1623)
>Reporter: Eli Collins
>Assignee: Uma Maheswara Rao G
>
> Entering Safemode on the primary after while it's already in safemode after
> the SBN is started results in an NPE:
> {noformat}
> hadoop-0.24.0-SNAPSHOT $ ./bin/hdfs dfsadmin -safemode get
> Safe mode is ON
> hadoop-0.24.0-SNAPSHOT $ ./bin/hdfs dfsadmin -safemode enter
> safemode: java.lang.NullPointerException
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-69) Improve dfsadmin command line help
[ https://issues.apache.org/jira/browse/HDFS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184940#comment-13184940 ] Hudson commented on HDFS-69: Integrated in Hadoop-Mapreduce-trunk #956 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/956/]) HDFS-69. Improve the 'dfsadmin' commandline help. (harsh) harsh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1230398 Files : * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/tools/DFSAdmin.java > Improve dfsadmin command line help > --- > > Key: HDFS-69 > URL: https://issues.apache.org/jira/browse/HDFS-69 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Ravi Phulari >Assignee: Harsh J >Priority: Minor > Fix For: 0.23.1 > > Attachments: HDFS-69.patch > > > Enhance dfsadmin command line help informing "A quota of one forces a > directory to remain empty" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-69) Improve dfsadmin command line help
[ https://issues.apache.org/jira/browse/HDFS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184930#comment-13184930 ] Hudson commented on HDFS-69: Integrated in Hadoop-Mapreduce-0.23-Build #158 (See [https://builds.apache.org/job/Hadoop-Mapreduce-0.23-Build/158/]) merge HDFS-69 (harsh) harsh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1230414 Files : * /hadoop/common/branches/branch-0.23 * /hadoop/common/branches/branch-0.23/hadoop-common-project * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-auth * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/CHANGES.txt * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/src/main/docs * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/src/main/java * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/src/test/core * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/java * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/tools/DFSAdmin.java * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/native * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/webapps/datanode * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/webapps/hdfs * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/webapps/secondary * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/test/hdfs * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/.gitignore * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/bin * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/conf * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-examples * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-site * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-site/src/site/apt * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/c++ * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/block_forensics * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/build-contrib.xml * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/build.xml * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/data_join * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/eclipse-plugin * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/index * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/vaidya * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/examples * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/fs * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/hdfs * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/io/FileBench.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/io/TestSequenceFileMergeProgress.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/ipc * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/security/authorize/TestServiceLevelAuthorization.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/test/MapredTestDriver.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/webapps/job * /hadoop/common/branches/branch-0.23/hadoop-project * /hadoop/common/branches/branch-0.23/hadoop-project/src/site > Improve dfsadmin command line help > --- > > Key: HDFS-69 > URL: https://issues.apache.org/jira/browse/HDFS-69 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 1.0.0 >Rep
[jira] [Commented] (HDFS-69) Improve dfsadmin command line help
[ https://issues.apache.org/jira/browse/HDFS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184907#comment-13184907 ] Hudson commented on HDFS-69: Integrated in Hadoop-Hdfs-0.23-Build #136 (See [https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/136/]) merge HDFS-69 (harsh) harsh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1230414 Files : * /hadoop/common/branches/branch-0.23 * /hadoop/common/branches/branch-0.23/hadoop-common-project * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-auth * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/CHANGES.txt * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/src/main/docs * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/src/main/java * /hadoop/common/branches/branch-0.23/hadoop-common-project/hadoop-common/src/test/core * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/java * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/tools/DFSAdmin.java * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/native * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/webapps/datanode * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/webapps/hdfs * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/webapps/secondary * /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/test/hdfs * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/.gitignore * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/bin * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/conf * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-examples * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-site * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-site/src/site/apt * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/c++ * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/block_forensics * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/build-contrib.xml * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/build.xml * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/data_join * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/eclipse-plugin * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/index * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/contrib/vaidya * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/examples * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/fs * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/hdfs * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/io/FileBench.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/io/TestSequenceFileMergeProgress.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/ipc * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/security/authorize/TestServiceLevelAuthorization.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/test/mapred/org/apache/hadoop/test/MapredTestDriver.java * /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/src/webapps/job * /hadoop/common/branches/branch-0.23/hadoop-project * /hadoop/common/branches/branch-0.23/hadoop-project/src/site > Improve dfsadmin command line help > --- > > Key: HDFS-69 > URL: https://issues.apache.org/jira/browse/HDFS-69 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Rav
[jira] [Commented] (HDFS-69) Improve dfsadmin command line help
[ https://issues.apache.org/jira/browse/HDFS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184894#comment-13184894 ] Hudson commented on HDFS-69: Integrated in Hadoop-Hdfs-trunk #923 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/923/]) HDFS-69. Improve the 'dfsadmin' commandline help. (harsh) harsh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1230398 Files : * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/tools/DFSAdmin.java > Improve dfsadmin command line help > --- > > Key: HDFS-69 > URL: https://issues.apache.org/jira/browse/HDFS-69 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Ravi Phulari >Assignee: Harsh J >Priority: Minor > Fix For: 0.23.1 > > Attachments: HDFS-69.patch > > > Enhance dfsadmin command line help informing "A quota of one forces a > directory to remain empty" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
