visual studio 6.0 link 2001常見錯(cuò)誤解決總結(jié)

第一篇：visual studio 6.0 link 2001常見錯(cuò)誤解決總結(jié)

第一：

nafxcwd.lib(appcore.obj): error LNK2001: unresolved external symbol ___argv

nafxcwd.lib(appcore.obj): error LNK2001: unresolved external symbol ___argc

nafxcwd.lib(timecore.obj): error LNK2001: unresolved external symbol __mbctype

nafxcwd.lib(apphelp.obj): error LNK2001: unresolved external symbol __mbctype

nafxcwd.lib(filelist.obj): error LNK2001: unresolved external symbol __mbctype

解決辦法：

PROJECT->SETING->C/C++->PREPROCESSOR->定義 _AFXDLL

第二：

解決外部符號(hào)錯(cuò)誤:_main,_WinMain@16,__beginthreadex

在創(chuàng)建MFC項(xiàng)目時(shí), 不使用MFC AppWizard向?qū)? 如果沒有設(shè)置好項(xiàng)目參數(shù), 就會(huì)在編譯時(shí)產(chǎn)生很多連接錯(cuò)誤, 如error LNK2001錯(cuò)誤, 典型的錯(cuò)誤提示有:

libcmtd.lib(crt0.obj): error LNK2001: unresolved external symbol _main

LIBCD.lib(wincrt0.obj): error LNK2001: unresolved external symbol _WinMain@16

1.Windows子系統(tǒng)設(shè)置錯(cuò)誤, 提示:

libcmtd.lib(crt0.obj): error LNK2001: unresolved external symbol _main

Windows項(xiàng)目要使用Windows子系統(tǒng), 而不是Console, 可以這樣設(shè)置:

[Project]--> [Settings]--> 選擇“Link”屬性頁(yè),在Project Options中將/subsystem:console改成/subsystem:windows

2.Console子系統(tǒng)設(shè)置錯(cuò)誤, 提示:

LIBCD.lib(wincrt0.obj): error LNK2001: unresolved external symbol _WinMain@16

控制臺(tái)項(xiàng)目要使用Console子系統(tǒng), 而不是Windows, 設(shè)置:

[Project]--> [Settings]--> 選擇“Link”屬性頁(yè),在Project Options中將/subsystem:windows改成/subsystem:console

3.程序入口設(shè)置錯(cuò)誤, 提示:

msvcrtd.lib(crtexew.obj): error LNK2001: unresolved external symbol _WinMain@16

通常, MFC項(xiàng)目的程序入口函數(shù)是WinMain, 如果編譯項(xiàng)目的Unicode版本, 程序入口必須改為wWinMainCRTStartup, 所以需要重新設(shè)置程序入口:

[Project]--> [Settings]--> 選擇“Link”屬性頁(yè),在Category中選擇Output,再在Entry-point symbol中填入wWinMainCRTStartup, 即可

4.線程運(yùn)行時(shí)庫(kù)設(shè)置錯(cuò)誤, 提示:

nafxcwd.lib(thrdcore.obj): error LNK2001: unresolved external symbol __beginthreadexnafxcwd.lib(thrdcore.obj): error LNK2001: unresolved external symbol __endthreadex

這是因?yàn)镸FC要使用多線程時(shí)庫(kù), 需要更改設(shè)置:

[Project]--> [Settings]--> 選擇“C/C++”屬性頁(yè),在Category中選擇Code Generation,再在Use run-time library中選擇Debug Multithreaded或者multithreaded

其中,Single-Threaded 單線程靜態(tài)鏈接庫(kù)(release版本)

Multithreaded 多線程靜態(tài)鏈接庫(kù)(release版本)

multithreaded DLL 多線程動(dòng)態(tài)鏈接庫(kù)(release版本)

Debug Single-Threaded 單線程靜態(tài)鏈接庫(kù)(debug版本)

Debug Multithreaded 多線程靜態(tài)鏈接庫(kù)(debug版本)

Debug Multithreaded DLL 多線程動(dòng)態(tài)鏈接庫(kù)(debug版本)

