hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjay Radia (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-8075) Revist layout version
Date Tue, 07 Apr 2015 17:45:15 GMT

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

Sanjay Radia commented on HDFS-8075:

Here is proposal:
* Add a *second* layout version field (call it "compatible-layout-version") that states which
version can safely read the image without data-loss.
** The ACL example will state that the previous version  can safely read the image without
data loss.
** Truncate example is tricky: one can safely downgrade if the truncate operation was not
used. We could add code to not allow such new features till finalize is done. Or we could
say don't support downgrade for such a feature and simply mark the compatible-layout-version

> Revist layout version
> ---------------------
>                 Key: HDFS-8075
>                 URL: https://issues.apache.org/jira/browse/HDFS-8075
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: HDFS
>    Affects Versions: 2.6.0
>            Reporter: Sanjay Radia
> Background
> * HDFS image layout was changed to use Protobufs to allow easier forward and backward
> * Hdfs has a layout version which is changed on each change (even if it an  optional
protobuf field was added).
> * Hadoop supports two ways of going back during an upgrade:
> **  downgrade: go back to old binary version but use existing image/edits so that newly
created files are not lost
> ** rollback: go back to "checkpoint" created before upgrade was started - hence newly
created files are lost.
> Layout needs to be revisited if we want to support downgrade is some circumstances which
we dont today. Here are use cases:
> * Some changes can support downgrade even though they was a change in layout since there
is not real data loss but only loss of new functionality. E.g. when we added ACLs one could
have downgraded - there is no data loss but you will lose the newly created ACLs. That is
acceptable for a user since one does not expect to retain the newly added ACLs in an old version.
> * Some changes may lead to data-loss if the functionality was used. For example, the
recent truncate will cause data loss if the functionality was actually used. Now one can tell
admins NOT use such new such new features till the upgrade is finalized in which case one
could potentially support downgrade.
> * A fairly fundamental change to layout where a downgrade is not possible but a rollback
is. Say we change the layout completely from protobuf to something else. Another example is
when HDFS moves to support partial namespace in memory - they is likely to be a fairly fundamental
change in layout.

This message was sent by Atlassian JIRA

View raw message