On Tue, 2025-06-24 at 20:56 +0100, Matthew Wilcox wrote: > On Tue, Jun 24, 2025 at 02:26:18PM -0400, Jeff Layton wrote: > > On Tue, 2025-06-24 at 07:14 -0700, Christoph Hellwig wrote: > > > On Sun, Jun 22, 2025 at 08:32:18PM +0800, ying chen wrote: > > > > Normally, user space returns immediately after writing data to the > > > > buffer cache. However, if an error occurs during the actual disk > > > > write operation, data loss may ensue, and there is no way to report > > > > this error back to user space immediately. Current kernels may report > > > > writeback errors when fsync() is called, but frequent invocations of > > > > fsync() can degrade performance. Therefore, a new sysctl > > > > fs.xfs.report_writeback_error_on_read is introduced, which, when set > > > > to 1, reports writeback errors when read() is called. This allows user > > > > space to be notified of writeback errors more promptly. > > > > > > That's really kernel wide policy and not something magic done by a > > > single file system. > > > > ...not to mention that getting an error back on a read for a prior > > writeback error would be completely unexpected by most applications. > > Well. It's somewhat understandable: > > write() (returns success) > writeback happens, error logged > memory pressure evicts folio > read() brings folio into page cache > attempt to read contents fails, error returned > > I'm not sure it's a good solution, but it's plausible. Personally, I find it confusing. The range you're trying to read might actually be fine if the error happened in a different range. It also has the same problem as reporting writeback errors on close(), in that it's non-deterministic. You might not see an error if writeback didn't happen yet. Just because you didn't get an error when reading, that doesn't mean that your data is actually safe. Maybe this is ok as an opt-in thing for some workloads, but it does have some potential footguns. -- Jeff Layton <jlayton@xxxxxxxxxx>
