关闭

走近文件系统系列二:探索Dirty Bit的奥秘

2976人阅读 评论(0) 收藏 举报

走近文件系统系列二:探索Dirty Bit的奥秘

在微软知识库文章KB322275上看到如下的一段话:

The "dirty" bit is a bit in the boot sector (for FAT or FAT32 volumes), or in the MFT (for NTFS volumes), that is checked when Windows starts.

这说明,在FAT文件系统里,Dirty Bit在分区的引导扇区(Boot Sector)中指定;而在NTFS文件系统里,则是在MFT中指定(实际上是$Volume元数据文件)。

作为一名IT Pro,自然不仅仅满足于知道以上的结论。本着“绝知此事要躬行”的精神,本文介绍如何通过工具,找出在$Volume元数据文件中的哪个地方定义了这个Dirty Bit

名词解释

什么是Dirty Bit?它实际上是文件系统的一个错误状态位,Windows启动时会根据这个状态位来判断文件系统是否出了故障,以确定是否要运行Chkdsk /F来进行磁盘修复。

行为差别

很多用户发现,同样是非法关机,重启时有些系统会自动进行磁盘检测(通常是FAT文件系统),而有些系统则照常启动(通常是NTFS文件系统)。

为什么?

原来不同的文件系统,对于Dirty Bit的设置方法有所区别,这种区别可以套用法律术语来类比:

(1) FAT相当于大陆法体系,实行的是“有罪推定”。在写入数据前,首先假设文件系统是“有罪”的──设置Dirty Bit1。只有确认数据操作完成以后,才将Dirty Bit设置为0,如果非法关机时,Dirty Bit可能还保留为1,则下次开机会自动进行磁盘扫描。

(2) NTFS相当于英美法体系,实现的是“无罪推定”。只有出现严重的数据不一致,同时无法根据日志功能进行修复,这时候才会将Dirty Bit设置为1

实验过程

1.工具箱

(1) Winhex:本文将用该工具查看、修改$Volume元数据文件。
      下载地址:
http://www.x-ways.net/winhex/index-m.html

(2) Fsutil:该命令行工具可以对文件系统进行全方位的管理,本文将用该工具管理NTFS文件系统的Dirty Bit设置,然后借助WinHex来获知磁盘数据的底层信息。
      
Windows XP/2003自带,对于Windows 2000,可以直接借用XP下的工具。

2.实验步骤

由于WindowsNTFS的元数据文件进行保护,所以我们无法直接在Windows系统里访问$Volume,但是我们可以借助第三方磁盘工具Winhex绕开这个系统限制,来达到目的。

在这个实验里,我们借助Winhex访问NTFS卷的$Volume文件,以确认Dirty Bit到底对应$Volume文件的哪个地方。

(1) Winhex打开任意一个卷,例如D盘,即可看到D盘里的所有元数据文件,例如$MFT$MFTMirr$Volume等文件。双击其中的$Volume即可打开该文件。

(2) 大家知道,每个NTFS文件都是由若干属性所组成。$Volume 文件具有两个独有的属性,$VOLUME_NAME$VOLUME_INFORMATION。其中卷标是由$VOLUME_NAME定义,而Dirty bit则是由$VOLUME_INFORMATION属性所定义的。$VOLUME_INFORMATION属性如下图所示,开头的值70H表示该属性的类别,offset 4的值28H定义该属性的长度,相当于十进制的40

(3) 为了清楚的标识$VOLUME_INFORMATION属性,现将该属性单独截图如下。第三方最左侧的两个字节(offset32-33)定义了NTFS文件系统的版本号,本例中的值为03 01,代表NTFS 3.1版(Windows XP3.1版本,而Windows 2000则是3.0)。

(4) 为了找出Dirty Bit到底在哪里,我们可以借助Fsutil命令人为地制造一个Dirty Bit。在命令提示符下运行以下命令:

Fsutil dirty set D:

