[
https://issues.apache.org/jira/browse/HDFS-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170534#comment-13170534
]
Todd Lipcon commented on HDFS-2602:
-----------------------------------
- can updateBlocks take the INodeFile object itself, rather than the path? In
both cases, we already have the INodeFile object, so the lookup is redundant
- in updateBlocks, in the case that the last block in the file is updating its
generation stamp, don't you need to call
{{oldBlock.setGenerationStamp(newBlock.getGenerationStamp()}}? Does append work
correctly cross restart?
- style nit: {{i++}} instead of {{i ++}} in the "adding blocks" case
> NN should log newly-allocated blocks without losing BlockInfo
> -------------------------------------------------------------
>
> Key: HDFS-2602
> URL: https://issues.apache.org/jira/browse/HDFS-2602
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha
> Affects Versions: HA branch (HDFS-1623)
> Reporter: Todd Lipcon
> Assignee: Aaron T. Myers
> Priority: Critical
> Attachments: HDFS-2602.patch, HDFS-2602.patch, HDFS-2602.patch
>
>
> Without the patch in HDFS-1108, new block allocations aren't logged to the
> edits log. For HA, we'll need that functionality and we'll need to make sure
> that block locations aren't blown away in the Standby NN when tailing the
> edits log.
> As described in HDFS-1975:
> When we close a file, or add another block to a file, we write OP_CLOSE or
> OP_ADD in the txn log. FSEditLogLoader, when it sees these types of
> transactions, creates new BlockInfo objects for all of the blocks listed in
> the transaction. These new BlockInfos have no block locations associated. So,
> when we close a file, the SBNN loses its block locations info for that file
> and is no longer "hot".
> I have an ugly hack which copies over the old BlockInfos from the existing
> INode, but I'm not convinced it's the right way. It might be cleaner to add
> new opcode types like OP_ADD_ADDITIONAL_BLOCK, and actually treat OP_CLOSE as
> just a finalization of INodeFileUnderConstruction to INodeFile, rather than
> replacing block info at all.
--
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
