阅读:1724回复:2
NTFS中的DirtyBit设置时机
看文章说NTFS对Dirty Bit设置是在只有出现严重的数据不一致,同时无法根据日志功能进行修复时才进行的。
我想问,这种不一致CHECK等功能是实时做的,还是关机的时候做的? |
|
沙发#
发布于:2008-08-09 15:30
可以参考《走近文件系统系列二:探索Dirty Bit的奥秘》一文,转载自盆盆的博客
图片没有贴,详见原文 很多用户发现,同样是非法关机,重启时有些系统会自动进行磁盘检测(通常是FAT文件系统),而有些系统则照常启动(通常是NTFS文件系统)。 为什么? 原来不同的文件系统,对于Dirty Bit的设置方法有所区别,这种区别可以套用法律术语来类比: (1) FAT相当于大陆法体系,实行的是“有罪推定”。在写入数据前,首先假设文件系统是“有罪”的──设置Dirty Bit为1。只有确认数据操作完成以后,才将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.实验步骤 由于Windows对NTFS的元数据文件进行保护,所以我们无法直接在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属性,现将该属性单独截图如下。第三方最左侧的两个字节(offset为32-33)定义了NTFS文件系统的版本号,本例中的值为03 01,代表NTFS 3.1版(Windows XP是3.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命令并没有认可我们的手动设置,但是实际还是生效的。 |
|
|
板凳#
发布于:2008-08-09 15:32
不一致的Check好象是是实时处理的,记得在《数据恢复技术》里看到过
|
|
|