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] [Updated] (HDFS-1846) Don't fill preallocated portion of edits log with 0x00
Date Thu, 21 Apr 2011 17:40:06 GMT

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

Aaron T. Myers updated HDFS-1846:
---------------------------------

    Attachment: hdfs-1846.0.txt

Thanks for the comments, Dhruba. Is your point that we should figure out some other way to
make the underlying FS allocate blocks, besides deliberately initializing the blocks? If so,
I should probably rename this JIRA to be "make sure the preallocation of edits logs actually
allocates blocks on disk."

I'm quite sure (at least on ext3 on Ubuntu Maverick) that the edits file does indeed end up
being sparse with the current implementation:

{code}
[10:29:51] atm@simon:~/src/apache/hadoop.git$ ls -l name-current.sparse/edits 
-rw-r--r-- 1 atm atm 1049092 2011-04-21 10:25 name-current.sparse/edits
[10:30:53] atm@simon:~/src/apache/hadoop.git$ du -B1 !$
du -B1 name-current.sparse/edits
32768	name-current.sparse/edits
[10:30:57] atm@simon:~/src/apache/hadoop.git$ ls -l dfs/name/current/edits 
-rw-r--r-- 1 atm atm 1048580 2011-04-21 10:26 dfs/name/current/edits
[10:31:03] atm@simon:~/src/apache/hadoop.git$ du -B1 !$
du -B1 dfs/name/current/edits
1052672	dfs/name/current/edits
{code}

Where "{{name-current.sparse}}" contains a copy of a {{dfs.name.dir/current}} directory created
with the current code, and "{{dfs/name/current}}" is a name directory created with modified
code which fills the preallocation space with {{OP_INVALID}}.

I've attached a patch of the code changes I made to do this test. Not intended for commit.

> Don't fill preallocated portion of edits log with 0x00
> ------------------------------------------------------
>
>                 Key: HDFS-1846
>                 URL: https://issues.apache.org/jira/browse/HDFS-1846
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>    Affects Versions: 0.23.0
>            Reporter: Aaron T. Myers
>            Assignee: Aaron T. Myers
>         Attachments: hdfs-1846.0.txt
>
>
> HADOOP-2330 added a feature to preallocate space in the local file system for the NN
transaction log. That change seeks past the current end of the file and writes out some data,
which on most systems results in the intervening data in the file being filled with zeros.
Most underlying file systems have special handling for sparse files, and don't actually allocate
blocks on disk for blocks of a file which consist completely of 0x00.
> I've seen cases in the wild where the volume an edits dir is on fills up, resulting in
a partial final transaction being written out to disk. If you examine the bytes of this (now
corrupt) edits file, you'll see the partial final transaction followed by a lot of zeros,
suggesting that the preallocation previously succeeded before the volume ran out of space.
If we fill the preallocated space with something other than zeros, we'd likely see the failure
at preallocation time, rather than transaction-writing time, and so cause the NN to crash
earlier, without a partial transaction being written out.
> I also hypothesize that filling the preallocated space in the edits log with something
other than 0x00 will result in a performance improvement in NN throughput. I haven't tested
this yet, but I intend to as part of this JIRA.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message