Hi all, Just to follow up, Joseph went on IRC and we managed to get his DFS back into shape.
It's unclear how it got into this state, but there was a storage directory with an 0.20 (layout version -18) fsimage and an 0.21 (LV -24) edits file. The edits file was in fact empty (4 bytes), so I had him printf a -18 LV header into it, and restore it as namedir/current. >From there he was able to rollback to 0.20. We should do some good verification of upgrade/rollback for 0.22 release - it's not clear if it was user error or a bug that got the cluster into this state. -Todd On Wed, Dec 15, 2010 at 11:57 AM, Joseph Engo <dev.toas...@gmail.com> wrote: > I attempted an upgrade from 0.20.2 to 0.21.0 the other day and run into a > bunch of major issues. Now I am attempting to roll back HDFS. I did not > finalize the upgrade. > After I switched out the binaries on the install and reverted the configs > back to my 0.20.2 version, I attempted to do ./start-dfs.sh -rollback but > found the following error in the logs: > ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: java.io.IOException: > Cannot rollback. None of the storage directories contain previous fs state. > Looking inside the dfs.name.dir location I do see a previous.checkpoint > directory. Inside the dfs.data.dir directory I also see a previous > directory that still exists. > When I try to load up ./start-dfs.sh without the -rollback I get: > ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: java.io.IOException: > Unexpected version of the file system log file: -24. Current version = -18. > Any suggestions on what I can try next ? I am desperate to get this back up > and running. I spent 2 days fighting the 0.21.0 upgrade and would rather > get back to something stable. The reason I attempted the upgrade was to > solve some really strange issues with the fair scheduler. > Thanks! -- Todd Lipcon Software Engineer, Cloudera
