Messages in this thread |  | | Date | Fri, 29 Dec 2023 11:06:02 +0100 (CET) | | From | Richard Weinberger <> | | Subject | Re: [PATCH RFC 00/17] ubifs: Add filesystem repair support |
| |
----- 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
|  |