Re: [PATCH v3 0/2] fix error flag covered by journal recovery

[yebin (H)]

On 2023/2/16 15:18, Baokun Li wrote:
> On 2023/2/14 10:29, Ye Bin wrote:
> > From: Ye Bin <yebin10@xxxxxxxxxx>
> >
> > 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.