Re: How can I bypass the buffer cache or disable it for a process?

It should help,

open(2)

man.freebsd.org

https://man.freebsd.org/cgi/man.cgi?open(2)

But like the guy said it depends on what help you’re looking for in that it’s going to be very slow but it’s perhaps useful if you need to write a small amount of data to disk at once rather than relying on sync/flush or cache which may be unreliable. If cache is unreliable you could maybe do something like,

flock LOCK_EX

Open/read, needs update?

Open write (normally) and write / flush / close

Release the lock

But if you really need then O_DIRECT is what you’re looking for I’m pretty sure, not to be confused with O_SYNC:

O_DIRECT alone only promises that the kernel will avoid copying data from user space to kernel space, and will instead write it directly via DMA (Direct memory access; if possible). Data does not go into caches. There is no strict guarantee that the function will return only after all data has been transferred.

> O_SYNC guarantees that the call will not return before all data has been transferred to the disk (as far as the OS can tell). This still does not guarantee that the data isn't somewhere in the harddisk write cache, but it is as much as the OS can guarantee.

> O_DIRECT|O_SYNC is the combination of these, i.e. "DMA + guarantee".

You can set both though and that might be more along the lines of what you’re asking for now that I think of it.

Sent from my iPhone

On Aug 5, 2026, at 10:53 PM, Steve Kargl <[email protected]> wrote:

On 8/5/26 22:39, Michael Schuster wrote:

On Thu, 6 Aug 2026, 01:24 Bob Bishop, <[email protected] <mailto:[email protected]>> wrote:

Hi,

On 4 Aug 2026, at 23:45, Friedrich Doku

<[email protected]

<mailto:[email protected]>> wrote:

Hello,

Is there a way to reliably run a single userspace process such

that all of its I/O (reads and writes) bypasses the UFS buffer cache?

The short answer is probably “no”.

Doesn't FreeBSD support direct I/O?

It has O_DIRECT for the open() system. That may or may not help.
OP has not stated if his interest is a single specific executable,
which he may adapted for O_DIRECT, or for any generic executable
that he may wish to run. Also, note that O_DIRECT does not mean
caching will never happen. See open(2) for more info.

--
steve