Uncached Buffered IO Is Performing Great, Working Now On Btrfs / EXT4 / XFS

[coder]

I know dd has a direct option available. However, considering the potential benefits of RWF_UNCACHED, it could be particularly useful for updating IoT device firmware images where every byte of RAM, second, and CPU cycle matters.

Assuming you're using O_DIRECT on a filesystem which supports it, and you've catered to its limitations (i.e. only doing full-block writes), the difference should really boil down to whether you use userspace buffering and async I/O or whether the kernel uses the page cache and its own writeback mechanism.

I'm not saying dd's direct mode is particularly well-implemented. It might be, but I wouldn't assume so. In that case, what I'd suggest is that they quietly just switch to RWF_UNCACHED, when direct is used on kernels that support it.

[Jakobson]

Well, it already has a direct flag, for using O_DIRECT, which you can separately specify as an iflag or oflag. Depending on how well it's implemented, there could be little advantage to using RWF_UNCACHED, instead.

I'm not saying I'd be opposed to them using it, either instead of, or in addition to, direct. Just that, if you want to avoid cache pollution, it can already do that.

I know dd has a direct option available. However, considering the potential benefits of RWF_UNCACHED, it could be particularly useful for updating IoT device firmware images where every byte of RAM, second, and CPU cycle matters.

[coder]

dd could really use an iflag/oflag option for this new RWF_UNCACHED functionality, e.g.:
dd if=input_file of=output_file iflag=uncached oflag=uncached

Well, it already has a direct flag, for using O_DIRECT, which you can separately specify as an iflag or oflag. Depending on how well it's implemented, there could be little advantage to using RWF_UNCACHED, instead.

I'm not saying I'd be opposed to them using it, either instead of, or in addition to, direct. Just that, if you want to avoid cache pollution, it can already do that.

[Jakobson]

dd could really use an iflag/oflag option for this new RWF_UNCACHED functionality, e.g.:
dd if=input_file of=output_file iflag=uncached oflag=uncached

[coder]

I wonder if I have to enable something in the kernel or no, to have this feature?(once it has mainlined)

No, but applications will need be updated to explicitly use it, at least for now.

[EphemeralEft]

memory transmission is not errorprone so there are memory protocols, but as speed adventures to be continued there is addition for moooooooore congestion disaster... xfs is server db filesystem, ssd and their trim connection adding some complexes psy-cho kernel programmers(and (system) architect) therapy needs...

Was this comment written by an AI?

[dimko]

I wonder if I have to enable something in the kernel or no, to have this feature?(once it has mainlined)

[pong]

It has been a while since I've deeply immersed myself in linux IO but all this talk of option bits / command options etc. makes
me think that one might hypothetically be somehow enabled to set cache preferences using the file system / file associated configurations. So one might have some kind of cache et. al. preferences expressed at a filesystem mount level.

One might be able to have directory / file attributes or such also encode some file-by-file or directory scope settings just
as one could control things like CoW, compression, dirsync, etc.

I could imagine creating a build sandbox with the src files set to prefer RAM residency once loaded until explicitly set to be "unnecessary" by userland or until deleted. Similarly so for .o, .a files until they're done being used, etc.

[coder]

rsync in particular would be a great candidate to have this as an option.

Yes, as an option.

Actually, nocache isn't a bad model for this, since you might be running a variety of commands, and you wouldn't want each and every one of them to have to incorporate support for this flag + a commandline option for enabling it. Another possibility might be just to have glibc expose an environment variable that could be used to enable it.

https://manpages.ubuntu.com/manpages/noble/man1/nocache.1.html

[F.Ultra]

Lots of people use rsync to make backups. However, rsync has other uses, too. It would be a mistake for it to use this flag, because that would harm the other use cases. Instead, you really want the user to control caching behavior, similar to how they can control CPU selection via tools like taskset.

rsync in particular would be a great candidate to have this as an option. In far too many scrips does one have to run it with nocache to force it not to pollute the cache when transferring TiB of data between systems.