[ 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)