You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Brahma Reddy Battula (JIRA)" <ji...@apache.org> on 2012/07/02 10:53:45 UTC
[jira] [Created] (HDFS-3585) Blocks are getting marked as corrupt
when commitblocksyncronization(Since recovery called by another client) is
success before BR send
Brahma Reddy Battula created HDFS-3585:
------------------------------------------
Summary: Blocks are getting marked as corrupt when commitblocksyncronization(Since recovery called by another client) is success before BR send
Key: HDFS-3585
URL: https://issues.apache.org/jira/browse/HDFS-3585
Project: Hadoop HDFS
Issue Type: Bug
Components: name-node
Affects Versions: 2.0.1-alpha, 3.0.0
Reporter: Brahma Reddy Battula
Scenario:
===========
Writing files without close
renaming file
deleting files with four DN's and replication factor=3
--
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-3585) Blocks are getting marked as corrupt
when commitblocksyncronization(Since recovery called by another client) is
success before BR send
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon reassigned HDFS-3585:
---------------------------------
Assignee: Todd Lipcon
> Blocks are getting marked as corrupt when commitblocksyncronization(Since recovery called by another client) is success before BR send
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-3585
> URL: https://issues.apache.org/jira/browse/HDFS-3585
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.1-alpha, 3.0.0
> Reporter: Brahma Reddy Battula
> Assignee: Todd Lipcon
>
> Scenario:
> ===========
> Writing files without close
> renaming file
> deleting files with four DN's and replication factor=3
--
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-3585) Blocks are getting marked as corrupt
when commitblocksyncronization(Since recovery called by another client) is
success before BR send
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405167#comment-13405167 ]
Todd Lipcon commented on HDFS-3585:
-----------------------------------
If I follow correctly, you're saying that the BR contains the block with GS=1002, but the NN has already seen the synchronization at GS=1003, so it marks blk_1002 as corrupt.
Shoudln't this be OK? i.e the NN will then issue deletion of the replica with GS=1002, the DN will ignore it because the GS doesn't match, and the corrupt block entry will go away?
> Blocks are getting marked as corrupt when commitblocksyncronization(Since recovery called by another client) is success before BR send
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-3585
> URL: https://issues.apache.org/jira/browse/HDFS-3585
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.1-alpha, 3.0.0
> Reporter: Brahma Reddy Battula
> Assignee: Todd Lipcon
>
> Scenario:
> ===========
> Writing files without close
> renaming file
> deleting files with four DN's and replication factor=3
--
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-3585) Blocks are getting marked as corrupt
when commitblocksyncronization(Since recovery called by another client) is
success before BR send
Posted by "Uma Maheswara Rao G (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405291#comment-13405291 ]
Uma Maheswara Rao G commented on HDFS-3585:
-------------------------------------------
Todd, If this situation happened for all blocks( for replication), then we will not invalidate that corrupt blocks right? If we have enough replication then only we will go for invalidation.
> Blocks are getting marked as corrupt when commitblocksyncronization(Since recovery called by another client) is success before BR send
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-3585
> URL: https://issues.apache.org/jira/browse/HDFS-3585
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.1-alpha, 3.0.0
> Reporter: Brahma Reddy Battula
>
> Scenario:
> ===========
> Writing files without close
> renaming file
> deleting files with four DN's and replication factor=3
--
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-3585) Blocks are getting marked as corrupt
when commitblocksyncronization(Since recovery called by another client) is
success before BR send
Posted by "amith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405055#comment-13405055 ]
amith commented on HDFS-3585:
-----------------------------
In the mentioned scenario
consider we a have block of GS 1002 and its reported to NN
Now DN has completed the recovery which should have bumped GS to 1003 and commitBlockSync successfully executed
Next the old block report is processed then there is a mismatch in the GS and reported ...!
SO the block is marked as corrupt :(
> Blocks are getting marked as corrupt when commitblocksyncronization(Since recovery called by another client) is success before BR send
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-3585
> URL: https://issues.apache.org/jira/browse/HDFS-3585
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.1-alpha, 3.0.0
> Reporter: Brahma Reddy Battula
>
> Scenario:
> ===========
> Writing files without close
> renaming file
> deleting files with four DN's and replication factor=3
--
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-3585) Blocks are getting marked as corrupt
when commitblocksyncronization(Since recovery called by another client) is
success before BR send
Posted by "amith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404992#comment-13404992 ]
amith commented on HDFS-3585:
-----------------------------
Here the scenario is
1. Create 2 clients
2. write a file using the client 1
3. trigger a BR
4. trigger lease recovery from the client 2
5. let client 2 complete its recovery in DN and let commitBlockSync complete
6. Now allow the old BR to process which is triggered @ 3
7. The block is marked as corrupt in this scenario
> Blocks are getting marked as corrupt when commitblocksyncronization(Since recovery called by another client) is success before BR send
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-3585
> URL: https://issues.apache.org/jira/browse/HDFS-3585
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.1-alpha, 3.0.0
> Reporter: Brahma Reddy Battula
>
> Scenario:
> ===========
> Writing files without close
> renaming file
> deleting files with four DN's and replication factor=3
--
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-3585) Blocks are getting marked as corrupt
when commitblocksyncronization(Since recovery called by another client) is
success before BR send
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon reassigned HDFS-3585:
---------------------------------
Assignee: (was: Todd Lipcon)
(oops, I didn't mean to assign this... just meant to comment)
> Blocks are getting marked as corrupt when commitblocksyncronization(Since recovery called by another client) is success before BR send
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-3585
> URL: https://issues.apache.org/jira/browse/HDFS-3585
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.1-alpha, 3.0.0
> Reporter: Brahma Reddy Battula
>
> Scenario:
> ===========
> Writing files without close
> renaming file
> deleting files with four DN's and replication factor=3
--
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