Message-ID: <dfoxg4aaolu6wknvh4644acbo3pvbtacwiztianjaol7zuf7vb@hbb7x2zitvwf>
Date: Wed, 8 Jan 2025 14:43:17 +0100
From: Jan Kara <jack@...e.cz>
To: Baokun Li <libaokun1@...wei.com>
Cc: Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org, tytso@....edu, 
	adilger.kernel@...ger.ca, linux-kernel@...r.kernel.org, yi.zhang@...wei.com, 
	yangerkun@...wei.com, libaokun@...weicloud.com
Subject: Re: [PATCH 3/5] ext4: abort journal on data writeback failure if in
 data_err=abort mode

On Wed 08-01-25 11:43:08, Baokun Li wrote:
> On 2025/1/6 22:32, Jan Kara wrote:
> > > But as you said, we don't track overwrite writes for performance reasons.
> > > But compared to the poor performance of journal_data and the risk of the
> > > drop cache exposing stale, not being able to sense data errors on overwrite
> > > writes is acceptable.
> > > 
> > > After enabling ‘data_err=abort’ in dioread_nolock mode, after drop_cache
> > > or remount, the user will not see the unexpected all-zero data in the
> > > unwritten area, but rather the earlier consistent data, and the data in
> > > the file is trustworthy, at the cost of some trailing data.
> > > 
> > > On the other hand, adding a new written extents and converting an
> > > unwritten extents to written both expose the data to the user, so the user
> > > is concerned about whether the data is correct at that point.
> > > 
> > > In general, I think we can update the semantics of “data_err=abort” to,
> > > “Abort the journal if the file fails to write back data on extended writes
> > > in ORDERED mode”. Do you have any thoughts on this?
> > I agree it makes sense to make the semantics of data_err=abort more
> > obvious. Based on the usecase you've described - i.e., rather take the
> > filesystem down on write IO error than risk returning old data later - it
> > would make sense to me to also do this on direct IO writes.
> 
> Okay, I will update the semantics of data_err=abort in the next version.
> For direct I/O writes, I think we don't need it because users can
> perceive errors in time.

So I agree that direct IO users will generally notice the IO error so the
chances for bugs due to missing the IO error is low. But I think the
question is really the other way around: Is there a good reason to make
direct IO writes different? Because if I as a sysadmin want to secure a
system from IO error handling bugs, then having to think whether some
application uses direct IO or not is another nuissance. Why should I be
bothered?

> >   Also I would do
> > this regardless of data=writeback/ordered/journalled mode because although
> > users wanting data_err=abort behavior will also likely want the guarantees
> > of data=ordered mode, these are two different things
> For data=journal mode, the journal itself will abort when data is abnormal.
> However, as you pointed out, the above bug may cause errors to be missed.
> Therefore, we can perform this check by default for journaled files.
> > and I can imagine use
> > cases for setups with data=writeback and data_err=abort as well (e.g. for
> > scratch filesystems which get recreated on each system startup).
> 
> Users using data=writeback often do not care about data consistency.
> I did not understand your example. Could you please explain it in detail?

Well, they don't care about data consistency after a crash. But they
usually do care about data consistency while the system is running. And
unhandled IO errors can lead to data consistency problems without crashing
the system (for example if writeback fails and page gets evicted from
memory later, you have lost the new data and may see old version of it).
And I see data_err=abort as a way to say: "I don't trust my applications to
handle IO errors well. Rather take the filesystem down in that case than
risk data consistency issues".

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists