Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Sat, 29 Sep 2012 08:27:09 +1100 (NCT)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <111957938.141011.1348867629057.JavaMail.jiratomcat@arcas>
In-Reply-To: <1092823934.126902.1348635248145.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HDFS-3979) Fix hsync and hflush semantics.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lars Hofhansl commented on HDFS-3979:
-------------------------------------

Enqueing the seqno at end seems like the best approach. (Indeed this is done in the 0.20.x code as both of you said). 
I wonder why this was changed? Will have a new patch momentarily.

                
> Fix hsync and hflush semantics.
> -------------------------------
>
>                 Key: HDFS-3979
>                 URL: https://issues.apache.org/jira/browse/HDFS-3979
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: data-node, hdfs client
>    Affects Versions: 0.22.0, 0.23.0, 2.0.0-alpha
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>         Attachments: hdfs-3979-sketch.txt
>
>
> See discussion in HDFS-744. The actual sync/flush operation in BlockReceiver is not on a synchronous path from the DFSClient, hence it is possible that a DN loses data that it has already acknowledged as persisted to a client.
> Edit: Spelling.

--
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