Bye-bye bdflush()

The addition of system calls to the Linux kernel is a routine affair; it happens during almost every merge window. The removal of system calls, instead, is much more uncommon. That appears likely to happen soon, though, as discussions proceed on the removal of bdflush(). Read on for a look at the purpose and history of this obscure system call and to learn whether you will miss it (you won't).

Linux, like most operating systems, buffers filesystem I/O through memory; a write() call results in a memory copy into the kernel's page cache, but does not immediately result in a write to the underlying block storage device. This buffering is necessary for writes of anything other than complete blocks; it is also important for filesystem performance. Deferring block writes can allow operations to be coalesced, provide opportunities for better on-disk file layout, and enables the batching of operations.

Buffered file data cannot be allowed to live in memory forever, though; eventually the system must arrange for it to be flushed back to disk. Even the 0.01 Linux release included a version of the sync() system call, which forces all cached filesystem data to be written out. While the kernel would flush some buffers when the buffer cache (which preceded the page cache and was a fixed-size array at that time) filled up, there was no provision for regularly ensuring that all buffers were pushed out to disk. That task was, if your editor's memory serves, handled by a user-space process that would occasionally wake up and call sync().

There are advantages to handling this task in the kernel, though; it has a much better idea of the state of both the buffer cache and the underlying devices. As a step in that direction, the bdflush() system call was added to the 0.99.14y release on February 2, 1994. (This was a different era of kernel development; the preceding 0.99.14x release came out seven hours earlier, and 0.99.14z came out nine hours later). That implementation was not particularly useful, though; all it did was return a "not implemented" error. An actual bdflush() implementation was not added until the 1.1.3 development kernel in April 1994.

It must be said that bdflush() was a strange system call. It was defined as:

    int bdflush(int func, long data);

If func was zero, bdflush() would never return; instead, it would loop within the kernel, occasionally flushing out dirty buffers. In essence, a user-space process would become the kernel buffer-flushing thread by making that call; these were the days before proper kernel threads, after all. Passing func as one would cause some buffers to be flushed immediately. Higher values of func would either read or write the value of a control parameter for the flushing thread; these included the percentage of dirty buffers needed to activate flushing, the number of blocks to write in each cycle, etc.

While bdflush() was an improvement, there were a number of problems with it as well. One of those was that it relied on user space for a critical kernel function; if no process ever set itself up with bdflush(), or if that process were killed, bad things would happen. In the 1.3.50 development release (December 1995), the kernel was changed to automatically create a kernel thread (something it could do at that point) to do the flushing work. User space could still call bdflush() to tweak the various parameters, but an attempt to run as the flushing daemon would turn into an immediate call to exit(); that caused the update process started by older init systems to "work", avoiding boot-time unhappiness.

Another problem with bdflush() — or, more specifically, with the underlying implementation — since the beginning is that it was a single thread. As Linux grew in popularity and found itself on bigger systems, that single thread became an increasingly severe bottleneck. If you have a number of drives on a system, it will eventually take multiple threads to keep them all busy. Thus Andrew Morton replaced the remaining bdflush() infrastructure entirely in 2002 for the 2.5.8 development kernel; in its place was a new set of kernel threads called pdflush. Each pdflush thread was dedicated to a separate physical drive, providing a much-needed scalability improvement.

In December 2002, Morton merged a patch from Robert Love formally deprecating the bdflush() system call, promising that it "will be removed in a future kernel". The pdflush threads were removed in 2009 (for 2.6.32) in favor of a rather more elaborate, workqueue-based, writeback-control mechanism; those can still be seen in the form of kernel threads with names like kworker/u8:3-flush-259:0. Meanwhile, though, bdflush() lives on in current kernels, even though it has not done anything for many years.

Now, however, Eric Biederman is proposing to remove bdflush() entirely as part of a larger project he has to rework the kernel's exit() code. Given that this system call does nothing, was never widely used in the first place, and has been deprecated for nearly 19 years, one might confidently conclude that there are no users left. As it turns out, though, Geert Uytterhoeven has an old m68k image that he occasionally boots, presumably on days when he is overcome with nostalgia. Michael Schmitz demonstrated, though, that said image still boots successfully in the absence of bdflush(), so it is not an impediment to the system call's removal.

There are no other known users of bdflush() out there, so there would appear to be nothing preventing this removal from happening. At that point, it will be the first system call removed since late 2019, when sysctl() was deleted — by the same Eric Biederman. It would be surprising to see that happen in 5.14, though, given how recently this patch was posted. This system call has endured for almost 19 years after it ceased to be useful; keeping it for another two months until 5.15 does not seem like much of an imposition.

Index entries for this article
Kernel	System calls/bdflush()

---

to post comments