[
https://issues.apache.org/jira/browse/HDFS-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862079#comment-13862079
]
Jing Zhao commented on HDFS-5709:
---------------------------------
bq. One possible solution is to turn of snapshot feature post upgade and allow
.snapshot directory or file. When a user tries to turn on .snapshot the
namenode fails to come up, forcing them to turn off the feature, rename
directories and turn it back on again. This may be a lot of work.
To support this we need to add a switch into SnapshotManager and we need to
check this switch every time resolving a .snapshot path. This may be a quick
fix but will make the current code not clean.
bq. make it an active decision during upgrade
I think an interactive upgrade process can be a possible solution, and this can
be the default behavior if a file/directory with a reserved name is detected.
In case that users want to disable the interactive process, a flag (like
-force) can be provided and the name read from the configuration (like
.user-snapshot) will be used for the rename. And all the rename should be
recorded/logged.
> Improve upgrade with existing files and directories named ".snapshot"
> ---------------------------------------------------------------------
>
> Key: HDFS-5709
> URL: https://issues.apache.org/jira/browse/HDFS-5709
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Affects Versions: 3.0.0, 2.2.0
> Reporter: Andrew Wang
> Labels: snapshots, upgrade
>
> Right now in trunk, upgrade fails messily if the old fsimage or edits refer
> to a directory named ".snapshot". We should at least print a better error
> message (which I believe was the original intention in HDFS-4666), and [~atm]
> proposed automatically renaming these files and directories.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
