Messages in this thread | | | Subject | Re: [PATCH v3 0/2] fix error flag covered by journal recovery | From | "yebin (H)" <> | Date | Thu, 16 Feb 2023 16:12:03 +0800 |
| |
On 2023/2/16 15:18, Baokun Li wrote: > On 2023/2/14 10:29, Ye Bin wrote: >> From: Ye Bin <yebin10@huawei.com> >> >> Diff v3 Vs v2: >> Only fix fs error flag lost when previous journal errno is not record >> in disk. As this may lead to drop orphan list, however fs not record >> error flag, then fsck will not repair deeply. >> >> Diff v2 vs v1: >> Move call 'j_replay_prepare_callback' and 'j_replay_end_callback' from >> ext4_load_journal() to jbd2_journal_recover(). >> >> When do fault injection test, got issue as follows: >> EXT4-fs (dm-5): warning: mounting fs with errors, running e2fsck is >> recommended >> EXT4-fs (dm-5): Errors on filesystem, clearing orphan list. >> EXT4-fs (dm-5): recovery complete >> EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: >> data_err=abort,errors=remount-ro >> >> EXT4-fs (dm-5): recovery complete >> EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: >> data_err=abort,errors=remount-ro >> >> Without do file system check, file system is clean when do second mount. >> Theoretically, the kernel will not clear fs error flag. In >> errors=remount-ro >> mode the last super block is commit directly. So super block in >> journal is >> not uptodate. When do jounral recovery, the uptodate super block will be >> covered by jounral data. If super block submit all failed after recover >> journal, then file system error flag is lost. When do "fsck -a" couldn't >> repair file system deeply. >> To solve above issue we need to do extra handle when do super block >> journal >> recovery. >> >> >> Ye Bin (2): >> ext4: commit super block if fs record error when journal record >> without error >> ext4: make sure fs error flag setted before clear journal error >> >> fs/ext4/super.c | 18 ++++++++++++++++-- >> 1 file changed, 16 insertions(+), 2 deletions(-) > When we proceed in the flow of ( uninstall after injecting fault > triggered error -> mount > kernel replay journal -> umount to view fsck info ), there are three > cases: > > 1. When an injection fault causes the ERROR_FS flag to not be saved to > disk, but j_errno > is successfully saved to disk, PATCH 2/2 effectively ensures that > ERROR_FS is saved to disk > so that fsck performs a force check to discover the error correctly. > > 2. When j_errno is lost and the ERROR_FS flag is saved, after the > journal replay: > a. The ext4_super_block on disk has neither error info nor > ERROR_FS flag; > b. The ext4_super_block in memory contains error info but no > ERROR_FS flag > because the error info is copied additionally during journal > replay; > c. The ext4_sb_info in memory contains both error info and > ERROR_FS flag. > This means that the ext4_super_block in memory will be written to disk > the next time > ext4_commit_super is executed, while the ERROR_FS flag in ext4_sb_info > will not be written > to disk until ext4_put_super is called. So if there is a disk > deletion/power failure/disk offline, > we will lose the ERROR_FS flag or even the error info. > > (In this case, repairing directly with e2fsck will not do a force > check either, because it > relies on j_errno to recover the ERROR_FS flag after the journal > replay. And it reloads > the information from the disk into memory after the journal replay, so > the > ERROR_FS flag and error info are completely lost.) > > 3. If neither the ERROR_FS flag nor j_errno are saved to disk, we seem > to be unable to > determine if a deep sweep is currently needed. But I think when > journal replay is needed > it means that the file system exits abnormally, > *Is it possible to consider e2fsck to do a force check after the > journal replay?* Perhaps e2fsck can provide a command parameter, because it is unacceptable to do so in scenarios with requirements for startup time.
| |