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

转载 2006年06月19日 10:09:00

走近文件系统系列二:探索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

关于Cache的dirty bit

当cpu往内存里写数据时,首先会写到Cache里,这样就造成了内存和cache中数据的不一致问题,当存此数据的cache要被新的数据取代时,需要把刚才更改的数据回写到内存中。dirty bit就是标记...
  • adrianfeng
  • adrianfeng
  • 2010年09月19日 14:47
  • 3662

windows启动自检显示volume is dirty长时间无法正常启动的解决方法

windows启动自检显示volume is dirty长时间无法正常启动,利用Disk Genius进行修复。...
  • FebWaltz
  • FebWaltz
  • 2017年01月19日 19:08
  • 614

invalidate()函数的区域更新例子

public class FingerView extends View { private static final float STROKE_WIDTH = 5f; /** Need ...
  • androidzhaoxiaogang
  • androidzhaoxiaogang
  • 2013年03月16日 19:53
  • 2315

脏读(dirty read)不可重复读(unrepeatable read)幻读(phantom problem)解析

1. 脏读  首先区分脏页和脏数据 脏页是内存的缓冲池中已经修改的page,未及时flush到硬盘,但已经写到redo log中。读取和修改缓冲池的page很正常,可以提高效率,flush...
  • eddie_520
  • eddie_520
  • 2015年07月29日 08:39
  • 1752

mysql关于bit类型用法

mysql bit
  • u013238950
  • u013238950
  • 2015年12月12日 18:57
  • 12691

java 数据存储 bit

大家都知道在Java 数据存储方式。定1 int = 4 byte, 1 byte = 8 bit。以此推理那么1个int在计算机中就是以4 * 8 = 32位(bit)的方式存储的。 如果创建一个...
  • xiaomin1991222
  • xiaomin1991222
  • 2016年03月10日 16:05
  • 1326

Mysql bit类型带来的坑

对一个表进行创建索引后,开发报告说之前可以查询出结果的查询在创建索引之后查询不到结果: mysql> SELECT count(*) FROM `node` WHERE uid='1655928604...
  • gua___gua
  • gua___gua
  • 2015年07月06日 15:26
  • 8646

ucore lab3实验报告

Lab3实验报告Lab3实验报告 练习0填写以有实验 练习1给未被映射的地址映上物理页 问题回答 练习2补充完成基于FIFO的页面替换算法 问题回答 实验运行截图 扩展练习 Challenge 借助...
  • TH_NUM
  • TH_NUM
  • 2016年04月25日 19:58
  • 1101

SQL Server数据库中bit字段类型使用时的注意事项

SQL Server数据库中bit字段类型使用时的注意事项 本文我们主要介绍了SQL Server数据库中bit类型字段的使用的相关知识以及bit字段类型使用时的注意事项,希望能够对您有...
  • hanghangde
  • hanghangde
  • 2016年01月09日 12:26
  • 2466

C语言Bit位定义

C语言Bit定义注意点: 首先看一个C位域使用的官方例子(摘自MC9S12XS128.h): /*** ATD0CTL45 - ATD 0 Control Register 45; 0x000002...
  • u011329967
  • u011329967
  • 2016年11月02日 22:50
  • 4612
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:走近文件系统系列二:探索Dirty Bit的奥秘
举报原因:
原因补充:

(最多只允许输入30个字)