Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Fri, 1 Aug 2014 01:54:39 +0000 (UTC)
From: "James Thomas (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12730653.1406676551886.92072.1406858079081@arcas>
In-Reply-To: <JIRA.12730653.1406676551886@arcas>
References: <JIRA.12730653.1406676551886@arcas>
Subject: [jira] [Updated] (HDFS-6777) Supporting consistent edit log reads
 when in-progress edit log segments are included
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HDFS-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Thomas updated HDFS-6777:
-------------------------------

    Status: Patch Available  (was: Open)

> Supporting consistent edit log reads when in-progress edit log segments are included
> ------------------------------------------------------------------------------------
>
>                 Key: HDFS-6777
>                 URL: https://issues.apache.org/jira/browse/HDFS-6777
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: qjm
>            Reporter: James Thomas
>            Assignee: James Thomas
>         Attachments: 6777-design.pdf, HDFS-6777.patch
>
>
> For inotify, we want to be able to read transactions from in-progress edit log segments so we can serve transactions to listeners soon after they are committed. This JIRA works toward ensuring that we do not send unsync'ed transactions back to the client by 1) discarding in-progress segments if we have a finalized segment starting at the same transaction ID and 2) if there are no finalized segments at the same transaction ID, using only the in-progress segments with the largest seen lastWriterEpoch. See the design document for more background and details.


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