hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-1538) Refactor more startup and image loading code out of FSImage
Date Tue, 29 Mar 2011 20:48:06 GMT

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

Todd Lipcon commented on HDFS-1538:

bq. Is your multiple edit directory scenario referring to what may happen post1073? It can
happen now, loadPlan does a sweep to find the latest directory so thats covered, but getStorageDirectoryForProperties()
always returns latestNameSD

Yes -- the current behavior should maintain what the pre-1073 code does. With the storage
inspector from HDFS-1793 (next in the patch sequence) the behavior might be slightly different.

bq. I think this would make it clearer that when you load a image up to point N, you load
edits starting from N+1

I see your point - I just tried to do that, and it actually ends up moving some complexity
out to other places, for example in the BackupNode and 2NN code where loadEdits is also used.
Rather than duplicating the pattern there, I think it's better to leave it for now. Does that
seem reasonable?

> Refactor more startup and image loading code out of FSImage
> -----------------------------------------------------------
>                 Key: HDFS-1538
>                 URL: https://issues.apache.org/jira/browse/HDFS-1538
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>    Affects Versions: Edit log branch (HDFS-1073)
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>             Fix For: Edit log branch (HDFS-1073)
>         Attachments: hdfs-1538-1.txt, hdfs-1538-2.txt, hdfs-1538-on-1521.txt, hdfs-1538-on-branch.2.txt,
hdfs-1538-on-branch.txt, hdfs-1538.txt
> For HDFS-1073, we need to be able to continue to load images in the old "fsimage/edits/edits.new"
layout for the purposes of upgrade.  But that code will be only for backwards compatibility,
and we want to be able to switch to new code for the new layout. This subtask is to separate
out much of that code into an interface which we can implement for both the old and new layouts.

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

View raw message