Re: [PATCH] xfs: report a writeback error on a read() call

[Christoph Hellwig <hch@infradead.org>]

On Thu, Jun 26, 2025 at 10:41:47AM +0800, Yafang Shao wrote:
> As you mentioned earlier, calling fsync()/fdatasync() after every
> write() blocks the thread, degrading performance—especially on HDDs.
> However, this isn’t the main issue in practice.
> The real problem is that users typically don’t understand "writeback
> errors". If you warn them, "You should call fsync() because writeback
> errors might occur," their response will likely be: "What the hell is
> a writeback error?"
> 
> For example, our users (a big data platform) demanded that we
> immediately shut down the filesystem upon writeback errors. These
> users are algorithm analysts who write Python/Java UDFs for custom
> logic—often involving temporary disk writes followed by reads to pass
> data downstream. Yet, most have no idea how these underlying processes
> work.

Well, if you want to immediately shutdown we should not report writeback
errors but do a file system shutdown.  Which given how we can't recover
from them in general is the right default.

> > Personally, I like the fcntl() idea better for this, but maybe we have
> > other uses for a fsync2().
> 
> What do you expect users to do with this new fcntl() or fsync2()? Call
> fsync2() after every write()? That would still require massive
> application refactoring.

That's why I'm asking what your intended use case for the writeback
reporting is.