On 4/24/25 18:43, Dmitry Antipov wrote:
> On 4/24/25 11:58 AM, Chao Yu wrote:
>
>> I guess we need to figure out why f2fs_bug_on() will be tiggerred?
>>
>> f2fs_write_end_io()
>> {
>> ...
>> f2fs_bug_on(sbi, folio->mapping == NODE_MAPPING(sbi) &&
>> folio->index != nid_of_node(&folio->page));
>
> Well, syzkaller is very "creative" in generating weirdly damaged filesystems
> :-).
Yeah.
>
> An overall idea of the patch is that an attempt to complete I/O on a
> filesystem
> which is known to be "broken enough to run fsck" may make the things even
> worse
> (by making the filesystem even less consistent). So it may be safer just to
> refuse all in-flight write attempts at least.
We will handle IO once there is critical error (tagged w/ CP_ERROR_FLAG), you
can check the detailed behaviors as below:
errors=%s Specify f2fs behavior on critical errors. This
supports modes:
"panic", "continue" and "remount-ro", respectively,
trigger
panic immediately, continue without doing anything,
and remount
the partition in read-only mode. By default it uses
"continue"
mode.
====================== =============== ===============
========
mode continue remount-ro
panic
====================== =============== ===============
========
access ops normal normal
N/A
syscall errors -EIO -EROFS
N/A
mount option rw ro
N/A
pending dir write keep keep
N/A
pending non-dir write drop keep
N/A
pending node write drop keep
N/A
pending meta write keep keep
N/A
====================== =============== ===============
========
But for SBI_NEED_FSCK case, if the inconsistency is detected in specific inode,
can we just
stop further updates for this inode? Rather than all inodes?
Thanks,
>
> Dmitry
>
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
