Close to File System Series 2: Explore Dirty Bit mystery
See the following paragraph on Microsoft Knowledge Base article KB322275:
The "Dirty" bit is a bit in the boot sector, or in the mft (for ntfs volume), That is checked when Windows Starts.
This shows that in the FAT file system, DIRTY BIT is specified in the Boot Sector of the partition; and in the NTFS file system, it is specified in the MFT (actually a Volume metadata file).
As an IT PRO, it is naturally not only satisfied with the above conclusions. In this paper, this article introduces how to find this Dirty bit in this article to find this Dirty bit. This DIRTY bit is defined in which place in the $ Volume metadata file is defined.
Glossary
What is dirty bit? It is actually an error status bit of the file system. When Windows is started, it will determine if the file system has failed when it is to determine whether to run CHKDSK / F.
Behavior difference
Many users have found that some systems are equally illegally shut down, and some systems are automatically detected (usually the FAT file system), while some systems are started as usual (usually NTFS file systems).
why?
Originally different file systems, this difference can be used for legal terms to be used for DIRTY BIT.
(1) FAT is equivalent to the mainland law system, and it is "guilty". Before writing data, first assume that the file system is "guilty" - set the dirty bit to 1. Only after confirming the data operation is completed, the DIRTY bit is set to 0. If it is illegally turned off, the DIRTY bit may remain in 1, then the next turbine will automatically perform disk scanning.
(2) NTFS is equivalent to the British and American law system, and it is realized "innocence." Only if there is serious data inconsistency, it is not possible to fix the Dirty bit at this time.
experiment procedure
1. Toolbox
(1) Winhex: This article will use this tool to view, modify the $ VOLUME metadata file. Download address: http://www.x-ways.net/winhex/index-m.html
(2) FSUTIL: This command line tool can manage the file system. This article will use the tool to manage the Dirty bit settings of the NTFS file system, and then use WinHex to get the underlying information of the disk data. Windows XP / 2003 comes with Windows 2000, you can directly borrow tools under XP.
2. Experimental steps
Since Windows protects NTFS metadata files, we can't access $ VOLME directly in the Windows system, but we can use third-party disk tools Winhex to wind this system restrictions to achieve your goal.
In this experiment, we use WinHex to access the $ VOLUME file of the NTFS volume to confirm which of the Dirty Bit corresponds to which of the Volume file.
(1) Use WinHex to open any volume, such as a D disk, you can see all metadata files in the D drive, such as $ MFT, $ MFTMIRR, $ VOLME, etc. Double-click on $ VOLUME to open the file.
(2) Everyone knows that each NTFS file is composed of several properties. The $ VOLUME file has two unique properties, $ volume_name, and $ volume_information. Where the volume is defined by the $ Volume_name, and Dirty bit is defined by the $ Volume_information property. The value of the Volume_information property is shown in the following figure, the value 70h at the beginning indicates the category of the attribute, and the value of the OFFSET 4 defines the length of the attribute, which is equivalent to the decimal 40. (3) In order to clearly identify the $ Volume_information property, the attribute is now screenshots as follows. The two bytes of the third party (OFFSET are 32-33) define the version number of the NTFS file system. The value in this example is 03 01, which represents NTFS 3.1 (Windows XP is a version 3.1, and Windows 2000 It is 3.0). (4) In order to find out where Dirty Bit is, we can use FSUTIL to create a Dirty bit. Run the following command at the command prompt: FSUTIL DIRTY SET D: Refresh the view of WinHex, you can see that the value of the Volume_information property changes, as shown below. You can give this conjecture: The byte of Offset 34 defines the Dirty bit setting of the NTFS file system. When the value is 01, Dirty bit is set by the NTFS file system. 3. Reverse verification In order to confirm this result, reverse verification is required. You can change the value of Offset 34 bytes in the $ volume_information property to 01 to see if the status bit is equivalent to setting the DIRTY bit. (1) Modify the value of the OFFSET 34 byte directly in WinHex, set it to 01, and save the settings. (2) The following command is then run, view the setting status of Dirty Bit: FSUTIL DIRTY QUERY D: Unexpectedly, the result of the command query is "Volume - D: No damage", that is, fsutil command It does not think that the file system sets Dirty bit. (3) Click Start → Turn off the computer → Restart, discovery that the system starts to automatically scan. It seems that the fsutil command does not recognize our manual settings, but actually active. 4. Troubleshooting (1) Why is the fsutil command can't query DIRTY BIT? Possible answers is that when the system Mount partitions, the important metadata files (including $ volume) are first read in memory, and the fsutil command reads the setting of Dirty Bit from the memory (instead of the disk). After manually modifying $ VOLUME, the system does not re-reckon the new $ volume into memory, so the fsutil command cannot query the setting of Dirty Bit. (2) How can I force the system to read into a metadata file? You can try to delete the drive letter of the volume (this example is D :) in the Disk Management unit, and then recover the drive letter. After setting, the fsutil command can only read the status of Dirty bit correctly. (3) Manually set the dirty bit, restart the system automatically run Chkdsk / f, why is the metadata file $ MFTMIRR error? $ MFTMirr saves four file records in the $ MFT, including $ Volume. The previous experiment process did not synchronize $ Volume in $ MFTMIRR, causing the two records inconsistent. Practical value
Of course, this paper refers to manually seting Dirty Bit methods just for experimental verification, there is no real application value, we don't have to use this method to manually set. It is clear that it is normal to shut down, but each time it is turned on, it will automatically ask if it is scanned. In this problem, you can follow the steps below (refer to KB160963): (1) Run the fsutil dirty query driveletter command, check if the disk is set up. If so, it may be a problem with the hard disk itself, please contact the hard disk manufacturer or computer dealer for testing. If you need to prevent the system from automatically detect Dirty bit, you can run the following command to exclude: ChkNTFS / X Driveletter (2) Check the task plan, there is no corresponding add-on item in the boot, and if you delete it. (3) Open the registry editor, enter the following registry key: hkey_local_machine / system / currentControlSet / Control / Session Manager Check the multi-character string keyxecute, whether it is similar to the following numerical data: AutoCheck Autochk / R /? ? / D: If it is, delete it / r / ?? / d: Tip In the NTFS file system, there is a very famous word "everything on the disk is a file", all file system data, all file, including MFT, boot sector, and even security descriptors.
About the description of the metadata file of the NTFS file system, you can refer to the following Microsoft official documentation:
Http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/library/techref/8cc5891d-bf8e-4164-862d-dac5418c5948.mspx
