hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6038) JournalNode hardcodes NameNodeLayoutVersion in the edit log file
Date Tue, 04 Mar 2014 01:47:25 GMT

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

Jing Zhao commented on HDFS-6038:
---------------------------------

One issue with the current patch is that the JN will also check the layoutversion locally
while serving read requests. Let me see if we can bypass this check in JN.

> JournalNode hardcodes NameNodeLayoutVersion in the edit log file
> ----------------------------------------------------------------
>
>                 Key: HDFS-6038
>                 URL: https://issues.apache.org/jira/browse/HDFS-6038
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: datanode, ha, hdfs-client, namenode
>            Reporter: Haohui Mai
>            Assignee: Jing Zhao
>         Attachments: HDFS-6038.000.patch, HDFS-6038.001.patch
>
>
> In HA setup, the JNs receive edit logs (blob) from the NN and write into edit log files.
In order to write well-formed edit log files, the JNs prepend a header for each edit log file.
> The problem is that the JN hard-codes the version (i.e., {{NameNodeLayoutVersion}} in
the edit log, therefore it generates incorrect edit logs when the newer release bumps the
{{NameNodeLayoutVersion}} during rolling upgrade.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message