aboutsummaryrefslogtreecommitdiff
path: root/ubifs-utils/fsck.ubifs
AgeCommit message (Collapse)Author
7 daysfsck.ubifs: rebuild_fs: Re-write dataZhihao Cheng
This is the 8/12 step of rebuilding. Re-write data. Read data from LEB and write back data, make sure that all LEB is ended with empty data(0xFF). It will prevent failed gc scanning in next mounting. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: rebuild_fs: Record used LEBsZhihao Cheng
This is the 7/12 step of rebuilding. Record used LEBs which may hold useful nodes, then left unused LEBs could be taken for storing new index tree. Notice, LEB that contains effective nodes on deleted trees in step 1 is regarded as used. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: rebuild_fs: Check and correct files' informationZhihao Cheng
This is the 6/12 step of rebuilding. Correct the file information. Traverse all files and calculate information (nlink, size, xattr_cnt, etc.) for each file just like check_leaf() does, correct inode node based on the calculated information. Now, all files are consistent, and UBIFS will pass chk_fs after mounting. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: rebuild_fs: Extract reachable directory entries treeZhihao Cheng
This is the 5/12 step of rebuilding. Extract reachable directory entries tree. Make sure that all files can be searched from '/', unreachable file is deleted. So, all files can be accessible in userspace after reparing. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: rebuild_fs: Filter invalid filesZhihao Cheng
This is the 4/12 step of rebuilding. Filter out invalid files and drop them, for example: 1. File has no inode node or inode nlink is zero 2. Nonconsistent file type between inode node and dentry nodes 3. File has no dentry nodes(excepts '/') 4. Encrypted file has no xattr information 5. Non regular file has data nodes 6. Directory/xattr file has more than one dentries 7. Xattr file has no host inode, or the host inode is a xattr ... Valid xattr file will be inserted into corresponding host file's subtree. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: rebuild_fs: Add valid nodes into fileZhihao Cheng
This is the 3/12 step of rebuilding. Generate file according to left valid inode nodes and dentry nodes. Based on the results from step 2, it is easy to understand: Step 2 has done: valid_inos - del_inos = left_inos valid_dents - del_dents = left_dents Step 3 should do: Traverse left_inos and left_dents, insert inode/dentry nodes into corresponding file. After that, all files are generated by scanning, the next thing to do is dropping invalid files(eg. nonconsistent file type between inode node and dentry nodes, file has no dentry nodes(excepts '/'), encrypted file has no xattr information, etc.), which will be done in next step. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: rebuild_fs: Remove deleted nodes from valid node treeZhihao Cheng
This is the 2/12 step of rebuilding. Traverse nodes from del_inos and del_dents trees, remove inode nodes and dentry nodes with smaller sqnum from valid trees. This step handles deleting case, for example, file A is deleted, deleted inode node and deleted dentry node are written, if we ignore the deleted nodes, file A can be recovered after rebuilding because undeleted inode node and undeleted dentry node can be scanned. There's an exception, if deleted inode node and deleted dentry node are reclaimed(by gc) after deletion, file A is recovered. UBIFS rebuild_fs cannot solve it, because the real existence information of nodes depends on TNC, but TNC should not be depended for UBIFS rebuild_fs. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: Add rebuilding filesystem supportZhihao Cheng
Add rebuilding filesystem support. This is the 1/12 step of rebuilding. Collect files, valid inode nodes, deleted inode nodes, valid dentry nodes and deleted dentry nodes in kinds of trees by scanning nodes from flash. Corrupted nodes(eg. incorrect crc, bad inode size, bad dentry name length, etc.) are dropped during scanning. Larger sqnum node is picked when more than 1 nodes with same index. In this step, trun node and data nodes are put into corresponding file, inode/dentry nodes are put into four trees: valid_inos(nlink != 0), del_inos(nlink is 0), valid_dents(inum != 0), del_dents(inum is 0). Next step will process above four trees to deal deletion situations. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: Add file organization realizationZhihao Cheng
In order to check the consistency of each file and the reachability of the whole dentry tree, fsck orginizes all nodes into files. And the final recovered file(xattr is treated as a file) is organized as: (rbtree, inum indexed) / \ file1 file2 / \ file3 file4 file { inode node // each file has 1 inode node dentry (sub rb_tree, sqnum indexed) // '/' has no dentries, // otherwise at least 1 // dentry is required. trun node // the newest one truncation node data (sub rb_tree, block number indexed) // Each file may have 0 // or many data nodes xattrs (sub rb_tree, inum indexed) // Each file may have 0 or // many xattr files } Each file from file rb_tree is constructed by scanning nodes(eg. inode, dentry, etc.) from the TNC or the UBI volume. File's xattrs will be initialized in subsequent steps. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: Add node parsing functionsZhihao Cheng
Add parsing functions for each type of nodes, which will be used for checking the validity of raw node data while reading from TNC or scanning from UBIFS logical erase block. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: Load filesystem information from UBI volumeZhihao Cheng
Load filesystem information from UBI volume (Similar to UBIFS mounting process), initialize kinds of buffers and read superblock. This is the base step for both fsck and rebuild_fs. Subsequent pacthes will complete this step by adding more steps(eg. read master, replay journal, etc.) which are only used in fsck. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: Distinguish reasons when certain failures happenZhihao Cheng
Read failure caused by scanning corrupted data or invalid data members should be identified, because fsck can handle it. Updating lp failure caused by bad space statistics should be identified too, because fsck can handle it. Add eight callback functions to implement it for fsck: 1. set_failure_reason_callback: Record failure reasons when reading or parsing node failed, there are four reasons: a. FR_DATA_CORRUPTED: scanning corrupted data or invalid nodes found b. FR_TNC_CORRUPTED: invalid index nodes c. FR_LPT_CORRUPTED: invalid pnode/nnode d. FR_LPT_INCORRECT: invalid space statistics or invalid LEB properties 2. get_failure_reason_callback: get failure reasons 3. clear_failure_reason_callback: Clear the error which is caused by above reasons. 4. test_and_clear_failure_reason_callback: Check and clear the error which is caused by above reasons, if so, fsck will handle it according to specific situation. For example, fsck will drop data node rather than fails to return when reading failure is caused by DATA_CORRUPTED. For another example, journal replaying will continue rather than fails to return if updating lpt failure is caused by LPT_CORRUPTED. 5. set_lpt_invalid_callback: Set the invalid lpt status 6. test_lpt_valid_callback: Check whether the lpt is corrupted/incorrect, it should be invoked before updating lp, if lpt status is invalid, returns false (which means that caller should skip updating lp, because updating lp could trigger assertion failed in ubifs_change_lp). 7. can_ignore_failure_callback: Check whether the failure can be ignored, some inconsistent errors won't affect the fsck process, for example wrong space statistics can be fixed after traversing TNC, so failures caused by incorrect space statistics can be ignored. 8. handle_failure_callback: Check whether the failure can be handled, some inconsistent errors could be fixed by fsck, we have fix_problem to do that, but UBIFS needs a callback function to invoke it in common libs. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: Add inconsistent problem handling asking functionZhihao Cheng
There are four dimensions to define the type of inconsistent problems: 1. fixable: Some inconsistent problems can't be fixed, for example corrupted superblock. Un-fixable problem will abort program. 2. must fix: Some inconsistent problems can be ignored(eg. incorrect isize), but some are not(eg. corrupted TNC), which will affect the subsequent fsck steps. 3. drop data: Some fixing methods will drop user data, which is unacceptable for safe mode. If it happens, fsck will be aborted. 4. need rebuild: Some inconsistent problems depends on rebuilding filesystem to be fixed(eg. corrupted master node, corrupted TNC). Define an asking function to handle above kinds of inconsistent problems. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
7 daysfsck.ubifs: Add fsck supportZhihao Cheng
Add basic process code for fsck.ubifs. There are following modes for fsck: 1. normal mode: Check the filesystem, ask user whether or not to fix the problem as long as inconsistent data is found during fs checking. 2. safe mode: Check and safely repair the filesystem, if there are any data dropping operations needed by fixing, fsck will fail. 3. danger mode: Answer 'yes' to all questions. There two sub modes: a) Check and repair the filesystem according to TNC, data dropping will be reported. If TNC/master/log is corrupted, fsck will fail. b) Check and forcedly repair the filesystem according to TNC, turns to rebuild filesystem if TNC/master/log is corrupted. Always make fsck succeed. 4. check mode: Make no changes to the filesystem, only check the filesystem. 5. rebuild mode: Scan entire UBI volume to find all nodes, and rebuild filesystem, always make fsck success. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>