題:
如何識別和修復磁盤塊損壞/無法訪問的文件
MrCranky
2014-04-29 02:09:50 UTC
view on stackexchange narkive permalink

我有一台2011年末的Macbook Pro,運行Mavericks 10.9.2。它唯一的HDD是750GB驅動器,採用Bootcamp格式化。它仍然運行得相當好,但是在運行碎片整理程序時,我發現有很多文件被碎片整理程序(iDefrag)拒絕移動。

iDefrag報告了POSIX訪問文件時錯誤代碼為5。隨機選擇一個文件並嘗試將文件複製到外殼中的另一個位置也會報告錯誤,這使我認為問題是真實的,並且與磁盤/ FS有關。 cp的輸出為:

cp:unity_nophysx.nexe:輸入/輸出錯誤

據我所知,錯誤代碼5為“訪問被拒絕”知道,但是碎片整理進程是以管理員身份運行的,並且在可疑文件上使用sudo運行cp沒什麼區別。

Disk Utility,fsck和Apple Hardware Test都聲稱該磁盤可以正常使用。沒有報告SMART錯誤,儘管有一些權限錯誤,但它們與iDefrag抱怨的文件無關,並且Disk Utility聲稱已對它們進行了修復而沒有任何抱怨。

可能有一百多個或更多損壞的文件,但仍然只是驅動器的一小部分。據我所知,沒有系統文件或關鍵數據受到影響。雖然可以很好地檢索數據,但我不介意重新安裝或進行備份。在這一點上,我不知道這是否真的是驅動器快要死了,僅僅是由於寫入時移動了驅動器而導致的一些壞扇區,還是可以解決的其他一些輕微損壞。我假設最壞的情況是,最有可能的是,我將不得不獲得一個稍大的HDD並克隆現有驅動器,以避免必須重建系統。

我的問題確實是如何將那些損壞的文件標記為正確的損壞並修復或清除它們,以便磁盤克隆成功但不會掛在文件上/阻止它無法訪問。 “磁盤工具”沒有發現問題,我不知道可以完成此工作的任何命令行或第三方工具。我不想註銷整個磁盤並從頭開始,因為該驅動器似乎還很健康,所以我正在尋找維修/診斷工具。

我建議您閱讀有關SuperUser的非常詳細的類似討論:http://superuser.com/q/148227。
不幸的是,我在運行狀況良好的磁盤上進行了測試:),http://www.volitans-software.com/smart_utility.php。它看起來像一個非常簡單且嚴肅的工具。您可以嘗試一下,最值得注意的是檢查“重新分配的扇區”計數器。
七 答案:
dan
2014-05-10 16:03:17 UTC
view on stackexchange narkive permalink

如果您正面臨一個結構良好的文件系統,並且想要查找磁盤錯誤塊的文件,請按照以下步驟操作:

  1. 使用 Time Machine Carbon Copy Cloner

    對磁盤進行完整備份。

  2. 運行以下繁重而冒險的命令(以防萬一您在文件系統結構之外有壞塊)(確保引號{}使包含空格的文件名起作用):

      find /-輸入f -print -exec dd if =“ {}” of = / dev / null bs = 1m \;  
  3. ol>

    這個很重的 find 命令將為任何普通文件打印其名稱(因此不讀取它,而僅顯示其目錄條目),然後繼續完整而快速地讀取其所有數據塊。

    點擊第一個文件包含壞塊,此 find 將導致內核將 read error 記錄在 /var/log/system.log 上,或者放慢速度或將系統帶到完全停止。這主要取決於硬盤驅動器的容量,以重新定位其內部池中專門用於此常規修復任務的壞塊。此包含壞塊的文件將是 find 打印的姓氏

    在紙上寫下該文件名!假設該文件名為:

      /。DocumentRevisions-V100 / .cs / ChunkStorage / 0 / 0/0/9  

    在這一點上,您可能可以通過按 ctrl kbd> + C快速殺死 find kbd>。如果無法正常殺死它,只需將您的Mac崩潰即可。

    重新啟動Mac後,直接檢查包含壞塊的文件:

      dd if ='/。DocumentRevisions- V100 / .cs / ChunkStorage / 0/0/0/9'of = / dev / null bs = 1m  

    如果命令正確終止,則錯誤對於您的磁盤而言足夠輕才能讀取此文件並重新分配壞塊。

  • 如果命令未終止,則無法將其殺死。 通常,您的數據會完全丟失,並且您將不得不使Maconce更崩潰。