單線程: 不需要多線程調(diào)用時(shí), 多用在DOS環(huán)境下

多線程: 可以并發(fā)運(yùn)行

靜態(tài)庫(kù): 直接將庫(kù)與程序Link, 可以脫離MFC庫(kù)運(yùn)行

動(dòng)態(tài)庫(kù): 需要相應(yīng)的DLL動(dòng)態(tài)庫(kù), 程序才能運(yùn)行

release版本: 正式發(fā)布時(shí)使用

debug版本: 調(diào)試階段使用

初學(xué)者在學(xué)習(xí)VC++的過(guò)程中，遇到的LNK2001錯(cuò)誤的錯(cuò)誤消息主要為：

unresolved external symbol “symbol”（不確定的外部“符號(hào)”）。

如果連接程序不能在所有的庫(kù)和目標(biāo)文件內(nèi)找到所引用的函數(shù)、變量或標(biāo)簽，將產(chǎn)生此錯(cuò)誤消息。一般來(lái)說(shuō)，發(fā)生錯(cuò)誤的原因有兩個(gè)：一是所引用的函數(shù)、變量不存在、拼寫不正確或者使用錯(cuò)誤；其次可能使用了不同版本的連接庫(kù)。

以下是可能產(chǎn)生LNK2001錯(cuò)誤的原因：

一．由于編碼錯(cuò)誤導(dǎo)致的LNK200

11．不相匹配的程序代碼或模塊定義(.DEF)文件能導(dǎo)致LNK2001。例如, 如果在C++源文件內(nèi)聲明了一變量“var1”，卻試圖在另一文件內(nèi)以變量“VAR1”訪問該變量,將發(fā)生該錯(cuò)誤。

2．如果使用的內(nèi)聯(lián)函數(shù)是在.CPP文件內(nèi)定義的，而不是在頭文件內(nèi)定義將導(dǎo)致LNK2001錯(cuò)誤。

3．調(diào)用函數(shù)時(shí)如果所用的參數(shù)類型同函數(shù)聲明時(shí)的類型不符將會(huì)產(chǎn)生LNK2001。

4．試圖從基類的構(gòu)造函數(shù)或析構(gòu)函數(shù)中調(diào)用虛擬函數(shù)時(shí)將會(huì)導(dǎo)致LNK2001。

5．要注意函數(shù)和變量的可公用性，只有全局變量、函數(shù)是可公用的。靜態(tài)函數(shù)和靜態(tài)變量具有相同的使用范圍限制。當(dāng)試圖從文件外部訪問任何沒有在該文件內(nèi)聲明的靜態(tài)變量時(shí)將導(dǎo)致編譯錯(cuò)誤或LNK2001。

函數(shù)內(nèi)聲明的變量(局部變量)只能在該函數(shù)的范圍內(nèi)使用。

C++ 的全局常量只有靜態(tài)連接性能。這不同于C，如果試圖在C++的多個(gè)文件內(nèi)使用全局變量也會(huì)產(chǎn)生LNK2001錯(cuò)誤。一種解決的方法是需要時(shí)在頭文件中加入該常量的初始化代碼，并在.CPP文件中包含該頭文件；另一種方法是使用時(shí)給該變量賦以常數(shù)。

二．由于編譯和鏈接的設(shè)置而造成的LNK2001

1．如果編譯時(shí)使用的是/NOD(/NODEFAULTLIB)選項(xiàng)，程序所需要的運(yùn)行庫(kù)和MFC庫(kù)在連接時(shí)由編譯器寫入目標(biāo)文件模塊，但除非在文件中明確包含這些庫(kù)名，否則這些庫(kù)不會(huì)被鏈接進(jìn)工程文件。在這種情況下使用/NOD將導(dǎo)致錯(cuò)誤LNK2001。

2．如果沒有為wWinMainCRTStartup設(shè)定程序入口，在使用Unicode和MFC時(shí)將得到“unresolved external on _WinMain@16”的LNK2001錯(cuò)誤信息。

