[
https://issues.apache.org/jira/browse/HDFS-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876981#comment-13876981
]
Andrew Wang commented on HDFS-5709:
-----------------------------------
Hey Suresh,
Sure, I can summarize. What this patch does essentially is pass all path
components during FSImage loading and paths during edit log loading through new
{{renameReserved*}} methods. Right now these methods just have an if check for
if we're upgrading from a version that doesn't support snapshots, but it's easy
to add more if statements for other LVs with reserved components. Jing had some
suggestions about how we can make the renaming process a little more generic,
but I think he and I agree that it should be easy to do this later.
The only difference from your prior proposed solution is that I wanted a more
expressive config option than a prefix, so went with a full substitution
instead. This lets users rename {{.snapshot}} to {{.user-snapshot}}, not just
{{MYPREFIX.snapshot}}. Since I don't foresee us adding that many more reserved
paths, a config option per seems like a tolerable overhead.
> 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)