在後一種情況下,您必須考慮更換磁盤並從中進行操作最後備份。其他一些文件也可能包含壞塊,只要您不讀取它們,很長時間以來就一直未被發現。

內核不會在從未讀取過的塊上引發讀取錯誤。

啊哈,這絕對是我想要的技巧。首次執行find / dd腳本會觸摸磁盤上的所有文件/塊,並確保我找到了一堆出現“輸入/輸出錯誤”的文件,並且我可以簡單地將命令日誌輸出到文件中,然後用grep找出duff裡面的文件。dd命令本身並不足以觸發任何自動修復(我什至不知道OS X會這樣做),但至少它給了我一個可靠的選擇識別文件的方法。
從好的方面來說,當操作系統嘗試從具有這些壞塊的文件中讀取數據時,它不會崩潰或嚴重掛斷。我看到“ 5月10日20:42:15 ICE內核[0]:disk0s2:I / O錯誤。”在日誌中彈出,但是不知道是哪個文件觸發了它。但是隨後命令運行得很愉快。
您的內核不會與BBFH掛起,因為您的磁盤池中仍然有足夠的可用塊來修復壞塊。 dd並不能解決任何問題,此命令的目的是複制數據並儘可能快地對其進行轉換。磁盤仍然能夠修復輕微錯誤。請注意,磁盤的價格不會影響您的工作。
嗯,是的,我假設:dd只是一個愚蠢的工具,可以將所有數據從一個文件中刪除,然後將其放置在其他位置(在我們的情況下為稀疏文件)。真正重要的是讀取與文件關聯的每個塊。在這種情況下,我沒有得到OS X的期望。顯然,內核無法讀取這些壞塊,但是您認為磁盤本身可以並且可以修復它們嗎?如果無法從原始壞塊中獲取數據,該如何將其轉移到其他地方?
很好的問題。磁盤將自動在讀取塊上重試。每次頭部位置在機械上處於不同位置。如果此嘗試之一成功,則將數據複製到可用於修復故障塊的塊之一上。壞塊被標記為壞塊,將不再使用。另一方面,如果所有重試均失敗,則不會保存數據,並且在很長一段時間後,磁盤將標記該塊為壞塊,並為可見磁盤分配一個新的空磁盤。內核將報告不可恢復的磁盤錯誤。
鑑於我所看到的,重試都失敗了,內核報告了IO錯誤,但是文件仍然不可訪問(大概是因為將新的空塊放在其位置沒有意義,因為那樣會損壞文件數據,並且沒有任何提示發生)。您將遇到一個不可恢復的磁盤錯誤,然後每次訪問都會靜默返回損壞的數據。但是,如果知道它曾經發生過一次,我不明白的是為什麼OS X不會將其保存到duff文件列表中,並且有一個維護工具可以告訴您其中一些不好,請您自行修復!
Matt
2014-04-29 03:33:51 UTC
view on stackexchange narkive permalink

