How to read and write Windows Registry offline

Regardless of the file system, its fundamental purpose is the same: how to put the file in a given area of the system, how to effectively manage the reading and writing of files. To achieve this, the drive layer needs to be well and carefully dealt with the various operations attached to the file system. These operations are usually not an instruction complete, if a process requires more than one instruction to complete, in the execution of these operations, all the instructions do not complete the case of the interruption, then the file system will have a consistency error (or called continuity error).

In order to ensure that there is less consistency error, now the mainstream file system will be designed to log-type. The main feature of the log file system is that all the instructions for an operation are buffered separately, and if all the execution is done and then the log flag is cleared, if the operation is not completed, it can be traced back or continued through the log after reactivation.

The EXT3 log function records the operation of the file system in this file by adding a special file (usually the 8th node file) based on the design of the EXT2. But the EXT system filesystem itself does not have redundant protection in nodes, indirect index blocks, and directory nodes, so when the file system is not consistent with other structures except the log, and it is repaired by fsck, this consistency is likely to make the correct structure even more erroneous. (Just like the original is 1+2=3, now wrong became 1+3=3, perhaps after changed into a 1+3=4, there is no way to restore the earliest 1+2=3).

This is often the case with data recovery: Once a raid fails, the next boot system prompts for fsck, but after that, it cannot mount partitions or mount partitions after the data is all wrong. The difficulty of data repair for such a situation is great, and it is harder to build another completely different structure than to fix a faulty structure, from a complete structure (which is actually complete from the system perspective). In fact, a lot of this is because RAID5 has an early offline disk joined two logical disk groups, resulting in all the data flow is in the new + old way of interleaving, naturally there will be too many errors. At this point, if you do fsck, it is possible that the data will not be restored.

So, in EXT3 (in fact, other file systems are similar) can not mount, or hint fsck, if there are important data, should be treated with caution, do not rashly implement the "Fsck-f-y" automatic repair function. If possible, do a DD full mirror of the fault area before execution, or read-only execution, and look carefully at the repair process, if prompted by a large number of inode errors, the need to rebuild the tree, or the size of the peer can not continue to go on.