刷新Winhex的视图,可以看到$VOLUME_INFORMATION属性的值出现了变化,如下图所示。

可以得出这样的猜想:offset 34的字节定义了NTFS文件系统的Dirty Bit设置情况,当该值为01时,代表NTFS文件系统设置了Dirty Bit

3.逆向验证

为了证实这个结果,需要进行逆向验证。可以将$VOLUME_INFORMATION属性中Offset 34字节的值直接修改为01,看看是否相当于设置Dirty Bit的状态位。

(1) 直接在Winhex里修改Offset 34字节的值,将其设置为01,同时保存所做的设置。

(2) 然后在命令提示符下运行以下命令,查看Dirty Bit的设置状态:

Fsutil dirty query D:

出乎意料的是,命令查询的结果是“卷 - D: 没有损坏”,也就是说Fsutil命令并不认为文件系统设置了Dirty Bit

(3) 单击开始→关闭计算机→重新启动,发现系统开始自动扫描。看来尽管Fsutil命令并没有认可我们的手动设置,但是实际还是生效的。

4.疑难解答

(1) 为什么Fsutil命令无法查询手动设置Dirty Bit

可能的答案是,在系统Mount分区的时候,先将重要的元数据文件(包括$Volume)读到内存里,而Fsutil命令会从内存里(而不是磁盘里)读取Dirty Bit的设置情况。手动修改$Volume后,系统并没有重新将新的$Volume读入内存,所以Fsutil命令无法查询Dirty Bit的设置情况。

(2) 如何才能迫使系统重新读入元数据文件?

可以尝试在“磁盘管理”管理单元里删除该卷的盘符(本例为D:),然后重新恢复盘符。设置以后,Fsutil命令果然可以正确读取Dirty Bit的状态了。

(3) 手动设置Dirty Bit,重启系统后会自动运行Chkdsk /F,为什么会提示元数据文件$MFTMirr错误?

$MFTMirr保存着$MFT中前面四个文件记录,其中包括$Volume。前面的实验过程并没有同步修改$MFTMirr中的$Volume,导致两者记录不一致。

实用价值

当然,本文提到手动设置Dirty Bit的方法只是为了实验验证,并没有真正的应用价值,我们没有必要采用这种方法进行手动设置。

明明是正常关机,但是每次开机时会自动询问是否扫描磁盘。遇到这种问题,可以按照以下步骤进行处理(参考KB160963):

(1) 运行Fsutil dirty query DriveLetter命令,检查该磁盘是否设置了Dirty Bit。如果是的话,可能是硬盘本身的问题,请联系硬盘厂商或者计算机经销商进行检测。

如果需要防止系统自动检测标记Dirty Bit的卷,可以运行以下命令进行排除:

chkntfs /x DriveLetter

(2) 检查任务计划、启动项里有没有相应的加载项,有的话删除即可。

(3) 打开注册表编辑器,进入以下注册表项:

HKEY_LOCAL_MACHINE/SYSTEM/CURRENTCONTROLSET/CONTROL/Session Manager

检查其下的多字符串键值BootExecute,是否为类似以下的数值数据:

autocheck autochk /r /??/D:

如果是的话,删除其中/r /??/D:即可。

提示

NTFS文件系统里,有一句很著名的话“everything on the disk is a file”,所有的文件系统数据,都是文件,包括MFT、引导扇区、甚至还有安全描述符等。

关于NTFS文件系统的元数据文件的描述,可以参考以下的微软官方文档:

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/8cc5891d-bf8e-4164-862d-dac5418c5948.mspx

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:146262次
    • 积分:1799
    • 等级:
    • 排名:千里之外
    • 原创:31篇
    • 转载:31篇
    • 译文:0篇
    • 评论:35条
    原创部分博文公告
    欢迎交流,欢迎转载;转载请勿篡改内容,并且注明出处,禁止用于商业目的,谢谢!
    文章分类
    最新评论