[jira] [Commented] (HDFS-9676) “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.

2016-01-22 Thread DuRuiling (JIRA)

[ 
https://issues.apache.org/jira/browse/HDFS-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112229#comment-15112229
 ] 

DuRuiling commented on HDFS-9676:
-

Ok, the previous namenode logs has been flushed and I will check it at the next 
backup, I would like to be able to find the relevant error log information. 
thanks

> “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.
> --
>
> Key: HDFS-9676
> URL: https://issues.apache.org/jira/browse/HDFS-9676
> Project: Hadoop HDFS
>  Issue Type: Bug
>  Components: auto-failover, datanode, hdfs-client
>Affects Versions: 2.5.0
> Environment: Linux version 3.0.101
> 2 namenode, 54 datanode
>Reporter: DuRuiling
>Assignee: DuRuiling
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> I find the bug when I backup about 240T data from local file system to HDFS, 
> I use command “hdfs dfs -D dfs.replication=3 -put $localPath $hdfsPath” to 
> backup each file one by one, the return value of this command is 0, then 
> illustrate the command execute right, I find file path is right, but the size 
> of $hdfsPath is 0 and the size of $loaclPath is non-zero. I reproduce the bug 
> when I backup data again.
> I write a bash shell to backup all data, according to the $? of the command 
> to judge the file is backup success and record a detailed log.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HDFS-9676) “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.

2016-01-21 Thread Vinayakumar B (JIRA)

[ 
https://issues.apache.org/jira/browse/HDFS-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111009#comment-15111009
 ] 

Vinayakumar B commented on HDFS-9676:
-

Hi [~drlhome], Can you please give some more details.. like logs, etc.

> “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.
> --
>
> Key: HDFS-9676
> URL: https://issues.apache.org/jira/browse/HDFS-9676
> Project: Hadoop HDFS
>  Issue Type: Bug
>  Components: auto-failover, datanode, hdfs-client
>Affects Versions: 2.5.0
> Environment: Linux version 3.0.101
> 2 namenode, 54 datanode
>Reporter: DuRuiling
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> I find the bug when I backup about 240T data from local file system to HDFS, 
> I use command “hdfs dfs -D dfs.replication=3 -put $localPath $hdfsPath” to 
> backup each file one by one, the return value of this command is 0, then 
> illustrate the command execute right, I find file path is right, but the size 
> of $hdfsPath is 0 and the size of $loaclPath is non-zero. I reproduce the bug 
> when I backup data again.
> I write a bash shell to backup all data, according to the $? of the command 
> to judge the file is backup success and record a detailed log.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HDFS-9676) “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.

2016-01-21 Thread DuRuiling (JIRA)

[ 
https://issues.apache.org/jira/browse/HDFS-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111820#comment-15111820
 ] 

DuRuiling commented on HDFS-9676:
-

Ok, I execute command “hdfs dfs -D dfs.replication=3 -put $localPath $hdfsPath 
>> $logfile 2>&1”to catch possible error. I checked $logfile when I found 
$hdfsPath is empty, but I found nothing. I think the return value of the 
command has already shown that the command is executed successfully, actually 
it's failed.

> “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.
> --
>
> Key: HDFS-9676
> URL: https://issues.apache.org/jira/browse/HDFS-9676
> Project: Hadoop HDFS
>  Issue Type: Bug
>  Components: auto-failover, datanode, hdfs-client
>Affects Versions: 2.5.0
> Environment: Linux version 3.0.101
> 2 namenode, 54 datanode
>Reporter: DuRuiling
>Assignee: DuRuiling
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> I find the bug when I backup about 240T data from local file system to HDFS, 
> I use command “hdfs dfs -D dfs.replication=3 -put $localPath $hdfsPath” to 
> backup each file one by one, the return value of this command is 0, then 
> illustrate the command execute right, I find file path is right, but the size 
> of $hdfsPath is 0 and the size of $loaclPath is non-zero. I reproduce the bug 
> when I backup data again.
> I write a bash shell to backup all data, according to the $? of the command 
> to judge the file is backup success and record a detailed log.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HDFS-9676) “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.

2016-01-21 Thread Vinayakumar B (JIRA)

[ 
https://issues.apache.org/jira/browse/HDFS-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15111958#comment-15111958
 ] 

Vinayakumar B commented on HDFS-9676:
-

Can you check namenode logs?

> “hdfs dfs -put”,the return value is 0, but the size of $hdfsPath is 0.
> --
>
> Key: HDFS-9676
> URL: https://issues.apache.org/jira/browse/HDFS-9676
> Project: Hadoop HDFS
>  Issue Type: Bug
>  Components: auto-failover, datanode, hdfs-client
>Affects Versions: 2.5.0
> Environment: Linux version 3.0.101
> 2 namenode, 54 datanode
>Reporter: DuRuiling
>Assignee: DuRuiling
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> I find the bug when I backup about 240T data from local file system to HDFS, 
> I use command “hdfs dfs -D dfs.replication=3 -put $localPath $hdfsPath” to 
> backup each file one by one, the return value of this command is 0, then 
> illustrate the command execute right, I find file path is right, but the size 
> of $hdfsPath is 0 and the size of $loaclPath is non-zero. I reproduce the bug 
> when I backup data again.
> I write a bash shell to backup all data, according to the $? of the command 
> to judge the file is backup success and record a detailed log.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)