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

Konstantin Shvachko commented on HDFS-9516:
-------------------------------------------

+1 on the latest patch.
The Jenkins report is quite confusing. Don't know if there is any value in 
running it. Still
- No new tests, because existing tests should fail due to the new assert 
statement.
- checkstyle issues seems to be the same 123
- Failed tests are reported incorrectly in the jira. Ran 8 failed tests 
locally, no problems.
- No new files in the patch, so ASF warnings are not related.

Will commit shortly.
Also should we target it for any of the upcoming releases? Seems like a 
critical bug.

> truncate file fails with data dirs on multiple disks
> ----------------------------------------------------
>
>                 Key: HDFS-9516
>                 URL: https://issues.apache.org/jira/browse/HDFS-9516
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode
>    Affects Versions: 2.7.1
>            Reporter: Bogdan Raducanu
>            Assignee: Plamen Jeliazkov
>         Attachments: HDFS-9516_1.patch, HDFS-9516_2.patch, HDFS-9516_3.patch, 
> HDFS-9516_testFailures.patch, Main.java, truncate.dn.log
>
>
> FileSystem.truncate returns false (no exception) but the file is never closed 
> and not writable after this.
> It seems to be because of copy on truncate which is used because the system 
> is in upgrade state. In this case a rename between devices is attempted.
> See attached log and repro code.
> Probably also affects truncate snapshotted file when copy on truncate is also 
> used.
> Possibly it affects not only truncate but any block recovery.
> I think the problem is in updateReplicaUnderRecovery
> {code}
> ReplicaBeingWritten newReplicaInfo = new ReplicaBeingWritten(
>             newBlockId, recoveryId, rur.getVolume(), 
> blockFile.getParentFile(),
>             newlength);
> {code}
> blockFile is created with copyReplicaWithNewBlockIdAndGS which is allowed to 
> choose any volume so rur.getVolume() is not where the block is located.
>  



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

Reply via email to