On Wed, Jun 25, 2025 at 10:06 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Wed, 2025-06-25 at 04:56 -0700, Christoph Hellwig wrote: > > On Wed, Jun 25, 2025 at 07:49:31AM -0400, Jeff Layton wrote: > > > Another idea: add a new generic ioctl() that checks for writeback > > > errors without syncing anything. That would be fairly simple to do and > > > sounds like it would be useful, but I'd want to hear a better > > > description of the use-case before we did anything like that. 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. > > > > That's what I mean with my above proposal, except that I though of an > > fcntl or syscall and not an ioctl. > > Yeah, a fcntl() would be reasonable, I think. > > For a syscall, I guess we could add an fsync2() which just adds a flags > field. Then add a FSYNC_JUSTCHECK flag that makes it just check for > errors and return. > > 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. Writeback errors are fundamentally bugs in the filesystem/block layer/driver stack. It makes no sense to expose kernel implementation flaws to userspace, forcing developers to compensate for kernel-level issues with additional syscalls. Most users neither have the patience nor should they need to understand the deepest intricacies of Linux kernel internals. The proper fix should happen in the kernel—not by pushing workarounds onto applications. -- Regards Yafang
