My only concern with this is the potential burden of documenting and
testing the interoperability of these independently changing versions
-- especially given that we don't currently have any tests in this
area. In my experience, generating compatibility matrices can be
tricky business.
On Dec 7, 2006, at 9:23 PM, dhruba borthakur (JIRA) wrote:
splitting DFS version number
----------------------------
Key: HADOOP-807
URL: http://issues.apache.org/jira/browse/HADOOP-807
Project: Hadoop
Issue Type: Bug
Components: dfs
Reporter: dhruba borthakur
Assigned To: dhruba borthakur
In the current code, there is a enum named DFS_CURRENT_VERSION. It
is being used for three different purposes:
1. It is stored in the fsimage and represents the format of the
fsimage.
2. It is stored in the "storage" file by the Datanodes. Thus, it
represents the format of data on Datanodes.
3. It is used as a version of the Datanode Protocol.
The current implementation makes it difficult to change the fsimage
format without affecting the Datanode Protocol. My proposal is to
introduce three new constants, one for each of the functionality
described above.
In the current code, we have:
public static final int DFS_CURRENT_VERSION = -3;
Instead, we can have:
public static final int DFS_FSIMAGE_CURRENT_VERSION = -3;
public static final int DFS_DATANODEPROTOCOL_CURRENT_VERSION = -3;
public static final int DFS_DATASTORAGE_CURRENT_VERSION = -3;
The first one is associated with the format of the fsimage/edits;
the second one is associated with the communication procotol
between the namenode and the datanode; the third one is associated
with the format of the datastore on the datanodes (e.g. directory
fanout).
Please comment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/
Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/
software/jira
