hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhe Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-9533) seen_txid in the shared edits directory is modified during bootstrapping
Date Mon, 08 Feb 2016 22:21:39 GMT

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

Zhe Zhang commented on HDFS-9533:

[~kihwal] / [~daryn] Thanks for reporting and fixing the issue.

I wonder what's the symptom of the bug. Was it just a wrong {{seen_id}} file or was it causing
other issues like crash or corruption?

I agree that the standby should not touch shared edit dir at all. But more fundamentally,
why does it even write a new {{seen_id}} to the image dir? Before the change, we are always
updating the {{seen_id}} in all NNStorage dirs consistently. Could there be an issue if the
image and edit dirs have different {{seen_id}}'s?

> seen_txid in the shared edits directory is modified during bootstrapping
> ------------------------------------------------------------------------
>                 Key: HDFS-9533
>                 URL: https://issues.apache.org/jira/browse/HDFS-9533
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: ha, namenode
>    Affects Versions: 2.6.0
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>             Fix For: 3.0.0, 2.7.3
>         Attachments: HDFS-9533.patch
> The last known transaction id is stored in the seen_txid file of all known directories
of a NNStorage when starting a new edit segment. However, we have seen a case where it contains
an id that falls in the middle of an edit segment. This was the seen_txid file in the sahred
edits directory.  The active namenode's local storage was containing valid looking seen_txid.

This message was sent by Atlassian JIRA

View raw message