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-1936) Updating the layout version from HDFS-1822 causes upgrade problems.
Date Tue, 17 May 2011 00:16:47 GMT

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

Todd Lipcon commented on HDFS-1936:
-----------------------------------

I compiled the following list of versions:
{noformat}
  // -35: Adding support for block pools and multiple namenodes (federation)
  // -34: no new feature - just bumped after following three were reserved
  // The following three image versions are special out-of-sequence allocations
  // (i.e. they don't necessarily contain all features from "earlier" versions)
  // See HDFS-1822, HDFS-1842, 
  //   -33:    0.22.0
  //   -32:    0.20.204
  //   -31:    0.20.203
  // -30: HDFS-1070: store only last component of a path in image
  // -29: unused (skipped for no reason)
  // -28: HDFS-1630: fsedits are checksummed
  // -27: HDFS-259: remove intentionally corrupt pre-0.13 image directory
  // -26: image checksum
  // -25: image compression
  // -24: added OP_*_DELEGATION_TOKEN and OP_UPDATE_MASTER_KEY   *** 0.21.0 ***
  // -23: symlinks
  // -22: OP_CONCAT_DELETE
  // -21: atomic rename function
  // -20: datanode has a "rbw" subdirectory (append impl in 0.21)
  // -19: sticky bit                         *** CDH3, earlier 0.20.203 ***
  // -18: support disk space quotas          *** 0.20.2 ***
  // -17: support access time on files
  // -16: change edit log and fsimage to support quotas
  // -15: store generation stamp with each block

  // The special versions -31, -32, -33 are as follows:
  // -31: corresponds to release 0.20.203:
  //   * Includes functionality up to version -19
  //   * includes delegation token opcodes from -24, BUT
  //     with different opcode identifiers. Given this,
  //     we don't allow upgrade from this version.
  // -32:
  //   * Includes same set of features as version -31
  //   * Distinction is that the opcodes match trunk
  //
  // -33: 0.22.0
  //   * contains all features up through version -27
{noformat}

It seems that this patch might break upgrade from 0.21?

Rather than trying to force all the checks to particular "release boundaries", I really think
it would be easier to follow if we did the refactor now so that we can just encode that compression
is in -25 through -30 and -35 onwards?

> Updating the layout version from HDFS-1822 causes upgrade problems.
> -------------------------------------------------------------------
>
>                 Key: HDFS-1936
>                 URL: https://issues.apache.org/jira/browse/HDFS-1936
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>    Affects Versions: 0.22.0, 0.23.0
>            Reporter: Suresh Srinivas
>            Assignee: Suresh Srinivas
>            Priority: Blocker
>             Fix For: 0.22.0, 0.23.0
>
>         Attachments: HDFS-1936.22.patch, HDFS-1936.trunk.patch
>
>
> In HDFS-1822 and HDFS-1842, the layout versions for 203, 204, 22 and trunk were changed.
Some of the namenode logic that depends on layout version is broken because of this. Read
the comment for more description.

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

Mime
View raw message