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.
