<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mtd-utils.git/ubifs-utils/libubifs/master.c, branch v2.3.1</title>
<subtitle>A mirror of http://git.infradead.org/mtd-utils.git</subtitle>
<id>https://git.infraroot.at/mtd-utils.git/atom?h=v2.3.1</id>
<link rel='self' href='https://git.infraroot.at/mtd-utils.git/atom?h=v2.3.1'/>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/'/>
<updated>2024-11-11T09:32:46+00:00</updated>
<entry>
<title>fsck.ubifs: Read master node &amp; init lpt</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:01:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=3f8ee068870a046b0dcf2921ed7ee375f405e49f'/>
<id>urn:sha1:3f8ee068870a046b0dcf2921ed7ee375f405e49f</id>
<content type='text'>
This is the 1/18 step of fsck. Read and check master node, init lpt.
There could be following errors:
 1. corrupted scanning data in master area or invalid master node:
    danger mode with rebuild_fs and normal mode with 'yes' answer will
    turn to rebuild filesystem, other modes will exit.
 2. incorrect space statistics in master node: Set %FR_LPT_INCORRECT for
    for lpt status. Ignore the error.
 3. corrupted lpt: Set %FR_LPT_CORRUPTED for lpt status. Ignore the error.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Distinguish reasons when certain failures happen</title>
<updated>2024-11-11T09:32:45+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:01:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=518e5374471233125a595c5aeff2d0c3f5d27c0b'/>
<id>urn:sha1:518e5374471233125a595c5aeff2d0c3f5d27c0b</id>
<content type='text'>
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 &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>ubifs-utils: Adapt master.c in libubifs</title>
<updated>2024-11-11T09:32:45+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:00:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=0e537c08629ec82c0268358073e2e1c30d7590a1'/>
<id>urn:sha1:0e537c08629ec82c0268358073e2e1c30d7590a1</id>
<content type='text'>
Adapt master.c in libubifs, compared with linux kernel implementations:
 1. Remove authentication related implementations
    (eg. mst_node_check_hash), authentication is not supported in fsck
    for now.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>ubifs-utils: Import UBIFS libs from linux kernel</title>
<updated>2024-11-11T09:32:45+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T08:36:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=898499314c7073bbf6851db6542858921aeb6580'/>
<id>urn:sha1:898499314c7073bbf6851db6542858921aeb6580</id>
<content type='text'>
Import UBIFS libs from linux kernel. Next patches will replace ubifs
related source code with implementation of linux kernel, which makes
userspace implementation be same with linux kernel, then fsck.ubifs
can resuse the code.

Notice: lpt.c is modified with [1] applied. ubifs.h and orphan.c are
modified with [2] applied, journal.c is modified with [3] reverted(
because fsck runs in a single thread, so waitqueue is not needed to
be implemented in userspace.).
[1] https://lore.kernel.org/linux-mtd/20231228014112.2836317-13-chengzhihao1@huawei.com/
[2] https://lore.kernel.org/linux-mtd/20240410073751.2522830-1-chengzhihao1@huawei.com/
[3] https://lore.kernel.org/linux-mtd/20240122063103.359501-1-chengzhihao1@huawei.com/

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
</feed>
