Package org.apache.hadoop.hdfs.server.namenode

Enum Class NameNodeLayoutVersion.Feature

java.lang.Object
java.lang.Enum<NameNodeLayoutVersion.Feature>
org.apache.hadoop.hdfs.server.namenode.NameNodeLayoutVersion.Feature
All Implemented Interfaces:
Serializable, Comparable<NameNodeLayoutVersion.Feature>, Constable, org.apache.hadoop.hdfs.protocol.LayoutVersion.LayoutFeature
Enclosing class:
org.apache.hadoop.hdfs.server.namenode.NameNodeLayoutVersion
public static enum NameNodeLayoutVersion.Feature extends Enum<NameNodeLayoutVersion.Feature> implements org.apache.hadoop.hdfs.protocol.LayoutVersion.LayoutFeature
Enums for features that change the layout version.

To add a new layout version:
  • Define a new enum constant with a short enum name, the new layout version and description of the added feature.
  • When adding a layout version with an ancestor that is not same as its immediate predecessor, use the constructor where a specific ancestor can be passed.
  • Specify a minimum compatible layout version. The minimum compatible layout version is the earliest prior version to which a downgrade is possible after initiating rolling upgrade. If the feature cannot satisfy compatibility with any prior version, then set its minimum compatible layout version to itself to indicate that downgrade is impossible. Satisfying compatibility might require adding logic to the new feature to reject operations or handle them differently while rolling upgrade is in progress. In general, it's possible to satisfy compatibility for downgrade if the new feature just involves adding new edit log ops. Deeper structural changes, such as changing the way we place files in the metadata directories, might be incompatible. Feature implementations should strive for compatibility, because it's in the best interest of our users to support downgrade.