Skip to content
This repository was archived by the owner on Jul 16, 2022. It is now read-only.
This repository was archived by the owner on Jul 16, 2022. It is now read-only.

Proper fsync on OS X #6

Closed
Closed

Description

@lazka

I think this is missing

if hasattr(fcntl, "F_FULLFSYNC"):
    fcntl.fcntl(f.fileno(), fcntl.F_FULLFSYNC)
else:
    os.fsync(f.fileno())

on OSX.

As mentioned here [0] and here [1] fsync doesn't wait for the changes to hit the disk there.

[0] https://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html
[1] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/fsync.2.html#//apple_ref/doc/man/2/fsync

Activity

  1. untitaker commented on Dec 4, 2015

    @untitaker
    Owner

    While safer, I'm not sure this is desirable behavior on e.g. SSDs (where small
    writes are damaging).

    Overall fsync provides the amount of "safety" I've come to expect. I haven't
    seen any other impl do anything special for OS X and therefore assumed that my
    level of "safety" is sufficient.

    That said: We probably want this, but with a flag to turn it off in
    performance-critical situations.

    On Wed, Dec 02, 2015 at 04:51:37AM -0800, Christoph Reiter wrote:

    I think this is missing

    if hasattr(fcntl, "F_FULLFSYNC"):
        fcntl.fcntl(f.fileno(), fcntl.F_FULLFSYNC)
    else:
        os.fsync(f.fileno())
    

    on OSX.

    As mentioned here [0] and here [1] fsync doesn't wait for the changes to hit the disk there.

    [0] https://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html
    [1] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/fsync.2.html#//apple_ref/doc/man/2/fsync


    Reply to this email directly or view it on GitHub:
    #6

  2. untitaker commented on Jul 26, 2016

    @untitaker
    Owner

    @Unrud Do you have any opinion on this?

  3. untitaker commented on Jul 26, 2016

    @untitaker
    Owner

    After re-reading this I'm not sure if it's always expected that we block for the data to hit the disk. As long as it doesn't linger in the cache for too long (> 1sec, for example), it should be fine, no?

  4. Unrud commented on Jul 26, 2016

    @Unrud

    I would use F_FULLFSYNC on OS X. If fsync doesn't ensure that data is written into permanent storage (and the on-disk cache doesn't have battery backup), the operation is neither atomic nor durable.

    As long as it doesn't linger in the cache for too long (> 1sec, for example)

    But there are no guarantees for this. The data can linger in the cache for an arbitrary amount of time.

    The same problem seems to exist on Windows.

  5. untitaker commented on Jul 26, 2016

    @untitaker
    Owner

    It seems my reading comprehension is getting worse. Will implement as-is.

  6. added 6 commits that reference this issue on Jul 26, 2016
    c3dd736
    13b6caf
    669e642
    e395d82
    7580a5d
    77fb4cb
  7. changed the title [-]Support OSX[/-] [+]Proper fsync on OS X[/+] on Jul 26, 2016
  8. untitaker commented on Jul 26, 2016

    @untitaker
    Owner

    See #18 for Windows

  9. added a commit that references this issue on Jul 26, 2016
    2bdd9da
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions