GNU bug report logs - #19681
[PATCH] sync: use syncfs(2) if any argument is specified

Previous Next

Package: coreutils;

Reported by: Giuseppe Scrivano <gscrivan <at> redhat.com>

Date: Sun, 25 Jan 2015 03:06:02 UTC

Severity: normal

Tags: patch

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Giuseppe Scrivano <gscrivan <at> redhat.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: Bernhard Voelker <mail <at> bernhard-voelker.de>, 19681 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: bug#19681: [PATCH] sync: use syncfs(2) if any argument is specified
Date: Mon, 26 Jan 2015 09:36:05 +0100
Pádraig Brady <P <at> draigbrady.com> 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?

Regards,
Giuseppe




This bug report was last modified 6 years and 283 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.