Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 7 Jul 2011 00:43:16 +0000 (UTC)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <1942238474.5728.1309999396621.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1022903786.5720.1309999036872.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (HDFS-2133) 1073: address remaining TODOs and
 pre-merge cleanup
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Todd Lipcon updated HDFS-2133:
------------------------------

    Attachment: hdfs-2133.txt

Patch addresses the following:


- removes an extra "setReadyToFlush/flush" call in EditLogFileOutputStream.close. This snuck in when we did some refactoring, but seems unnecessary, since we always flush before closing a stream anyway. Tests seem to be passing even when I remove this (and the next bit of that same function already verifies that there isn't any unflushed data in the buffer)

{code:title=FSImage.java}
-    // TODO need to discuss what the correct logic is for determing which
-    // storage directory to read properties from
     sdForProperties.read();
{code}
This TODO is invalid -- when inspecting the dirs at startup, we already call {{read()}} for each directory. That means that we've verified that they all contain the same data. Since VERSION files are now just namespace info, and nothing related to checkpoint times or versions, it doesn't matter which one we read() from here.

{code:title=FSImage.java}
-      storage.writeAll(); // TODO is this a good spot for this?
-      
+      storage.writeAll();
{code}
Yes, I think it's a good spot :) Eli had commented that he agreed in an earlier code review, but I hadn't removed it at that point. This {{writeAll}} call is necessary when adding new directories to a NN, for example.

- various changes to remove checkpointTxId from NameNodeRegistration and CheckpointCommand. A checkpoint txid is no longer relevant when deciding whether to allow a checkpoint to take place, since we can distinguish between different checkpoints at different txids.

- various javadoc additions where things were incorrect or incomplete


> 1073: address remaining TODOs and pre-merge cleanup
> ---------------------------------------------------
>
>                 Key: HDFS-2133
>                 URL: https://issues.apache.org/jira/browse/HDFS-2133
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: name-node
>    Affects Versions: Edit log branch (HDFS-1073)
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>             Fix For: Edit log branch (HDFS-1073)
>
>         Attachments: hdfs-2133.txt
>
>
> There are a few TODOs still in the code and a bit of cleanup to be done before merging HDFS-1073. This JIRA is for this misc cleanup.

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