[ https://issues.apache.org/jira/browse/HDFS-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887540#comment-13887540 ]
Vinay commented on HDFS-5754: ----------------------------- First of all, sorry for coming in late ( that too after commit )... All Changes look good, except following one. {noformat}+ if (DataNodeLayoutVersion.supports( + LayoutVersion.Feature.FEDERATION, + HdfsConstants.DATANODE_LAYOUT_VERSION) && + HdfsConstants.DATANODE_LAYOUT_VERSION == nsInfo.getLayoutVersion()) { readProperties(sd, nsInfo.getLayoutVersion()); writeProperties(sd); LOG.info("Layout version rolled back to " +{noformat} Here while rolling back and previous directory not exist, {{DATANODE_LAYOUT_VERSION}} is directly compared with {{NAMENODE_LAYOUT_VERSION}} to update the VERSION file. But LayoutVersion is split because both these could be different in same version of hadoop right? {noformat}+ if (HdfsConstants.DATANODE_LAYOUT_VERSION != nsInfo.getLayoutVersion()) { + LOG.info("DataNode and NameNode layout versions are different:" + + " DataNode version: "+ HdfsConstants.DATANODE_LAYOUT_VERSION + + " NameNode version: "+ nsInfo.getLayoutVersion());{noformat} May be this log not required. Only below log is enough with condition removed. {noformat}+ if( HdfsConstants.DATANODE_LAYOUT_VERSION == nsInfo.getLayoutVersion()) + LOG.info("Data-node version: " + HdfsConstants.DATANODE_LAYOUT_VERSION + + " and name-node layout version: " + nsInfo.getLayoutVersion());{noformat} If any changes required I am ok to do in separate Jira instead of re-opening this. > Split LayoutVerion into NamenodeLayoutVersion and DatanodeLayoutVersion > ------------------------------------------------------------------------ > > Key: HDFS-5754 > URL: https://issues.apache.org/jira/browse/HDFS-5754 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: datanode, namenode > Reporter: Tsz Wo (Nicholas), SZE > Assignee: Brandon Li > Fix For: HDFS-5535 (Rolling upgrades) > > Attachments: FeatureInfo.patch, HDFS-5754.001.patch, > HDFS-5754.002.patch, HDFS-5754.003.patch, HDFS-5754.004.patch, > HDFS-5754.006.patch, HDFS-5754.007.patch, HDFS-5754.008.patch, > HDFS-5754.009.patch, HDFS-5754.010.patch, HDFS-5754.012.patch, > HDFS-5754.013.patch > > > Currently, LayoutVersion defines the on-disk data format and supported > features of the entire cluster including NN and DNs. LayoutVersion is > persisted in both NN and DNs. When a NN/DN starts up, it checks its > supported LayoutVersion against the on-disk LayoutVersion. Also, a DN with a > different LayoutVersion than NN cannot register with the NN. > We propose to split LayoutVersion into two independent values that are local > to the nodes: > - NamenodeLayoutVersion - defines the on-disk data format in NN, including > the format of FSImage, editlog and the directory structure. > - DatanodeLayoutVersion - defines the on-disk data format in DN, including > the format of block data file, metadata file, block pool layout, and the > directory structure. > The LayoutVersion check will be removed in DN registration. If > NamenodeLayoutVersion or DatanodeLayoutVersion is changed in a rolling > upgrade, then only rollback is supported and downgrade is not. -- This message was sent by Atlassian JIRA (v6.1.5#6160)