hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3900) QJM: avoid validating log segments on log rolls
Date Fri, 07 Sep 2012 20:46:07 GMT

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

Aaron T. Myers commented on HDFS-3900:

Patch looks pretty good to me, and I really like the curSegmentTxId cleanup.

One question: note that the refactor into the abortCurSegment() method also causes the code
in newEpoch to now call "curSegment.abort()" instead of "curSegment.close()". Is there any
semantic change there that we should be concerned about?

+1 once this question is answered.
> QJM: avoid validating log segments on log rolls
> -----------------------------------------------
>                 Key: HDFS-3900
>                 URL: https://issues.apache.org/jira/browse/HDFS-3900
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>    Affects Versions: QuorumJournalManager (HDFS-3077)
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>         Attachments: hdfs-3900.txt
> Currently, we are paranoid and validate every log segment when it is finalized. For the
a log segment that has been written entirely by one writer, with no recovery in between, this
is overly paranoid (we don't do this for local journals). It also causes log rolls to be slow
and take time linear in the size of the segment. Instead, we should optimize this path to
simply trust that the segment is correct so long as the txids match up as expected.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message