ubifs: corrupted dirent (ENOENT), problably related to O_TMPFILE and linkat
Richard Weinberger
richard.weinberger at gmail.com
Tue Jul 27 14:06:42 PDT 2021
On Thu, Jul 22, 2021 at 12:56 PM Sebastian Gross
<sebastian.gross at emlix.com> wrote:
> > Can you reproduce using a recent kernel?
> As stated I am already having a hard time to reproduce it as it is. The last time took me ~2000 runs.
> But I will try anyway.
> Can you give me a pointer when there might a good time/place to cut the power?
> During the linkat or fsync call? Or maybe a certain function in the ubifs driver?
I'd try first with linkat().
You can always emulate a power-cut by placing ubifs_ro_mode() calls at
code paths where you suspect
the bug.
But often it is more complicated. Especially when the bug is in the
recovery code when the filesystem
is mounted the next time.
> > Yes. Maybe it makes sense to make UBIFS at this stage more forgiving instead of
> > the current situation.
> ubifs_readdir had then to check if the inodes it got are actually be found by tnc and then remove it.
> Seems quite hacky to me and not really upstream-worthy.
> Are there other places where a "faulty" inode can be "discovered"?
If you enable /sys/kernel/debug/ubifs/chk_fs, it will do a full scan
upon mount time.
This can detect such problems. But not fix them.
I have some ideas how to turn this feature into a minimal repair tool
but this has to be
done with extreme care.
--
Thanks,
//richard
More information about the linux-mtd
mailing list