> dot release. And the hadoop code should handle the required disk
> format upgrades and downgrades transparently. This issue, by itself,
If by "downgrades" you mean "rollbacks", then this sounds right to me.
You did not mean that we should support data conversions from
higher versions to lower, right?
I think Sanjay's proposal to weaken the data conversion requirement
makes sense. We should say that direct upgrades between some versions
may not be possible, only via intermediate version(s). But we should
also say what is the minimal distance between such versions.
E.g. "direct upgrades between different major releases may not be
possible".
--Konstantin
Dhruba Borthakur wrote:
Hi Sanjay,
Ok, let me understand the terminology.
-- Versions 1.0 and versions 2.0 are "major" releases, maybe occur
once every year
-- Versions 1.2 and 1.3 are minor releases, maybe occurs once every 2 months
-- Versions 2.4.5 and 2.4.6 are "dot" release.
Is my understanding correct?
don't you want disk format compatibility to be for both major and minor release
changes as I stated earlier?
Disk formats can change for both major and minor releases but not for
dot release. And the hadoop code should handle the required disk
format upgrades and downgrades transparently. This issue, by itself,
should have no impact on pre-existing FileSystem APIs.
Does this make sense?
thanks,
dhruba
On Wed, Oct 22, 2008 at 9:04 AM, Sanjay Radia <[EMAIL PROTECTED]> wrote:
On Oct 20, 2008, at 11:44 PM, Dhruba Borthakur wrote:
3. HDFS disk format can change from 1.x to 1.y release and is
transparent to user-application. A cluster when rolling back to 1.x
from 1,y will revert back to the old disk format.
Dhruba don't you want disk format compatibility to be for both major and
minor release changes as I stated earlier?
I don't think it is acceptable to break data format across major releases.
Q. do we want disk upgrade to be supported across arbitrary number of
releases? For example we allowed the crc upgrade for
approx 4 releases in the past.
