On Tue 21-01-25 15:10:47, libaokun@xxxxxxxxxxxxxxx wrote: > From: Baokun Li <libaokun1@xxxxxxxxxx> > > The data_err=abort was initially introduced to address users' worries > about data corruption spreading unnoticed. With direct writes, we can > rely on return values to confirm successful writes to disk. But with > buffered writes, a successful return only means the data has been written > to memory. Users have no way of knowing if the data has actually written > it to disk unless they use fsync (which impacts performance and can > sometimes miss errors). > > The current data_err=abort implementation relies on the ordered data list, > but past changes have inadvertently altered its behavior. For example, if > an extent is unwritten, we do not add the inode to the ordered data list. > Therefore, jbd2 will not wait for the data write-back of that inode to > complete and check for errors in the inode mapping. Moreover, the checks > performed by jbd2 can also miss errors. > > Now, all buffered writes eventually call ext4_end_bio(), where I/O errors > are checked. Therefore, we can check for the data_err=abort mode at this > point and abort the journal in a kworker (due to the interrupt context). > > Therefore, when data_err=abort is enabled, the journal is aborted in > ext4_end_io_end() when an I/O error is detected in ext4_end_bio() to make > users who are concerned about the contents of the file happy. > > Suggested-by: Jan Kara <jack@xxxxxxx> > Link: https://patch.msgid.link/c7ab26f3-85ad-4b31-b132-0afb0e07bf79@xxxxxxxxxx > Signed-off-by: Baokun Li <libaokun1@xxxxxxxxxx> > Reviewed-by: Zhang Yi <yi.zhang@xxxxxxxxxx> Looks good. Feel free to add: Reviewed-by: Jan Kara <jack@xxxxxxx> Just one naming suggestion below: > +#define EXT4_IO_END_NEED_COMPLETION (EXT4_IO_END_UNWRITTEN | EXT4_IO_END_FAILED) I'd call this EXT4_IO_END_DEFER_COMPLETION > +static bool ext4_io_end_need_completion(ext4_io_end_t *io_end) And this would then be ext4_io_end_defer_completion(). Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
