[
https://issues.apache.org/jira/browse/HDFS-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082172#comment-16082172
]
Vinayakumar B commented on HDFS-12120:
--------------------------------------
Idea is :
1. On RU-prepare command, NameNode can track the pre-RU blockId and genstamp.
2. For all append requests, where last block is pre-RU, force the client to
write to new block (as variable length block feature is already available).
--> Here, instead of making last block to UNDERCONSTRUCTION, regardless of
client's flag of NEW_BLOCK, return null for last block and exclude from
validation of previousBlock in addBlock() call for this specific case.
So in this way, pre-RU block will be same in state and length.
Hi [~kihwal], whether this sounds okay to you ?
> Use new block for pre-RollingUpgrade files` append requests
> -----------------------------------------------------------
>
> Key: HDFS-12120
> URL: https://issues.apache.org/jira/browse/HDFS-12120
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Vinayakumar B
>
> After the RollingUpgrade prepare, append on pre-RU files will re-open the
> same last block and makes changes to it (appending extra data, changing
> genstamp etc).
> These changes to the block will not be tracked in Datanodes (either in trash
> or via hardlinks)
> This creates problem if RollingUpgrade.Rollback is called.
> Since block state and size both changed, after rollback block will be marked
> corrupted.
> To avoid this, first time append on pre-RU files can be forced to write to
> new block itself.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