3．使用/MD選項(xiàng)編譯時(shí),既然所有的運(yùn)行庫(kù)都被保留在動(dòng)態(tài)鏈接庫(kù)之內(nèi)，源文件中對(duì)“func”的引用，在目標(biāo)文件里即對(duì)“__imp__func” 的引用。如果試圖使用靜態(tài)庫(kù)LIBC.LIB或LIBCMT.LIB進(jìn)行連接，將在__imp__func上發(fā)生LNK2001；如果不使用/MD選項(xiàng)編譯，在使用MSVCxx.LIB連接時(shí)也會(huì)發(fā)生LNK2001。

4．使用/ML選項(xiàng)編譯時(shí)，如用LIBCMT.LIB鏈接會(huì)在_errno上發(fā)生LNK2001。

5．當(dāng)編譯調(diào)試版的應(yīng)用程序時(shí)，如果采用發(fā)行版模態(tài)庫(kù)進(jìn)行連接也會(huì)產(chǎn)生LNK2001；同樣，使用調(diào)試版模態(tài)庫(kù)連接發(fā)行版應(yīng)用程序時(shí)也會(huì)產(chǎn)生相同的問題。

6．不同版本的庫(kù)和編譯器的混合使用也能產(chǎn)生問題，因?yàn)樾掳娴膸?kù)里可能包含早先的版本沒有的符號(hào)和說(shuō)明。

編程時(shí)打開了函數(shù)內(nèi)聯(lián)（/Ob1或/Ob2)，但是在描述該函數(shù)的相應(yīng)頭文件里卻關(guān)閉了函數(shù)內(nèi)聯(lián)（沒有inline關(guān)鍵字），這時(shí)將得到該錯(cuò)誤信息。為避免該問題的發(fā)生，應(yīng)該在相應(yīng)的頭文件中用inline關(guān)鍵字標(biāo)志內(nèi)聯(lián)函數(shù)。

8．不正確的/SUBSYSTEM或/ENTRY設(shè)置也能導(dǎo)致LNK2001。

LINK : fatal error LNK1117: syntax error in option “subsystem:windows/incremental:yes” 解決方法：刪掉incremental:yes

vc編譯報(bào)錯(cuò) unresolved external symbol __imp__PlaySoundA@12 解決辦法添加Winmm.lib和頭文件中包含 Mmsystem.h

選擇“project”->“setting”->“l(fā)ink”->“Object/librarymodules”然后添加“Winmm.lib”就可以了。

第二篇：鋼筋常見錯(cuò)誤總結(jié)（精選）

鋼筋常見錯(cuò)誤

一、基礎(chǔ)常見錯(cuò)誤

1、基礎(chǔ)梁接頭位置不對(duì)，按樓層框架梁接頭位置設(shè)置，且沒有錯(cuò)開（基礎(chǔ)梁與框架梁的受力正好相反，接頭亦然）。

2、筏板鋼筋接頭在施工縫處預(yù)留長(zhǎng)度不夠，且接頭沒錯(cuò)開。

3、基礎(chǔ)馬凳擺放錯(cuò)誤，如果換一方向，每一排馬凳可省一固定用通長(zhǎng)鋼筋?；蛘?，馬凳上通長(zhǎng)鋼筋利用筏板上部同方向縱筋。

4、筏板面積較大，卻仍按50%接頭百分率，未按25%百分率接頭，導(dǎo)致鋼筋接頭浪費(fèi)。

5、底板縱筋接頭長(zhǎng)度有的太長(zhǎng)，超過(guò)一個(gè)搭接長(zhǎng)度，有的則太短，不能滿足規(guī)范所要求的長(zhǎng)度。底板通長(zhǎng)筋沒綁扎成平行直線，導(dǎo)致同截面鋼筋根數(shù)不同。

6、承臺(tái)按規(guī)范是不縮減的，設(shè)計(jì)“優(yōu)化”按獨(dú)立基礎(chǔ)構(gòu)造搞成縮減，這屬于設(shè)計(jì)的偷工減料。

7、筏板封邊構(gòu)造沒按規(guī)范和設(shè)計(jì)，擅自設(shè)置筏板上下縱筋彎折長(zhǎng)度。

8、筏板縱筋接頭設(shè)置在后澆帶內(nèi)（縱筋接頭不宜設(shè)置在后澆帶位置）。

9、接樁鋼筋并在一塊。

二、柱常見錯(cuò)誤

1、頂層邊柱均未設(shè)置彎折，11G101規(guī)定是當(dāng)采用柱外搭接時(shí)，柱外側(cè)可不彎折，但柱內(nèi)側(cè)鋼筋當(dāng)梁高度小于錨固時(shí)均要求彎折。

2、頂層中柱彎折，頂層中柱縱筋如果在梁內(nèi)滿足直錨就不需要彎折。

3、柱梁節(jié)點(diǎn)箍筋未設(shè)置或間距太大。柱梁節(jié)點(diǎn)是核心節(jié)點(diǎn)，是抗震的關(guān)鍵節(jié)點(diǎn)，寧可少放梁縱筋也不能省掉梁柱節(jié)點(diǎn)內(nèi)的箍筋。

4、柱縱筋沒有長(zhǎng)短交錯(cuò)，這是鋼筋翻樣問題，對(duì)柱上下鋼筋根數(shù)發(fā)生變化時(shí)沒在下層調(diào)整豎向鋼筋長(zhǎng)度，導(dǎo)致接頭未能錯(cuò)開。

5、柱保護(hù)層未滿足最小保護(hù)層厚度。

6、有的暗柱很長(zhǎng)，暗箍筋采用U形，增加鋼筋接頭，應(yīng)該是封閉式箍筋，可節(jié)約鋼筋。

7、暗柱箍筋有內(nèi)折角，這是不允許的。兩個(gè)箍筋相交或錨固形成的角度不屬于內(nèi)折角。

8、無(wú)地下室柱加密從正負(fù)零以上H0/3，應(yīng)該是從基礎(chǔ)頂面開始算起。

三、墻常見錯(cuò)誤

1、墻水平筋（外側(cè)與內(nèi)鍘）在同一位置搭接，沒有按接頭百分率錯(cuò)開接頭。

2、墻水平筋接頭未設(shè)置在受力最小處。外墻外側(cè)水平鋼筋應(yīng)位于跨中三分之一或墻高四分之一區(qū)域，外墻內(nèi)側(cè)應(yīng)位于支座及支座附近。

3、地下室外墻豎向鋼筋接頭位置錯(cuò)誤，根據(jù)規(guī)范外墻外側(cè)豎向鋼筋應(yīng)位于墻高中間的三分之一區(qū)域，外墻內(nèi)側(cè)豎向縱筋應(yīng)位于墻高根部的四分之一區(qū)域。

4、外墻外側(cè)鋼筋頂模，無(wú)保護(hù)層，外墻外側(cè)鋼筋露筋后果很嚴(yán)重，最終把整個(gè)外墻破壞掉。外墻外側(cè)是直接接觸泥土和水，保護(hù)層不少于40mm。

5、結(jié)構(gòu)總說(shuō)明未注明頂板是外墻的簡(jiǎn)支承還是彈性嵌固支承，施工也沒按照其施工，外墻縱筋彎折按墻厚減保護(hù)層，不知施工依據(jù)什么，還是想當(dāng)然。

6、墻縱向鋼筋搭接長(zhǎng)度過(guò)長(zhǎng)，直接按墻高度。墻封頂時(shí)墻豎向鋼筋應(yīng)該是減去下面預(yù)留長(zhǎng)度再加搭接長(zhǎng)度。

7、墻拉筋綁扎不規(guī)范，要么間距不對(duì)，要么做法不對(duì)，如沒拉住墻水平筋，要么拉筋長(zhǎng)度不對(duì)，施工時(shí)不是垂直拉而是斜拉。

四、梁常見錯(cuò)誤

1、梁支座鋼筋包括第一排支座負(fù)筋伸入支座均為L(zhǎng)0/4（設(shè)計(jì)問題）。

