6

I'm running an experiment where I benchmark the speed of reading and writing with and without caching. On Linux, using 'conv=fsync' as an operand makes sure that the output file is entirely physically written before 'dd' exits (for more accurate times).

MacOS doesn't have this option for 'conv'. Is this something I should be concerned about as I look for accurate benchmarks? If so, what can I do?

Thanks for your time.

Phi Lam
  • 61
  • 1
  • 2
  • 2
    Use homebrew and get GNU coreutils? – muru Jun 08 '17 at 04:29
  • or calling `sync` additionally might help as well – stefanct Apr 15 '18 at 16:04
  • @muru That won’t work. You can’t just use Linux IO APIs on macOS and expect them to do the same thing. Unless GNU coreutils has specific code to address the BSD-specific API, using GNU’s `dd` will simply fail silently, i.e. the option `conv=sync` will do nothing. – Konrad Rudolph Jun 07 '20 at 09:26
  • @Konrad I don't expect GNU coreutils to be Linux specific, even if they're the most common userland utilities in Linux distros. – muru Jun 07 '20 at 09:34
  • @muru They’re not, but some macOS file systems simply don’t support this operation at all. It’s not just a matter of translating a function call and/or parameter. Reliable documentation is admittedly hard to come by but what appears to be macOS’ closest equivalent, `fcntl(F_FULLFSYNC)` is not supported by APFS, nor by certain device drivers. My point was that I don’t think that GNU `dd` will print an error in this case; it will simply fail silently. – Konrad Rudolph Jun 07 '20 at 09:49
  • @Kunrod I don't expect *all* Linux filesystems to support it either (unless this is handled in the vfs layer, but I haven't checked). I'd say it's reasonable to assume that (a) coreutils devs would use the right API if available, and (b) the user should check if the option is applicable to their OS and filesystem combinations. – muru Jun 07 '20 at 11:44

0 Answers0