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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aF0fjKq2zVKnkCsS@infradead.org>
Date: Thu, 26 Jun 2025 03:23:08 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Yafang Shao <laoar.shao@...il.com>
Cc: Jeff Layton <jlayton@...nel.org>, Christoph Hellwig <hch@...radead.org>,
	david@...morbit.com, djwong@...nel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-xfs@...r.kernel.org, yc1082463@...il.com
Subject: Re: [PATCH] xfs: report a writeback error on a read() call

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.