[
https://issues.apache.org/jira/browse/HDFS-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862134#comment-13862134
]
Andrew Wang commented on HDFS-5709:
-----------------------------------
Cool, thanks Suresh and Jing. Glad we've converged on something palatable.
Suresh, is there any reason you prefer a prefix over a full substitution? Full
sub would be more flexible. I somewhat prefer the look of
{{.myprefix-snapshot}} over {{myprefix-.snapshot}} too.
There's also the question of what to do if the destination path already exists.
I think the simplest thing to do is just to abort. My first thought was to try
incrementing some value until there's no collision, e.g. .user-snapshot,
.user-snapshot-1, .user-snapshot-2, but you could still collide with a future
edit in the edit log. We could insert a UUID, but then edit log replay becomes
non-deterministic across NNs. So, I think just abort.
bq. I think an interactive upgrade process can be a possible solution
This is an interesting suggestion, but I'd prefer to make this as automatic as
possible first if we can do it.
> 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)
