Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Mon, 11 Jun 2012 22:18:42 +0000 (UTC)
From: "Colin Patrick McCabe (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <1869567725.4482.1339453122809.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <553465024.41682.1338934584773.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Updated] (HDFS-3510) Fix 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:all-tabpanel ]

Colin Patrick McCabe updated HDFS-3510:
---------------------------------------

    Description: 
In the FSEditLog, we want to avoid running out of space in the middle of writing an edit log operation to the disk. We do this by a process called "preallocation"-- reserving space on the disk for the upcoming edit log entries before beginning to write them.

The idea is that if we're going to encounter an out-of-disk-space condition, we don't want it to happen in the middle of writing valid data.  Instead, we want it to happen in the middle of writing padding bytes.  The edit log uses bytes with the value 0xff (in decimal, -1) as padding.  These bytes correspond to FSEditLogOp.OP_INVALID.

The current preallocation strategy is flawed.  Although we preallocate a very large chunk at a time-- 1 megabyte, in fact-- we only do this preallocation when we are more than 4096 bytes away from the end of the file.  This means that the effective preallocation length is only 4096 bytes.  A batch of edit log entries could easily be more than this.  There is evidence that this has caused problems in the field for end-users.

Here is a visual illustration of the old preallocation strategy:

{code}
first write
|
V <----- 1 MB ----->
+--+---------------+
|__|FFFFFFFFFFFFFFF|
+--+---------------+
    second write
    |
    V
+--+------+--------+
|__|______|FFFFFFFF|
+--+------+--------+
           third write
           |
           V
+--+------+------+-+
|__|______|______|_|
+--+------+------+-+
                  fourth write
                  | (NOT preallocated)
                  V
+--+------+------+-+
|__|______|______|________
+--+------+------+-+
                          fifth write
                          |
                          V<--- 1 MB -->
+--+------+------+--------+---+--------+
|__|______|______|________|___|FFFFFFFF|
+--+------+------+--------+---+--------+
{code}

And here is the new preallocation strategy:

{code}
first write
|
V
+--+
|__|
+--+
    second write
    |
    V
+--+------+
|__|______|
+--+------+
           third write
           |
           V
+--+------+------+
|__|______|______|
+--+------+------+
                  fourth write
                  |
                  V
+--+------+------+--------+
|__|______|______|________|
+--+------+------+--------+
                           fifth write
                           |
                           V
+--+------+------+--------+---+
|__|______|______|________|___|
+--+------+------+--------+---+
{code}

  was:
In the FSEditLog, we want to avoid running out of space in the middle of writing an edit log operation to the disk.  We do this by a process called "preallocation"-- reserving space on the disk for the upcoming edit log entries before beginning to write them.

There are two problems:

In both trunk and branch-1:
* We only try to do preallocation when the current position is less than 4096 bytes from the end of the file.  However, bufReady starts out at 512kb, and only gets bigger from there.  There is no way that 4kb is enough space to reserve.

Only in branch-1:
* The branch-1 code unfortunately creates sparse files rather than actually pre-allocating the required space.

    
> Fix 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
>
>
> In the FSEditLog, we want to avoid running out of space in the middle of writing an edit log operation to the disk. We do this by a process called "preallocation"-- reserving space on the disk for the upcoming edit log entries before beginning to write them.
> The idea is that if we're going to encounter an out-of-disk-space condition, we don't want it to happen in the middle of writing valid data.  Instead, we want it to happen in the middle of writing padding bytes.  The edit log uses bytes with the value 0xff (in decimal, -1) as padding.  These bytes correspond to FSEditLogOp.OP_INVALID.
> The current preallocation strategy is flawed.  Although we preallocate a very large chunk at a time-- 1 megabyte, in fact-- we only do this preallocation when we are more than 4096 bytes away from the end of the file.  This means that the effective preallocation length is only 4096 bytes.  A batch of edit log entries could easily be more than this.  There is evidence that this has caused problems in the field for end-users.
> Here is a visual illustration of the old preallocation strategy:
> {code}
> first write
> |
> V <----- 1 MB ----->
> +--+---------------+
> |__|FFFFFFFFFFFFFFF|
> +--+---------------+
>     second write
>     |
>     V
> +--+------+--------+
> |__|______|FFFFFFFF|
> +--+------+--------+
>            third write
>            |
>            V
> +--+------+------+-+
> |__|______|______|_|
> +--+------+------+-+
>                   fourth write
>                   | (NOT preallocated)
>                   V
> +--+------+------+-+
> |__|______|______|________
> +--+------+------+-+
>                           fifth write
>                           |
>                           V<--- 1 MB -->
> +--+------+------+--------+---+--------+
> |__|______|______|________|___|FFFFFFFF|
> +--+------+------+--------+---+--------+
> {code}
> And here is the new preallocation strategy:
> {code}
> first write
> |
> V
> +--+
> |__|
> +--+
>     second write
>     |
>     V
> +--+------+
> |__|______|
> +--+------+
>            third write
>            |
>            V
> +--+------+------+
> |__|______|______|
> +--+------+------+
>                   fourth write
>                   |
>                   V
> +--+------+------+--------+
> |__|______|______|________|
> +--+------+------+--------+
>                            fifth write
>                            |
>                            V
> +--+------+------+--------+---+
> |__|______|______|________|___|
> +--+------+------+--------+---+
> {code}

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