On 26/01/15 08:36, Giuseppe Scrivano wrote: > Pádraig Brady <[email protected]> writes: > >> On 25/01/15 18:05, Bernhard Voelker wrote: >>> On 01/25/2015 06:41 PM, Pádraig Brady wrote: >>>> So we have: fdatasync < fsync < syncfs < sync >>>> referring to:: file data, file data + metadata, file system, all file >>>> systems >>> >>>> [...] >>> >>>> I'd be incline to go with the _what_ interface above. >>> >>> Either way, I think it's important to document sync is falling back >>> to the bigger hammer if the smaller failed. >>> ... or shouldn't do sync this? >> >> It should fall back where possible. >> >> Now there is a difference between the file and file system(s) interfaces >> in that the former can return EIO error for example, while the latter >> are specified to always return success. You wouldn't fall back to >> a syncfs() if an fsync() gave an EIO for example. Also gnulib >> guarantees that fsync() and fdatasync() are available, so I wouldn't >> fallback from file -> file system interfaces, nor between file interfaces. > > one risk here is when multiple arguments are specified and the fsync > will return EIO more than once, we will fallback to syncfs multiple > times. Couldn't in this case a single sync be a better choice?
I was saying we shouldn't fall back from fsync() to syncfs(). Just process each argument. Diagnose any errors and EXIT_FAILURE if there was any error? Pádraig.
