Subject: bug#19681: [PATCH] sync: use syncfs(2) if any argument is specified

From: Pádraig Brady <[email-masked]>
Date: Sun, 25 Jan 2015 18:32:29 +0000

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.
There is an edge case with fsync("fifo") for example where EINVAL is given,
though again since there is no data in the file system associated with that,
I wouldn't bother falling back to a file system interface.

As for documenting the fall back, that's one of the reasons I
suggested keeping the warning if syncfs() is not supported,
which should be enough direct feedback about the extra syncing happening.

cheers,
Pádraig.