通過在引導過程中按住 Command kbd> + S kbd>來以單用戶模式重新引導。當看到提示時(看起來像 root#或類似的名稱),鍵入 fsck -f 並按 Return kbd>。這是Mac內置的文件系統一致性檢查工具,可讓您查找和修復啟動文件系統中的錯誤。運行此命令,直到看不到 **卷[volume name]被修改。** 或該工具連續三次失敗。

如果該工具失敗,則可能表明存在更大的問題(但如果不查看工具的輸出,我無法告訴您什麼)。無論如何,在運行任何磁盤工具之前,請確保已備份所有內容。完成後,在提示中輸入 reboot 並按Enter鍵(您猜對了!)重新啟動計算機。

有關其他信息,請參見fsck手冊頁這裡

有趣的是,但即使使用-f且在單用戶模式下,它看起來也非常類似於fsck,它正在執行Disk Utility的操作。與“磁盤工具”一樣,它什麼也沒找到,並認為磁盤就可以了。我以為它正在掃描文件系統記錄,但是我認為我的問題是在塊級別上-即文件系統結構良好,但是在讀取文件時無法訪問文件中的實際數據/複製/整理碎片。
→MrCranky:對! fsck和Disk Utility正在檢查文件系統結構的完整性,它們讀取分配給文件系統結構的磁盤塊。它們不是為了驗證數據塊的完整性而設計的,因此它們可以在具有故障塊的磁盤上運行而不會引起任何讀取錯誤。如果要檢查磁盤,即使是可能有故障但實際上未使用的塊,也只需使用基本工具即可作為`dd if = / dev / disk0 of = / dev / null ibs = 1k`並在另一個shell窗口中運行`tail -f / var / log / system.log`。這是免費的,極端的並且不會隱藏您任何錯誤。
Adam
2014-04-29 04:09:43 UTC
view on stackexchange narkive permalink

我強烈建議DiskWarrior用於重建磁盤目錄和掃描可能損壞的文件

在目錄重建期間,它還可以通知您是否由於磁盤故障而延遲。

我不願意購買一個工具來提供幫助,但是無需試用,也不能保證該工具甚至旨在發現我遇到的錯誤,因此,在獲得幫助之前,我需要更多的建議來備份您的工具準備在工具上投入100美元。
-1不僅是答案,還包括評論和答案。
awiebe
2017-07-14 01:04:34 UTC
view on stackexchange narkive permalink

要解決Buscar的答案,您可以使用一些非常繁瑣的命令行foo自動執行此操作。

  sudo find / -type f -print0 |xargs -0 -I {} dd if ='{}'of = / dev / null bs = 1m 2>&1 |grep'錯誤'>>badfiles.txt &
 
  • sudo:管理模式
  • 找到-print0:絕對路徑
  • xargs -0 -I {}:在下一條命令中替換{}
  • dd 2> &1:將標準錯誤重定向到標準輸出
  • 將管道標準輸出到grep以查找字符串錯誤
  • 將結果追加到列表文件中。(note:如果您認為內部驅動器存在問題,則應該在外部介質上)
Ruskes
2014-05-08 23:34:21 UTC
view on stackexchange narkive permalink

正如您所說,甚至不清楚這些文件是否已損壞,至少您的Mac認為不是。

每個操作系統都會生成其操作所需的不可移動文件(還原點,當前處於活動狀態)文件等...。)。有些碎片會顯示出來,有些則不會。

您無法訪問或移動它們的事實並不意味著它們已損壞。

通常Mac可以很好地處理

使用Apple維護方法是:打開終端並輸入:

  sudo週期性每天每週每月 

按回車鍵,輸入管理員密碼,OS X將為您處理所有事情。

在控制台中查找有關您感興趣的報告。

在在控制台中查找(搜索)任何表明磁盤開始出現問題的I / O錯誤,以補充Disk Utility和fsck的發現。

有時我會使用一個免費的工具,稱為 OnyX用於其他維護任務。它是用法語製作的,而且食物很美味:)

OnyX是OS X的多功能實用程序,它使您可以驗證啟動磁盤及其係統文件的結構,從而運行系統維護的其他任務,以配置Finder,Dock,QuickTime,Safari,Mail,iTunes,登錄窗口,Spotlight和許多Apple應用程序的一些隱藏參數,以刪除緩存,刪除一定數量的文件和文件夾 sub>

說了這麼多,我不質疑您決定使用碎片整理程序(iDefrag),因為我不知道它,而是提供其他解決方案。

