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: Wed, 3 Jan 2024 13:55:34 +0100 (CET)	[thread overview]
Message-ID: <939427292.194880.1704286534231.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <cc6e93a3-3d3c-6bae-51d9-d8cdd8ca0e4c@huawei.com>

----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@huawei.com>
> How about merging 3(a) and 3(b) as one mode(dangerous mode)? If fsck can
> get a good TNC(all non-leaf index nodes are valid), fsck executes as
> 3(a) describes. If fsck cannot find a good TNC, fsck executes as 3(b)
> and reminds user that "TNC is damaged, nodes dropping is not awared".

Well, you can make all modes combinable.
Right now I don't care much about the user interface.
But offering much flexibility is a worthwhile goal.

At the end it should be crystal clear to the user of fsck.ubifs whether
it fixed the file system by applying dangerous methods or not.

Want I want to avoid by all means is a tool which blindly alters
the filesystem just to stop UBIFS complaining about it.

Thanks,
//richard

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

  reply	other threads:[~2024-01-03 12:55 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 ` [PATCH RFC 00/17] ubifs: Add filesystem repair support Richard Weinberger
2023-12-29 13:09   ` 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 [this message]
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=939427292.194880.1704286534231.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