2、主次梁交接處，主梁兩側(cè)增加附加箍筋。主梁在次梁位置未布置正常箍筋，直接布三道附加箍筋。

3、梁底筋一般都未綁扎。工人的借口是綁不到，其實(shí)是完全可以綁到的，先把梁抬高，用鋼管支架固定，待梁上下鋼筋包括腰筋全部綁扎完成后再把梁落下去就是，這是簡(jiǎn)單的施工工藝。不綁屬于偷工減料，不綁，梁鋼筋糾結(jié)在一塊，影響其受力。

4、梁拉鉤施工按一端90度，一端135度，應(yīng)該都為135度，當(dāng)然拉鉤兩端都加工成135度不好放，可以先一端加工成90度，待綁扎完后再用扳手彎成135度。

5、非抗扭的非框架梁下部縱筋伸入支座為錨固長(zhǎng)度，平法要求12d，這完全是無(wú)謂的浪費(fèi)。

6、梁洞口周圍未布置鋼筋。規(guī)范嚴(yán)禁在梁上開洞，但也不可避免要在梁上開洞，補(bǔ)救措施就是對(duì)洞口進(jìn)行加強(qiáng)。

7、梁接頭沒有設(shè)置在受力較小處（上部縱筋為跨中三分之一區(qū)域），而是設(shè)在受力最大處，有的把梁上部鋼筋設(shè)在梁支座處或附近。

8、屋面梁上部縱筋彎曲內(nèi)徑不符合規(guī)范，規(guī)范要求>6d,8d，不過(guò)，這個(gè)一般是做不到。

9、吊筋按次梁高度施工，應(yīng)該是按主梁高度施工。

10、梁墊塊做法不對(duì)，墊塊強(qiáng)度不夠而粉碎，導(dǎo)致梁直接與模板接觸，露筋無(wú)疑；有的用橫筋直接支承在板上。

11、梁拉筋漏放或斜放，有的沒綁扎，起不到拉筋作用。

12、梁二排鋼筋位置不對(duì)，離梁頂距離過(guò)大，起不到受力作用。

13、梁上部鋼筋采用綁扎接頭卻未在接頭位置加密箍筋，按規(guī)范要求在接頭位置設(shè)置橫向箍筋，間距為min(5d,100)，實(shí)際是很難做到，如果按規(guī)范做，幾乎變成全加密。梁縱筋最好采用機(jī)械連接或焊接（非電渣壓力焊），這樣，就不需要對(duì)接頭進(jìn)行箍筋加密了。

14、梁上部鋼筋間距過(guò)密，混凝土澆筑困難。

15、幾個(gè)方向梁相交重疊，梁上部鋼筋無(wú)保護(hù)層甚至超過(guò)梁高度，這種情況可以把次梁上部縱筋放在主梁上部縱筋之下解決之。

16、非框架梁是非抗震，其箍筋無(wú)需彎成135度，平直段也無(wú)需10d。如果非框架梁設(shè)計(jì)是按非抗震考慮，其箍筋的彎鉤可做成90度，平直段長(zhǎng)度為5d。

五、板常見錯(cuò)誤

1、板筋的搭接長(zhǎng)度過(guò)長(zhǎng)。

2、板上部鋼筋接頭位置錯(cuò)誤，板上部鋼筋接頭應(yīng)在跨中，卻設(shè)置在支座。

3、板接頭百分率50%。未按25%施工。

4、板下部縱筋伸入支座長(zhǎng)度未按規(guī)范，按全支座施工，規(guī)范為max(5d,b/2)

5、板上部縱筋伸入支座La，實(shí)際施工不管支座有多寬均按伸入支座對(duì)邊彎折15 d，當(dāng)支座寬度不能滿足錨固長(zhǎng)度時(shí)才需要彎折15d，如果滿足且支座很寬，板上部鋼筋可以彎折，但彎折長(zhǎng)度加在支座內(nèi)平直段長(zhǎng)度等于錨固長(zhǎng)度即可，沒有必要一定但到支座外側(cè)，因視情況而定。