使用碎片整理程序不是問題,我很清楚OS X在這方面做了什麼和沒有做這些事情。這些文件肯定沒有使用,這些是用於未激活應用程序的數據文件,實際上現在無法移動該應用程序。
在Onyx上,它做的工作比Disk Utility還要多,它檢查磁盤的SMART狀態,然後運行fsck樣式診斷程序(我們已經確定這沒有什麼錯)
明確一點,對於任何其他閱讀此答案的人,文件肯定是**被損壞了,而Mac知道這一點,因為不允許我從它們中讀取(複製它們,無論如何)。那不是因為它們是系統文件,或者不是在使用中,即使對於用戶數據文件也是如此。定期維護並不能解決該問題,這再次是因為像`fsck`一樣,它似乎只關心文件系統問題,而不是阻止可訪問性問題。僅當我手動嘗試從這些損壞的文件之一中復制/讀取數據時,控制台才會顯示錯誤,這對查找它們沒有幫助。
chillin
2014-05-08 23:06:18 UTC
view on stackexchange narkive permalink

聽起來很不合理,在執行任何操作之前,應將所有數據複製到已知的良好驅動器上。如果從安裝程序啟動並複制數據失敗,則有一個名為“ dd”的命令行實用程序可以執行低級複製,並且以一種毫不妥協的方式進行。

  man dd 代碼> 

了解有關dd的更多信息,包括使用和正確的語法。


對Matt的帖子的另一種投票,啟動單用戶模式,然後運行

  fsck -fy  

一遍又一遍,直到fsck停止報告錯誤為止。


對於Adam的一票,DiskWarrior易於使用,但是一個非常強大的應用程序,它將報告HDD故障,檢查單個文件中的錯誤並在可能的情況下對其進行修復,以及重建和優化目錄結構。嘗試使用大量的零散證據來恢復數據的成功方法是,拉動驅動器,使用幾層冷凍袋保護其免受潮氣,然後將其放入冷凍室中30-45分鐘。然後,在驅動器處於冷狀態時,將該驅動器安裝在外部USB擴展塢中,並使用另一個臨時系統再次嘗試將損壞的數據複製到另一個驅動器。通常,如果出現硬件問題並且驅動器發生故障,則使用此方法。如果您可以在不影響數據的情況下複製整個驅動器,那麼這是理想的選擇,因為重新分區和重新格式化通常會使驅動器獲得新的使用壽命。

就像我說過的那樣,fsck不會報告任何錯誤。磁盤尚未出現氣質或報告隨機錯誤,並且損壞的文件列表似乎沒有增加,因此我不相信我在附近“最後一次緊急凍結”階段。正如我在問題中所說,我也已經很好地備份了文件/文件夾級別,並且不擔心丟失數據。很高興聽到DiskWarrior的另一票。
@MrCranky:我相信您是在更新問題之前引用了一些內容;對於任何發現此頁面尋求類似症狀的解決方案的人,我都會加強fsck的想法。關於我發布的有關HDD故障的任何內容,對其他人(不一定是您本人)再全面地介紹也無濟於事。我已經看到了相當一部分硬盤故障。即使使用SMART技術,通常也沒有故障的跡象,直到您無法以任何方式訪問數據為止。如果您關心數據,強烈建議您購買一個新驅動器,然後備份數據。
我當然不同意有關備份的建議,但是Q&A格式的精神是回答所提出的問題,而不是一般性的“如何修復損壞的磁盤”問題(其中有很多)。在我對其進行編輯以將“ fsck”添加到“認為磁盤正常的事物”列表之前,我已經回答了回答問題“ fsck”,以降低其實用性。 “ fsck”和“磁盤工具”執行的功能大體相同,即在文件系統結構上運行,而不是在塊級別上運行。我確實嘗試明確指出這是一個塊問題,而不是文件系統問題。
bleater
2016-02-29 06:01:03 UTC
view on stackexchange narkive permalink

對於由於磁盤讀取錯誤而無法完全讀取的單個文件,可以使用 dd 實用程序將文件複製到外部卷,用NUL字節代替塊無法讀取。強烈建議將其複製到其他卷(例如下面的示例中的“ USB磁盤”)。

示例:

  dd if = /路徑/到/損壞的文件= /卷/ USB \磁盤/文件bs = 512 conv = noerror,sync
 

通過使用512字節塊,將恢復最大數量的可讀塊。

恢復可能需要很長時間,因為每次讀取失敗後內核都會阻塞一段時間。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...