Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 21 Jun 2012 20:37:42 +0000 (UTC)
From: "Colin Patrick McCabe (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <325652903.41058.1340311062871.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <553465024.41682.1338934584773.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (HDFS-3510) Improve FSEditLog pre-allocation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Colin Patrick McCabe commented on HDFS-3510:
--------------------------------------------

bq. BTW, with the current patch the following is possible (no OP_INVALID following a journal record):
bq. {code}
--- journal records --- end-of-file
{code}
bq. I have not had a chance to look at how rest of the code deals with that condition.

It works.  The relevant code is in decodeOp:

{code}
byte opCodeByte;
try {
  opCodeByte = in.readByte();
} catch (EOFException eof) {
  // EOF at an opcode boundary is expected.
  return null;
}
{code}

As always, thanks for your reviews.  It's good to be thorough when dealing with this stuff. -C
                
> Improve FSEditLog pre-allocation
> --------------------------------
>
>                 Key: HDFS-3510
>                 URL: https://issues.apache.org/jira/browse/HDFS-3510
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 1.0.0, 2.0.0-alpha
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>             Fix For: 1.0.0, 2.0.1-alpha
>
>         Attachments: HDFS-3510-b1.001.patch, HDFS-3510-b1.002.patch, HDFS-3510.001.patch, HDFS-3510.003.patch, HDFS-3510.004.patch, HDFS-3510.004.patch, HDFS-3510.006.patch, HDFS-3510.007.patch, HDFS-3510.008.patch, HDFS-3510.009.patch, HDFS-3510.010.patch
>
>
> It is good to avoid running out of space in the middle of writing a batch of edits, because when it happens, we often get partial edits at the end of the log.
> Edit log preallocation can solve this problem (see HADOOP-2330 for a full description of edit log preallocation).
> The current pre-allocation code was introduced for performance reasons, not for preventing partial edits.  As a consequence, we sometimes do a write without using pre-allocation.  We should change the pre-allocation code so that it always preallocates at least enough space before writing out the edits.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira