public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: chengzhihao1 <chengzhihao1@huawei.com>
Cc: david oberhollenzer <david.oberhollenzer@sigma-star.at>,
	 Miquel Raynal <miquel.raynal@bootlin.com>,
	 Sascha Hauer <s.hauer@pengutronix.de>,
	 Tudor Ambarus <Tudor.Ambarus@linaro.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>,
	 linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH RFC 00/17] ubifs: Add filesystem repair support
Date: Fri, 29 Dec 2023 11:06:02 +0100 (CET)	[thread overview]
Message-ID: <1145531757.175508.1703844362355.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20231228014112.2836317-1-chengzhihao1@huawei.com>

----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@huawei.com>
> An: "david oberhollenzer" <david.oberhollenzer@sigma-star.at>, "richard" <richard@nod.at>, "Miquel Raynal"
> <miquel.raynal@bootlin.com>, "Sascha Hauer" <s.hauer@pengutronix.de>, "Tudor Ambarus" <Tudor.Ambarus@linaro.org>
> CC: "linux-kernel" <linux-kernel@vger.kernel.org>, "linux-mtd" <linux-mtd@lists.infradead.org>
> Gesendet: Donnerstag, 28. Dezember 2023 02:40:55
> Betreff: [PATCH RFC 00/17] ubifs: Add filesystem repair support

Thanks a lot for sharing this.
Below you find some thoughts that came into my mind while skimming over the
patch series.

> UBIFS repair provides a way to fix inconsistent UBIFS image(which is
> corrupted by hardware exceptions or UBIFS realization bugs) and makes
> filesystem become consistent, just like fsck tools(eg. fsck.ext4,
> fsck.f2fs, fsck.fat, etc.) do.

I don't fully agree. The tool makes UBIFS mount again but you still have lost data
and later userspace might fail because file no longer contain what the application
expected.
So my fear is that we're just shifting the problem one layer up.

UBIFS never had a fsck for reasons. UBIFS tries hard to not become inconsistent,
by maintaining a data journal for example.
It can fail of course by hardware issues. e.g. if the underlying MTD loses bits,
but there is nothing UBIFS can do except something like storing duplicates
of data like BTRFS does.

And finally, the biggest pain point, it can fail due to bugs in UBIFS itself.
In my opinion bugs should get addressed by improving our test infrastructure
instead of working around.

> About why do we need it, how it works, what it can fix or it can not
> fix, when and how to use it, see more details in
> Documentation/filesystems/ubifs/repair.rst (Patch 17).

This needs to go into the cover letter.
 
> Testing on UBIFS repair refers to
> https://bugzilla.kernel.org/show_bug.cgi?id=218327
> 
> Whatever, we finally have a way to fix inconsistent UBFIS image instead
> of formatting UBI when UBIFS becomes inconsistent.

Fix in terms of making mount work again, I fear? As I said, most likely
the problem is now one layer above. UBIFS thinks everything is good but
userspace suddenly will see old/incomplete files.

What I can think of is a tool (in userspace like other fscks) which
can recover certain UBIFS structures but makes very clear to the user what
the data is lost. e.g. that inode XY now misses some blocks or an old version
of something will be used.
But this isl nothing you can run blindly in production.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2023-12-29 10:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28  1:40 [PATCH RFC 00/17] ubifs: Add filesystem repair support Zhihao Cheng
2023-12-28  1:40 ` [PATCH RFC 01/17] ubifs: repair: Load filesystem info from volume Zhihao Cheng
2023-12-28  1:40 ` [PATCH RFC 02/17] ubifs: repair: Scan nodes " Zhihao Cheng
2023-12-28  1:40 ` [PATCH RFC 03/17] ubifs: repair: Remove deleted nodes from valid node tree Zhihao Cheng
2023-12-28  1:40 ` [PATCH RFC 04/17] ubifs: repair: Add valid nodes into file Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 05/17] ubifs: repair: Filter invalid files Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 06/17] ubifs: repair: Extract reachable directory entries tree Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 07/17] ubifs: repair: Check and correct files' information Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 08/17] ubifs: repair: Record used LEBs Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 09/17] ubifs: repair: Re-write data Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 10/17] ubifs: repair: Create new root dir if there are no scanned files Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 11/17] ubifs: repair: Build TNC Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 12/17] ubifs: Extract a helper function to create lpt Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 13/17] ubifs: repair: Build LPT Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 14/17] ubifs: repair: Clean up log and orphan area Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 15/17] ubifs: repair: Write master node Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 16/17] ubifs: Enable ubifs_repair in '/sys/kernel/debug/ubifs/repair_fs' Zhihao Cheng
2023-12-28  1:41 ` [PATCH RFC 17/17] Documentation: ubifs: Add ubifs repair whitepaper Zhihao Cheng
2023-12-29 10:06 ` Richard Weinberger [this message]
2023-12-29 13:09   ` [PATCH RFC 00/17] ubifs: Add filesystem repair support Zhihao Cheng
2023-12-29 21:08     ` Richard Weinberger
2024-01-02 10:08       ` Zhihao Cheng
2024-01-02 20:45         ` Richard Weinberger
2024-01-03  3:18           ` Zhihao Cheng
2024-01-03 12:44             ` Zhihao Cheng
2024-01-03 12:55               ` Richard Weinberger
2024-01-03 13:33             ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1145531757.175508.1703844362355.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=Tudor.Ambarus@linaro.org \
    --cc=chengzhihao1@huawei.com \
    --cc=david.oberhollenzer@sigma-star.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox