On Fri, Dec 13, 2024 at 05:43:09PM +0000, John Garry wrote: >> So if the redo log uses buffered I/O I can see how that would bloat writes. >> But then again using buffered I/O for a REDO log seems pretty silly >> to start with. >> > > Yeah, at the low end, it may make sense to do the 512B write via DIO. But > OTOH sync'ing many redo log FS blocks at once at the high end can be more > efficient. > > From what I have heard, this was attempted before (using DIO) by some > vendor, but did not come to much. I can't see how buffered I/O will be fast than an optimized direct I/O implementation. Then again compared to very dumb dio code that doesn't replace the caching in the page I can easily see how dio would be much worse. But given that people care about optimizing this workload enough to look into changes all over the kernel I/O stack I would expected that touching the code to write the redo log should not be out of the picture.