第三篇：SAT常見錯(cuò)誤總結(jié)

文都國(guó)際教育官方網(wǎng)站：http:// 文都國(guó)際教育官方網(wǎng)站：http://004km.cn/

第四篇：Hadoop常見錯(cuò)誤總結(jié)

Hadoop常見錯(cuò)誤總結(jié) 2010-12-30 13:55 錯(cuò)誤1：bin/hadoop dfs 不能正常啟動(dòng)，持續(xù)提示：

INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:9000.Already tried 0 time(s).原因：由于 dfs 的部分文件默認(rèn)保存在tmp文件夾，在系統(tǒng)重啟時(shí)被刪除。解決：修改core-site.xml 的 hadoop.tmp.dir配置文件路徑：/home/hadoop/tmp。

錯(cuò)誤2：hadoop出現(xiàn)了一些問題。用$ bin/hadoop dfsadmin-report 測(cè)試的時(shí)候，發(fā)現(xiàn)dfs沒有加載。顯示如下：

Configured Capacity: 0(0 KB)Present Capacity: 0(0 KB)DFS Remaining: 0(0 KB)DFS Used: 0(0 KB)DFS Used%: ?% Under replicated blocks: 0 Blocks with corrupt replicas: 0 Missing blocks: 0 查看日志：

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Incompatible namespaceIDs in /home/hadoop/data: namenode namespaceID = 2033006627;datanode namespaceID = 1589898341 經(jīng)分析，是由于namenode namespaceID = 2033006627;和datanode namespaceID = 1589898341 不一致造成原因。

修改了namenode namespaceID = 1589898341 可以使用，但是重啟之后，又不可以用了。

最后解決方案：刪除hadoop用戶下的name文件夾，data文件夾，tmp文件夾，temp文件里的內(nèi)容，然后重新執(zhí)行namenode命令。重啟電腦之后，正常。

錯(cuò)誤3：File /home/hadoop/tmp/mapred/system/jobtracker.info could only be replicated to 0 nodes, instead of 1 出現(xiàn)此錯(cuò)誤，一般發(fā)生在datanode與namenode還沒有進(jìn)行連接，就開始往hdfs系統(tǒng)上put數(shù)據(jù)了。稍等待一會(huì)，就可以了。

也可以使用：hadoop dfsadmin –report命令查看集群的狀態(tài)。錯(cuò)誤4：

每次啟動(dòng)總有部分datanade不能去全部啟動(dòng)，查看日志文件，顯示為： ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.net.UnknownHostException: zgchen-ubutun: zgchen-ubutun at java.net.InetAddress.getLocalHost(InetAddress.java:1426)。分析：這是由于datanode 找不到服務(wù)host引起的。

解決：通過(guò)查找/etc/hostname 找到hostname；比如：ubuntu。然后找到/etc/hosts，添加：127.0.1.1 ubuntu 錯(cuò)誤5：

java.lang.OutOfMemoryError: GC overhead limit exceeded 分析：這個(gè)是JDK6新添的錯(cuò)誤類型。是發(fā)生在GC占用大量時(shí)間為釋放很小空間的時(shí)候發(fā)生的，是一種保護(hù)機(jī)制。解決方案是，關(guān)閉該功能，可以添加JVM的啟動(dòng)參數(shù)來(lái)限制使用內(nèi)存：-XX:-UseGCOverheadLimit 添加位置是：mapred-site.xml 里新增項(xiàng)：mapred.child.java.opts 內(nèi)容：-XX:-UseGCOverheadLimit java.lang.OutOfMemoryError: Java heap space 出現(xiàn)這種異常，明顯是jvm內(nèi)存不夠得原因，要修改所有的datanode的jvm內(nèi)存大小。

Java-Xms1024m-Xmx4096m 一般jvm的最大內(nèi)存使用應(yīng)該為總內(nèi)存大小的一半，我們使用的8G內(nèi)存，所以設(shè)置為4096m，這一值可能依舊不是最優(yōu)的值。（其實(shí)對(duì)于最好設(shè)置為真實(shí)物理內(nèi)存大小的0.8）

