[
https://issues.apache.org/jira/browse/HADOOP-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467224
]
Yoram Arnon commented on HADOOP-702:
------------------------------------
losing the capability for multiple snapshots is regrettable, but if the
snapshots aren't maintained and are just left there to rot then perhaps it's
not such a bad thing. A full snapshots solution will need to wait until it's
done, well, fully.
Not being able to restart just the name node with an upgraded version is
regrettable too, since we've seen cases where a tiny namenode bug is fixed and
it's *much* simpler to update just one node than to update the entire cluster.
Can that limitation be relaxed?
Datanodes automatically "catching up" on a missed previous upgrade/discard
seems like a good thing, isn't it?
The benchmark - was it executed on a machine with a single disk or several? How
fast can links be created (and deleted) on a machine with several disks?
> DFS Upgrade Proposal
> --------------------
>
> Key: HADOOP-702
> URL: https://issues.apache.org/jira/browse/HADOOP-702
> Project: Hadoop
> Issue Type: New Feature
> Components: dfs
> Reporter: Konstantin Shvachko
> Assigned To: Konstantin Shvachko
> Attachments: DFSUpgradeProposal.html, DFSUpgradeProposal2.html,
> DFSUpgradeProposal3.html, FSStateTransition.html, TestPlan-HdfsUpgrade.html,
> TestPlan-HdfsUpgrade.html
>
>
> Currently the DFS cluster upgrade procedure is manual.
> http://wiki.apache.org/lucene-hadoop/Hadoop_Upgrade
> It is rather complicated and does not guarantee data recoverability in case
> of software errors or administrator mistakes.
> This is a description of utilities that make the upgrade process almost
> automatic and minimize chance of loosing or corrupting data.
> Please see the attached html file for details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
