Good point, Uma. Thanks, --Konst
On Tue, Jan 14, 2014 at 7:47 PM, Uma Maheswara Rao G <hadoop....@gmail.com>wrote: > Seems like you are hitting https://issues.apache.org/jira/browse/HDFS-1690? > > > On Wed, Jan 15, 2014 at 6:58 AM, Stanley Shi <s...@gopivotal.com> wrote: > > > Thanks Konstantin! > > I am running on vsphere VM with CentOS64 installed, Local file system is > > ext3; > > > > Regards, > > *Stanley Shi,* > > > > > > > > On Wed, Jan 15, 2014 at 8:27 AM, Konstantin Shvachko > > <shv.had...@gmail.com>wrote: > > > > > Yes format should check "in_use.lock". > > > What is your environment? > > > Does it support locks on you local file system? > > > > > > Thanks, > > > --Konst > > > > > > > > > On Tue, Jan 14, 2014 at 1:38 AM, Stanley Shi <s...@gopivotal.com> > wrote: > > > > > > > Hi, > > > > > > > > I have encountered this case in my environment: > > > > > > > > 1. NameNode is actively running without any problem; > > > > > > > > 2. someone accidentally formatted the namenode (even if there's one > > > > instance running); > > > > > > > > 3. The running namenode continues to write edit log starting from > some > > > big > > > > txid; > > > > > > > > > > > > This caused the namenode now in an in-consistent state: > > > > > > > > It has edit log and fsimage but if you restart the namenode, it will > > say > > > > the namenode cannot be started because it expect some txid 1 ; > > > > > > > > I think this is a bug. At least when formating the namenode, it > should > > > > check if there's an namenode instance already running. > > > > > > > > Regards, > > > > *Stanley Shi,* > > > > > > > > > >