錯(cuò)誤6：Too many fetch-failures Answer: 出現(xiàn)這個(gè)問題主要是結(jié)點(diǎn)間的連通不夠全面。1)檢查、/etc/hosts 要求本機(jī)ip 對(duì)應(yīng) 服務(wù)器名

要求要包含所有的服務(wù)器ip + 服務(wù)器名 2)檢查.ssh/authorized_keys 要求包含所有服務(wù)器（包括其自身）的public key 錯(cuò)誤7：處理速度特別的慢出現(xiàn)map很快但是reduce很慢而且反復(fù)出現(xiàn) reduce=0% Answer: 結(jié)合第二點(diǎn)，然后修改可用內(nèi)存大小。

conf/hadoop-env.sh 中的export HADOOP_HEAPSIZE=4000 錯(cuò)誤8：能夠啟動(dòng)datanode，但無(wú)法訪問，也無(wú)法結(jié)束的錯(cuò)誤

在重新格式化一個(gè)新的分布式文件時(shí)，需要將你NameNode上所配置的dfs.name.dir這一namenode用來(lái)存放NameNode 持久存儲(chǔ)名字空間及事務(wù)日志的本地文件系統(tǒng)路徑刪除，同時(shí)將各DataNode上的dfs.data.dir的路徑 DataNode 存放塊數(shù)據(jù)的本地文件系統(tǒng)路徑的目錄也刪除。如本此配置就是在NameNode上刪除/home/hadoop/NameData，在DataNode上刪除/home/hadoop/DataNode1和/home/hadoop/DataNode2。這是因?yàn)镠adoop在格式化一個(gè)新的分布式文件系統(tǒng)時(shí)，每個(gè)存儲(chǔ)的名字空間都對(duì)應(yīng)了建立時(shí)間的那個(gè)版本（可以查看/home/hadoop /NameData/current目錄下的VERSION文件，上面記錄了版本信息），在重新格式化新的分布式系統(tǒng)文件時(shí)，最好先刪除NameData 目錄。必須刪除各DataNode的dfs.data.dir。這樣才可以使namedode和datanode記錄的信息版本對(duì)應(yīng)。

注意：刪除是個(gè)很危險(xiǎn)的動(dòng)作，不能確認(rèn)的情況下不能刪除！做好刪除的文件等通通備份！

錯(cuò)誤9：java.io.IOException: Could not obtain block: blk_***469_1100 file=/user/hive/warehouse/src_20100924_log/src_20100924_log 出現(xiàn)這種情況大多是結(jié)點(diǎn)斷了，沒有連接上?；蛘?/p>

mapred.tasktracker.map.tasks.maximum 的設(shè)置超過(guò) cpu cores數(shù)目，導(dǎo)致出現(xiàn)獲取不到文件。

錯(cuò)誤10：Task Id : attempt_201010291615_0001_m_000234_0, Status : FAILED Error: java.io.IOException: No space left on device Task Id : attempt_201010291615_0001_m_000240_0, Status : FAILED java.io.IOException: Spill failed 磁盤空間不夠，應(yīng)該分析磁盤空間df-h 檢查是否還存在磁盤空間。錯(cuò)誤11:Task Id : attempt_201011011336_0007_m_000001_0, Status : FAILED org.apache.hadoop.hbase.client.RegionOfflineException: region offline: lm，1288597709144 網(wǎng)上說(shuō)，將/hbase刪除；重啟hbase后，可以正常應(yīng)用了。但是我找不到/hbase目錄，只好自己重新刪除掉一些hadoop文件，重新生成文件管理系統(tǒng)。

還有一個(gè)可能是，配置錯(cuò)了/hbase/conf/hbase-env.sh的HBASE_CLASSPATH，這個(gè)默認(rèn)是不配置的，所以可以不配置。

錯(cuò)誤12：org.apache.hadoop.hbase.TableNotFoundException: org.apache.hadoop.hbase.TableNotFoundException: lm 找不到表，hbase啟動(dòng)了，檢查一下是否存在需要的Htable。