[
https://issues.apache.org/jira/browse/HDFS-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882915#comment-13882915
]
Aaron T. Myers commented on HDFS-5709:
--------------------------------------
bq. The configuration lingers on for ever, unless and informed user can get rid
of it. That is the reason why configuration is perhaps not the best way to do
this.
I honestly don't understand what the aversion is to having this be
configurable. Having a setting in an XML file longer than it strictly needs to
be doesn't do any harm.
bq. Or, just rename it based on convention as I had proposed. User can either
glean this from the log (preferred) or from searching fsimage the renamed paths
and rename them as they wish. Given that the likelihood of users running into
this conflict in the first place is low, this should be acceptable.
I'm fine renaming it based on some convention by default, but I feel strongly
that the rename behavior should be optionally configurable. That's what I
proposed above as a compromise.
> 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
> Assignee: Andrew Wang
> Labels: snapshots, upgrade
> Attachments: hdfs-5709-1.patch, hdfs-5709-2.patch, hdfs-5709-3.patch,
> hdfs-5709-4.patch, hdfs-5709-5.patch
>
>
> 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)
