admin 管理员组

文章数量: 1184232
To know how to deal with it, we need to discuss the basics first. The filesystem type is recorded at least in two separate places
  • In the partition table ( MBR , sometimes referred to as a legacy-style partition ) or in the LDM database (when dynamic disks are used).
  • In the volume boot sector .

Three significantly different combinations are thus possible.

  • Both partition table and volume boot sector provide consistent information about the filesystem type. This is how the things are supposed to be when the volume is online and operational.
  • Only one of these places contains proper information, or the information is contradictory (e.g. partition table lists the volume as NTFS, while the boot sector indicates it is the FAT32).
  • Neither partition table nor volume boot sector contain filesystem type information (the partition table will in this case indicate the special filesystem type of zero, i.e. unused volume). This can happen during normal operation and is pretty legal configuration state. It appears when you create a volume (e.g. using Disk Management applet) but do not format it at the same time. You can even assign a drive letter to this unformatted volume, as illustrated below (notice the underlined "H:" drive which has no filesystem type defined).

If the volume filesystem type information is unavailable, attempting CHKDSK against the volume will result in the following message:

The type of the filesystem is RAW.
CHKDSK is not available for RAW drives.

Sometimes, the volume fails in such a way that it becomes RAW. In most cases the failure will be associated with a sudden reboot (per power failure or the STOP error). Several causes are possible: partition table, LDM database, or the volume boot sector corruption, or (on the NTFS volume) when certain records in both MFT and MFT mirror are damaged beyond easy recognition.

"RAW filesystem" recovery expectations

The data recovery should not be complicated because the volume location info is still available. Be advised that some arbitrary filesystem type may be associated with the volume when you attempt to identify it amongst the list of the available volumes.

Notice the highlighted volume - it is the same H: volume featured in the earlier screenshot. It has the correct size (128MB) and the correct on-disk location (starting at 200+40+40 = 280MB from the start of disk), but the filesystem type of "Large FAT16" is not a good bet because the volume is in fact NTFS - the filesystem type information in the LDM database got corrupt (yeah, I know because I did it in purpose). This fact will be later discovered by ZAR and the appropriate decision will be made to treat the volume as NTFS, and in this test case an exact recovery is ultimately achieved.

In a real world case, the recovery expectations vary depending on the damage profile and locality. Overall, I'd expect a good yield. Exact recovery is possible if the damage is confined to the boot sector(s) and/or partition table (however there is no easy way to tell if it is). Suggested course of action is thus as usual: to download our data recovery tool ( ) and try it. Be sure to check as well.

TraceBack:

注：今天本来想查点RAW FileSystem的资料，无意中找到这篇关于RAW FileSystem恢复的，还算得上是一篇资料文章哦，所以就转贴过来了！~

本文标签： 面对 难题 如何找回

版权声明：本文标题：面对RAW FileSystem难题, 如何找回那些珍贵的Flash资源与配置？ 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/b/1771566549a3546076.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。