On Wed, Jun 17, 2020 at 01:23:41PM -0700, David Christensen wrote: > On 2020-06-17 12:26, Reco wrote: > > > On Wed, Jun 17, 2020 at 12:10:51PM -0700, David Christensen wrote: > > > 2. AIUI dd(1) uses asynchronous (buffered) I/O unless told otherwise. > > > > You seem to confuse asynchronous and cached I/O too. > > > > > From Linux kernel POV, *asynchronous* I/O is a pair of > > io_submit/io_getevents syscalls, and dd does not do these regardless of > > the options that are provided. > > What dd does is a *synchronous* I/O (read/write syscalls or > > pread64/pwrite64 for older kernels). > > > > Whenever the I/O is cached (an output file is opened without > > O_DIRECT|O_DSYNC flags) or not is orthogonal to whenever it's sync or > > async. > > It would not surprise me if there are a dozen layers of chip registers, > caches, buffers, memory, etc., between a CPU register and whatever device > implements > data storage in a recent to modern x86_64 computer. And, I can only wonder if > reading /dev/zero even comes from a CPU register -- it would not surprise me > if > an MMU feature does. > > > I was referring to the 'fdatasync', 'fsync', 'dsync', 'sync', and 'nocache' > options to dd(1).
You did. These all deal with the various caching aspects. Several years ago I saw some patches to dd that implemented async I/O, but AFAIK they were never accepted upstream. May have something with the fact that the patches in question were written by Oracle employees. > Given the terse manual page, and a unwillingness to crawl the dd(1) > and/or kernel code, I can only guess at my understanding of what is > happening. There's strace for the lazy ones like you and me ;) One of my favorite troubleshooting tools for many years. > But, all of those options seem to imply some opposite of > asynchronous or buffered I/O as I know it. No, it's just the wording. "sync" - you are blocked on each read/write syscall, and there's no way around it. "async" - you're not, if you're doing io_submit. You are if you're doing io_getevents, but life's unfair. "direct" - you're telling the kernel that you do not consider a write completed unless it has landed at a persistent storage. You're asking a kernel to read for you regardless of the state of the kernel's current page cache. "cached" - you don't care whenever your write lands to the persistent storage. Likewise, you don't care if the read comes from the page cache or the persistent storage. Most of the I/O your everyday programs do is "cached sync". There are exceptions to this rule, like apt (dsync writes), or firefox (dsync writes for sqlite). But to have an async I/O, one usually have to link against libaio, like mysql or postgres do. > "The devil is in the details." Totally agree. Reco
