[
https://issues.apache.org/jira/browse/HDFS-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170108#comment-13170108
]
Todd Lipcon commented on HDFS-2602:
-----------------------------------
bq. I just don't understand why this block persisting issue keeps migrating
from HDFS-978 to HDFS-1108 and now here? Are you seriously measuring
performance in # of jiras (or lines of code).
Funny :)
Dhruba opened both HDFS-978 and HDFS-1108, not sure why. It ended up migrating
here because at first we considered it separate, and were building this patch
on top of HDFS-1108. Then by the time the patch was done it seemed to make more
sense to integrate them. Would be reasonable to commit them separately, though
- 1108 for the logging and this one for the FSEditLog changes to avoid losing
the block locations. Would you prefer that or can we just commit this as is
once it's reviewed?
> Standby needs to maintain BlockInfo while following edits
> ---------------------------------------------------------
>
> 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
>
>
> 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
